From guest Wed Jan 1 19:34:07 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id TAA01229; Wed, 1 Jan 1997 19:32:53 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id TAA01213; Wed, 1 Jan 1997 19:32:51 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id TAA26989; Wed, 1 Jan 1997 19:33:56 -0800 Received: from newton.ncsa.uiuc.edu (newton.ncsa.uiuc.edu [141.142.2.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01596 for ; Wed, 1 Jan 1997 19:32:49 -0800 Received: from eads.ncsa.uiuc.edu (eads.ncsa.uiuc.edu [141.142.4.3]) by newton.ncsa.uiuc.edu (8.8.4/8.8.4) with SMTP id VAA10121; Wed, 1 Jan 1997 21:32:47 -0600 (CST) Date: Wed, 1 Jan 1997 21:30:07 -0600 (CST) From: "Dee A. Chapman" To: info-performer@sgi.com cc: "Dee A. Chapman" Subject: path following reset Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hello, I have created a path that I have an object follow. However, it appears once the object has followed the path once, it cannot follow it again. Is there something that needs to be reset? I don't want to use the CloseLoop function because I don't want the object to follow the path continuously, but rather whenever I request it. Any suggestions? Thanks! Dee From guest Thu Jan 2 02:18:33 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA01929; Thu, 2 Jan 1997 02:17:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA01913; Thu, 2 Jan 1997 02:17:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA07461; Thu, 2 Jan 1997 02:18:23 -0800 Received: from server.artemedia.de (server.artemedia.de [194.221.74.66]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id CAA12765 for ; Thu, 2 Jan 1997 02:17:07 -0800 Received: from fitz (10.3.2.5) by jaco.artemedia.de (EMWAC SMTPRS 0.81) with SMTP id ; Thu, 02 Jan 1997 11:17:47 +0100 Sender: claude@artemedia.de Message-ID: <32CB8B51.167E@artemedia.de> Date: Thu, 02 Jan 1997 11:17:53 +0100 From: Jean-Claude Bachmann Organization: ARTEMEDIA PRODUCTIONS GmbH X-Mailer: Mozilla 2.01 (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: "Dee A. Chapman" CC: info-performer@sgi.com Subject: Re: path following reset References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Dee A. Chapman wrote: > > Hello, > > I have created a path that I have an object follow. However, it > appears once the object has followed the path once, it cannot > follow it again. Is there something that needs to be reset? I > don't want to use the CloseLoop function because I don't want > the object to follow the path continuously, but rather whenever > I request it. Any suggestions? > > Thanks! > Dee You forgot to mention which path utility you are using. If you took the pfuPath shipped with performer there is a function called pfuFollowPath(..., float seconds,.... which takes as one of its arguments a timestamp at which to calculate the position on the path. Now if you want to reset the path to the beginning, you simply have to keep an internal clock which is set to zero again. (pfuFollowPath(path,0,where,orient) should calculate the path at the beginning). The only problem I remember is that there is no function which tells when the path is at the end. There really should be a return value for the pfuFollowPath routine that gives something like PATH_FINISHED. J.C. -- ******************************************************************** * Artemedia GmbH | Tel.: +49 [0]30 25443 - 0 * * Jean-Claude Bachmann | Tel.: +49 0172 - 219 13 76 * * Budapesterstr. 40 | Fax.: +49 [0]30 25443 - 240 * * D-10787 Berlin | email: jean-claude.bachmann@artemedia.de * * Germany | Web Page http://www.artemedia.de * ******************************************************************** ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 2 05:36:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA02216; Thu, 2 Jan 1997 05:34:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA02200; Thu, 2 Jan 1997 05:34:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA12262; Thu, 2 Jan 1997 05:35:59 -0800 Received: from geordi.airinc.com (derrick.ott.hookup.net [165.154.43.219]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA04680 for ; Thu, 2 Jan 1997 05:34:50 -0800 Received: from geordi by geordi.airinc.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA24643; Thu, 2 Jan 1997 08:27:08 -0500 Sender: prider@airinc.com Message-ID: <32CBB7AB.41C6@airinc.com> Date: Thu, 02 Jan 1997 08:27:07 -0500 From: Paul Rider Organization: Airborne Data Technologies X-Mailer: Mozilla 3.0 (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: "Performer mailing list." Subject: Runway Lights Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hello All, In response to my own message about runway lights. I misinterpreted the specifications. Each light _was_ to flash twice a second, but in perfect sequence. Gerry was right. (Hey, I've never seen a runway, I'm going by the [sometimes mis-intrepeted] specifications). Thanks for the many solutions to the (incorrect) problem. The incorrect version now works great. ;) ciao, Paul J. Rider. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 2 06:24:00 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA02397; Thu, 2 Jan 1997 06:22:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA02381; Thu, 2 Jan 1997 06:22:46 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA13846; Thu, 2 Jan 1997 06:23:51 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id GAA11062 for ; Thu, 2 Jan 1997 06:22:44 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA18354; Thu, 2 Jan 97 08:15:01 -0500 Date: Thu, 2 Jan 97 08:15:01 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701021315.AA18354@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: Undocumented IRIS GL gl_sincos??? Status: O I guess that to replace gl_sincos, you could use separate calls to sin() and cos(), but if you are using Performer, then pfSinCos appears to be a direct plug-in replacement. One thing to watch though is that some of those ancient IrisGL routines don't use degrees for angular measurements. (eg the 'arc' routine takes arguments in integer tenths of a degree). Since the man page for gl_sincos appears to have vanished into the mists of time, you'll probably have to determine the meaning of that first argument from context. However, since the input angle (the first argument I guess) is an integer, it seems likely that its in tenths of a degree. So, the most likely fix is:- gl_sincos ( a, &b, &c ) ; becomes pfSinCos ( (float) a / 10.0f, &b, &c ) ; I hope this helps... Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 2 10:26:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA02787; Thu, 2 Jan 1997 10:24:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA02771; Thu, 2 Jan 1997 10:24:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA28456; Thu, 2 Jan 1997 10:26:03 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23611 for ; Thu, 2 Jan 1997 10:24:56 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA25331; Thu, 2 Jan 1997 13:23:46 -0500 Date: Thu, 2 Jan 1997 13:23:46 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701021323.ZM25330@hotsauce.clubfed.sgi.com> In-Reply-To: LIM MING WAH "Keeping current position" (Dec 31, 12:29pm) References: Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: LIM MING WAH , info-performer@sgi.com Subject: Re: Keeping current position Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O pfDCS's are absolute they do not accumulate matrix operations. Use a set of pfMatrix instances to hold the current transform for each object then use pfDCS::setMat(pfMatrix &) to load it into the proper DCS. Brian On Dec 31, 12:29pm, LIM MING WAH wrote: > Subject: Keeping current position > > Hello all, > I have recently tried to load many objects (up to 5) to perfly by > distributing them to different DCSs. Then I modified the keybd.c to take > in numbers from 1 to 5 and this toggles through the objects to be moved. > The problem I face is that whenever I toggle back to an object whcih I > have moved previously, it altomatically resets to its initial position. > Is there any way which I can preserve their most recent position when I > call up the object? > > > > I have added this to the keybd.c file: > > void toggleobject(int choice) > { > > ViewState->sceneDCS = pointer[choice]; > initXformer(); > > } > > > ========================================================================== > Jonathan > Department of Mechanical and Production Engineering > Faculty of Engineering > National University of Singapore > ========================================================================== > > > > > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from LIM MING WAH -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 3 08:19:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA06135; Fri, 3 Jan 1997 08:17:37 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA06119; Fri, 3 Jan 1997 08:17:36 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA22947; Fri, 3 Jan 1997 08:18:42 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA25111 for ; Fri, 3 Jan 1997 08:17:33 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id LAA01820; Fri, 3 Jan 1997 11:17:30 -0500 Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 3 Jan 97 11:15:59 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 3 Jan 97 11:15:30 EST From: "Bill Storma" Organization: Enzian Technology, Inc. To: info-performer@sgi.com Date: Fri, 3 Jan 1997 11:15:23 EST Subject: SIGSEGV in draw X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: <1A2D272E5E@P3.ENZIAN.COM> Status: O Performer users: I am experiencing a SIGSEGV in a multipipe Performer 2.0 program with IRIX 5.3. The SIGSEGV cause is EINTR, interrupted system call. However, the IRIX man page on signal (5) does not list this cause as a valid option for the SIGSEGV. Is the man page wrong, or is performer causing a SIGSEGV in a manner other than what the system expects ? Does anyone have an idea why this type of SIGSEGV would be created in a draw process anyway ? Thanks. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bill Storma Phone: 407-282-1884 Enzian Technology FAX: 407-282-3013 Orlando, Fl. 32817 e-mail: bills@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 3 08:05:13 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA06099; Fri, 3 Jan 1997 08:03:45 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA06083; Fri, 3 Jan 1997 08:03:44 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA22180; Fri, 3 Jan 1997 08:04:50 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA22493 for ; Fri, 3 Jan 1997 08:03:39 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id LAA29401; Fri, 3 Jan 1997 11:03:35 -0500 Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 3 Jan 97 11:02:05 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 3 Jan 97 11:01:59 EST From: "Bill Storma" To: info-performer@sgi.com Date: Fri, 3 Jan 1997 11:01:53 EST Subject: Catching child death signal X-mailer: Pegasus Mail v3.31 Message-ID: <19F37F7C60@P3.ENZIAN.COM> Status: O Performer users: I am having a problem with a child process dying in a draw process, due to a segmentation violation. Apparently the performer code captures this event and issues a note of the event, then dies. This implies that the child is notifing the parent of the event. However, the parent performer app does not issue any type of warning to the user code that the application is terminating. Does performer provide some type of mechanism to let the user code know of an impending termination of the program, or do I have to write my own signal handlers in the parent and child to do this ? Currently, I have trapped SIGSEGV in the child process to determine where the program is dying. But I do not get any SIGCHLD signal in the parent (I assume Performer overrode my signal handler). My only course of action currently is to send a signal other than SIGCHLD from the child to the parent to notify the parent that the child is dying. That way, the parent can exit via a different route than a normal termination. Is there a better way to do this ? Thanks. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bill Storma Phone: 407-282-1884 Enzian Technology FAX: 407-282-3013 Orlando, Fl. 32817 e-mail: bills@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 3 10:31:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA06520; Fri, 3 Jan 1997 10:29:53 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA06504; Fri, 3 Jan 1997 10:29:52 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA02355; Fri, 3 Jan 1997 10:30:57 -0800 Received: from magellan.bgm.link.com (magellan.bgm.link.com [130.210.238.23]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22192 for ; Fri, 3 Jan 1997 10:29:45 -0800 Received: by magellan.bgm.link.com (940816.SGI.8.6.9/930416.SGI) for info-performer@sgi.com id MAA05582; Fri, 3 Jan 1997 12:30:29 -0600 Date: Fri, 3 Jan 1997 12:30:29 -0600 From: cvillarm@magellan.bgm.link.com (Cris Villarma) Message-Id: <199701031830.MAA05582@magellan.bgm.link.com> To: info-performer@sgi.com Subject: swap space Status: O I received the following message while running a performer app: ALERT: svd [3124] - out of logical swap space during mmap - see swap(1M) What things do I need to consider when setting swap space values? ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 3 10:53:31 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA06583; Fri, 3 Jan 1997 10:49:00 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA06567; Fri, 3 Jan 1997 10:48:59 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA04092; Fri, 3 Jan 1997 10:50:05 -0800 Received: from smtp.connectnet.com (smtp.connectnet.com [207.110.0.12]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26547 for ; Fri, 3 Jan 1997 10:48:56 -0800 Received: from curt.delphiresearch.com ([207.110.10.2]) by smtp.connectnet.com (8.8.4/Connectnet-2.2) with ESMTP id KAA29171 for ; Fri, 3 Jan 1997 10:49:37 -0800 (PST) Message-Id: <199701031849.KAA29171@smtp.connectnet.com> From: "Curt Bryan" To: Subject: HUD examples using Performer Date: Fri, 3 Jan 1997 10:53:06 -0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: O Hello and Happy New Year! I hope that this questions hasn't been asked to many times before but... can anyone direct me to or share an example of a simple generic HUD application based on Performer 2.1?? I'm specifically having trouble with the scrolling heading display at the top of the HUD. My thanks in advance. __________________________________ Curt Bryan | Delphi Research, Inc. | 3954 Murphy Canyon Road | Suite D-201 | San Diego, CA 92123 | | Voice: (619) 694-1314 | Fax: (619) 694-1356 | | E-mail: curtb@delphiresearch.com | ----------------------------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 3 11:19:15 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA06721; Fri, 3 Jan 1997 11:17:24 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA06705; Fri, 3 Jan 1997 11:17:23 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA06911; Fri, 3 Jan 1997 11:18:29 -0800 Received: from physics.ucla.edu (physics.ucla.edu [128.97.23.13]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03256 for ; Fri, 3 Jan 1997 11:17:21 -0800 Received: from scotch.physics.ucla.edu by physics.ucla.edu (SMI-8.6/SMI-SVR4) id LAA22526; Fri, 3 Jan 1997 11:17:17 -0800 Received: (from chris@localhost) by scotch.physics.ucla.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA17493 for info-performer@sgi.com; Fri, 3 Jan 1997 11:33:10 -0800 Date: Fri, 3 Jan 1997 11:33:10 -0800 From: chris@scotch.physics.ucla.edu (chris) Message-Id: <199701031933.LAA17493@scotch.physics.ucla.edu> To: info-performer@sgi.com Subject: Should be an easy one. Status: O Hi Performers -- Happy New Year! Is there any reason why I can't model a cone with indexed tristrips? If anyone out there has already done this, I'd love to see how. Chris Chris Mitchell UCLA Physics Department LAPD Plasma Lab 310-206-1772 chrism@ucla.edu http://scotch.physics.ucla.edu/~chris ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 3 11:42:56 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA06825; Fri, 3 Jan 1997 11:41:14 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA06809; Fri, 3 Jan 1997 11:41:13 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA08956; Fri, 3 Jan 1997 11:42:18 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08155 for ; Fri, 3 Jan 1997 11:41:05 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Fri, 03 Jan 1997 14:30:15 Eastern Standard Time Received: by gateway.ivex3d.com from ntserver.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Fri, 03 Jan 1997 14:30:14 Eastern Standard Time Message-ID: <32CD6339.1949@ivex3d.com> Date: Fri, 03 Jan 1997 14:51:21 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Cannot create Semaphore via NFS (/usr/tmp) !!! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi : I have a Performer App (compiled under Pf2.0) actually , I am not sure, if it is 1.2 or 2.0. But now we have Performer 2.2 installed. The app is on an nfs mounted directory. When I tried to run this app froma local machine, I got this fatal error message pfInit: cannot create semaphore via NFS (/usr/tmp). Change PFTMPDIR I am not setting any PFTMPDIR. I tried setting it to /tmp etc but I keep getting the same message. I know that pfInit creates semaphores on /usr/tmp and allocates SharedArena on the swap space. Has anybody got such messages and found a solution ? Thanks Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 3 13:49:05 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA07261; Fri, 3 Jan 1997 13:47:17 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA07245; Fri, 3 Jan 1997 13:47:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA17356; Fri, 3 Jan 1997 13:48:23 -0800 Received: from kirk.dnaco.net ([206.150.232.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA29209 for ; Fri, 3 Jan 1997 13:47:15 -0800 Received: from picard.dnaco.net (eheft@picard.dnaco.net [206.150.232.4]) by kirk.dnaco.net (8.7.6/8.7.3) with ESMTP id QAA27002 for ; Fri, 3 Jan 1997 16:43:23 -0500 (EST) From: Eric Heft Received: (eheft@localhost) by picard.dnaco.net (8.7.6/8.6.9) id QAA23166 for info-performer@sgi.com; Fri, 3 Jan 1997 16:43:20 -0500 (EST) Message-Id: <199701032143.QAA23166@picard.dnaco.net> Subject: Questions on texture and contrast. To: info-performer@sgi.com (Performer Mailing List) Date: Fri, 3 Jan 1997 16:43:19 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: O Hi, I was wondering if anyone could tell me what controls the pixel values of an object that has a texture, when the lighting model in perfly has been turned off. I've got a simple cylinder that has a texture map. The texture map ranges from 0-255 with an avg is 127.5. When I snap the textured cylinder its range is 39-165 with an avg of 101.6. So what's going on? Or perhaps a better question might be how do I fully control the intensity of the pixels in an object? Thanks. Eric ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 3 20:27:59 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id UAA08885; Fri, 3 Jan 1997 20:26:42 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id UAA08869; Fri, 3 Jan 1997 20:26:41 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id UAA10791; Fri, 3 Jan 1997 20:27:47 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA04517 for ; Fri, 3 Jan 1997 20:26:40 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id UAA10787; Fri, 3 Jan 1997 20:27:46 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id UAA25191; Fri, 3 Jan 1997 20:26:39 -0800 From: "Rob Jenkins" Message-Id: <9701032026.ZM25189@quid.csd.sgi.com> Date: Fri, 3 Jan 1997 20:26:39 -0800 In-Reply-To: "Rambabu" "Cannot create Semaphore via NFS (/usr/tmp) !!!" (Jan 3, 2:51pm) References: <32CD6339.1949@ivex3d.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Rambabu" , info-performer@sgi.com Subject: Re: Cannot create Semaphore via NFS (/usr/tmp) !!! Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19701032026.ZM25189.csd.sgi.com" Status: O -- --PART-BOUNDARY=.19701032026.ZM25189.csd.sgi.com Content-Type: text/plain; charset=us-ascii I think this is a known problem. If you have a EFS filesystem you can point PFTMPDIR to that and it should work but I'm guessing you have XFS filesystem and Irix 6.2 in which case there's a script you can run to get your app running which I've attached ( see the script for a description ). Cheers Rob On Jan 3, 2:51pm, Rambabu wrote: > Subject: Cannot create Semaphore via NFS (/usr/tmp) !!! > Hi : > > I have a Performer App (compiled under Pf2.0) actually , I am not sure, > if > it is 1.2 or 2.0. But now we have Performer 2.2 installed. > The app is on an nfs mounted directory. > > When I tried to run this app froma local machine, I got this > fatal error message > > pfInit: cannot create semaphore via NFS (/usr/tmp). Change PFTMPDIR > > I am not setting any PFTMPDIR. I tried setting it to /tmp etc but > I keep getting the same message. I know that pfInit > creates semaphores on /usr/tmp and allocates SharedArena on the > swap space. Has anybody got such messages and found a solution ? > > Thanks > > Ram > > ram@ivex3d.com > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Rambabu -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA --PART-BOUNDARY=.19701032026.ZM25189.csd.sgi.com X-Zm-Content-Name: perf12xfs Content-Description: Text Content-Type: text/plain ; name="perf12xfs" ; charset=us-ascii #!/bin/sh # # perf21xfs $Revision: 1.2 $ # # Script to patch a statically linked Performer2.1 application # to allow it to run when PFTMPDIR is an XFS file system # (getting rid of the bogus fatal "cannot create semaphore arena via NFS" # error). # # Run this script on the executable (but make a backup first!) # # So far, it has been tested on the following files: # ~src/trees/demo/GL/perfly/perfly # /usr/demos/Impact/data/GIS/terrain/perfly.ptu # /usr/demos/Impact/MaxImpact/SGI/site/perfly # If you have an executable for which it doesn't work, # please let me know (hatch@sgi.com). # if [ $# -ne 1 ] then echo Usage: `basename $0` executablename >&2 exit 1 fi perl -p -i.bak \ -e '$/ = 0777;' \ -e "s/pfInit: cannot create semaphore arena via NFS \(%s\). Change PFTMPDIR./pfInit: semaphore arena dir (%s) is not EFS. Use PFTMPDIR to change./;" \ -e "s/(\ \217\274\000\040\ \000\000\000\000\ \217\231..\ \047\244..\ \003\040\370\011\ \047\245..\ \217\274\000\040\ \047\244..\ \217\231..\ \044\005\000\057\ \003\040\370\011\ \000\000\000\000\ \217\274\000\040\ \020\100\000\002\ \047\244..\ \240\100\000\000\ \217\231..\ \047\245..\ \044\006\000\050\ \003\040\370\011\ \000\000\070\045\ \217\274\000\040\ \004\101\000\013\ \207\256..\ \217\206..\ \217\231..\ \044\004\000\001\ \044\005\000\003\ \047\247..\ \003\040\370\011\ \044\306..\ \217\274\000\040\ \000\000\000\000\ \207\256..\ \044\001\000\001\ \025\301\000\012\ \000\000\000\000\ \217\206..\ \217\231..\ \044\004\000)\001\ /"'$1'"\005/g;" \ -e "s/(\ \047\244..\ \003\040\370\011\ \044\245..\ \217\274\000\040\ \000\000\000\000\ \217\231..\ \047\244..\ \003\040\370\011\ \047\245..\ \217\274\000\040\ \047\244..\ \217\231..\ \044\005\000\057\ \003\040\370\011\ \000\000\000\000\ \217\274\000\040\ \020\100\000\002\ \047\244..\ \240\100\000\000\ \217\231..\ \047\245..\ \044\006\000\050\ \003\040\370\011\ \000\000\070\045\ \217\274\000\040\ \004\101\000\013\ \207\257..\ \217\206..\ \217\231..\ \044\004\000\001\ \044\005\000\003\ \047\247..\ \003\040\370\011\ \044\306..\ \217\274\000\040\ \000\000\000\000\ \207\257..\ \044\001\000\001\ \025\341\000\011\ \044\004\000)\001\ /"'$1'"\005/g;" \ $1 exit 0 --PART-BOUNDARY=.19701032026.ZM25189.csd.sgi.com-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 5 15:19:30 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA11313; Sun, 5 Jan 1997 15:17:52 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA11297; Sun, 5 Jan 1997 15:17:51 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA00771; Sun, 5 Jan 1997 15:18:55 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA16905 for ; Sun, 5 Jan 1997 15:17:46 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id NAA03117; Sat, 4 Jan 1997 13:26:45 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id NAA26103; Sat, 4 Jan 1997 13:25:37 -0800 From: "Rob Jenkins" Message-Id: <9701041325.ZM26101@quid.csd.sgi.com> Date: Sat, 4 Jan 1997 13:25:36 -0800 In-Reply-To: "Curt Bryan" "HUD examples using Performer" (Jan 3, 10:53am) References: <199701031849.KAA29171@smtp.connectnet.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Curt Bryan" , Subject: Re: HUD examples using Performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Curt >From the Performer web page ( see the tag added to all info-performer posts ) there's a link to the ftp archives which in turn has links to info on selected-topics - under there is a hud section. In general the Performer web page does have a lot of info under it - worth spending some time getting an idea of what's there. Cheers Rob On Jan 3, 10:53am, Curt Bryan wrote: > Subject: HUD examples using Performer > Hello and Happy New Year! > > I hope that this questions hasn't been asked to many times before but... > can anyone direct me to or share an example of a simple generic HUD > application based on Performer 2.1?? I'm specifically having trouble with > the scrolling heading display at the top of the HUD. My thanks in advance. > __________________________________ > Curt Bryan | > Delphi Research, Inc. | > 3954 Murphy Canyon Road | > Suite D-201 | > San Diego, CA 92123 | > | > Voice: (619) 694-1314 | > Fax: (619) 694-1356 | > | > E-mail: curtb@delphiresearch.com | > ----------------------------------- > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Curt Bryan -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 5 15:19:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA11295; Sun, 5 Jan 1997 15:17:48 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA11279; Sun, 5 Jan 1997 15:17:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA00768; Sun, 5 Jan 1997 15:18:55 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA16903 for ; Sun, 5 Jan 1997 15:17:46 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id OAA04108; Sat, 4 Jan 1997 14:21:28 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id OAA26180; Sat, 4 Jan 1997 14:20:15 -0800 From: "Rob Jenkins" Message-Id: <9701041420.ZM26178@quid.csd.sgi.com> Date: Sat, 4 Jan 1997 14:20:15 -0800 In-Reply-To: Eric Heft "Questions on texture and contrast." (Jan 3, 4:43pm) References: <199701032143.QAA23166@picard.dnaco.net> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Eric Heft , info-performer@sgi.com (Performer Mailing List) Subject: Re: Questions on texture and contrast. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Eric Not considering blending, lighting, fog etc then you could look at the texture environment - man pfTexEnv, tevdef or glTexEnv will give you details. In the default texture environment the 'mode' is MODULATE ( incoming color components are multiplied by texture values ), you can change the texture environment to control how texture effects the values of screen pixels as you need. Cheers Rob On Jan 3, 4:43pm, Eric Heft wrote: > Subject: Questions on texture and contrast. > Hi, > > I was wondering if anyone could tell me what controls the pixel > values of an object that has a texture, when the lighting model in > perfly has been turned off. > > I've got a simple cylinder that has a texture map. The texture > map ranges from 0-255 with an avg is 127.5. When I snap the textured > cylinder its range is 39-165 with an avg of 101.6. So what's going > on? > > Or perhaps a better question might be how do I fully control the > intensity of the pixels in an object? > > Thanks. > Eric > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Eric Heft -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 5 22:10:47 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id WAA11965; Sun, 5 Jan 1997 22:09:27 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id WAA11949; Sun, 5 Jan 1997 22:09:26 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id WAA11999; Sun, 5 Jan 1997 22:10:34 -0800 Received: from sable.nus.sg (sable.nus.sg [137.132.1.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA13493; Sun, 5 Jan 1997 22:09:08 -0800 Received: from leonis.nus.sg (eng30228@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.8.4/8.6.9) with ESMTP id OAA25720; Mon, 6 Jan 1997 14:08:59 +0800 (SST) Received: from localhost (eng30228@localhost) by leonis.nus.sg (8.8.4/8.6.9/CNS-3.5) with SMTP id OAA04820; Mon, 6 Jan 1997 14:08:47 +0800 (SST) Date: Mon, 6 Jan 1997 14:08:47 +0800 (SST) From: LIM MING WAH To: Brian Furtaw cc: info-performer@sgi.com Subject: Re: Keeping current position In-Reply-To: <9701021323.ZM25330@hotsauce.clubfed.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Thu, 2 Jan 1997, Brian Furtaw wrote: > pfDCS's are absolute they do not accumulate matrix operations. Use a set of > pfMatrix instances to hold the current transform for each object then use > pfDCS::setMat(pfMatrix &) to load it into the proper DCS. > > Brian > I have saved the matrices corresponding to the DCSs and tried loading them back but instead encountered bus error!!! The following is what I have done...... int oldchoice = -1; void updatepos(int choice) { pfMatrix storematrix[20]; extern int NumFiles; int current, g; /* Initialising and saving the matrices */ if (oldchoice == -1) { for (g=0; gsceneDCS = pointer[g]; pfGetDCSMat(ViewState->sceneDCS, storematrix[g]); } oldchoice = 0; current = NumFiles - 1; } pfGetDCSMat(ViewState->sceneDCS, storematrix[current]); ViewState->sceneDCS = pointer[choice]; pfDCSMat(ViewState->sceneDCS, storematrix[choice]); current = choice; } Thanks for the help!!!!!! Jonathan ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 00:39:30 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id AAA12163; Mon, 6 Jan 1997 00:38:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id AAA12147; Mon, 6 Jan 1997 00:38:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA16351; Mon, 6 Jan 1997 00:39:25 -0800 Received: from sable.nus.sg (sable.nus.sg [137.132.1.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA28162 for ; Mon, 6 Jan 1997 00:38:04 -0800 Received: from leonis.nus.sg (eng30228@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.8.4/8.6.9) with ESMTP id QAA03688 for ; Mon, 6 Jan 1997 16:37:28 +0800 (SST) Received: from localhost (eng30228@localhost) by leonis.nus.sg (8.8.4/8.6.9/CNS-3.5) with SMTP id QAA13432 for ; Mon, 6 Jan 1997 16:37:26 +0800 (SST) Date: Mon, 6 Jan 1997 16:37:22 +0800 (SST) From: LIM MING WAH To: info-performer@sgi.com Subject: Rotations about its own axis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi all, Thanks to many who have helped in one way or another!!! I have managed to load in few DCSs and switching them around, I have also saved their matrices and tried to assign them back whenever I switch them back so that perfly remembers their last position. But this has not been so. Whenever I switch them back by assigning the ViewState->sceneDCS = pointer; and then follow by the function initXformer(), the objects will always reset to its original position. The following is the content in initXformer(): void initXformer(void) { ViewState->xformer = pfiNewTDFXformer(pfGetSharedArena()); pfiXformerAutoInput(ViewState->xformer, ViewState->masterChan, &ViewState->mouse, &ViewState->events); pfiXformerNode(ViewState->xformer, ViewState->sceneGroup); pfiXformerAutoPosition(ViewState->xformer, NULL, ViewState->sceneDCS); pfiXformerResetCoord(ViewState->xformer, &ViewState->initView); xformerModel(ViewState->xformerModel, ViewState->collideMode); resetPosition(POS_ORIG); } This is what I have added to perfly; int oldchoice = -1; pfMatrix storematrix[20]; void updatepos(int choice) { extern int NumFiles; int current, g; if (oldchoice == -1) /* Initialising the matrices with the DCSs */ { for (g=0; gsceneDCS = pointer[g]; pfGetDCSMat(ViewState->sceneDCS, storematrix[g]); } oldchoice = 0; current = NumFiles - 1; } pfGetDCSMat(ViewState->sceneDCS, storematrix[current]); ViewState->sceneDCS = pointer[choice]; pfDCSMat(ViewState->sceneDCS, storematrix[choice]); current = choice; } I have also added to keybd.c ; void toggleobject(int choice) { updatepos(choice); initXformer(); } Can anyone tell me what's wrong? ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 01:49:54 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA12320; Mon, 6 Jan 1997 01:48:15 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA12304; Mon, 6 Jan 1997 01:48:14 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA17911; Mon, 6 Jan 1997 01:49:22 -0800 Received: from xr1.atlas.fr (xr1.atlas.fr [194.51.9.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA05011 for ; Mon, 6 Jan 1997 01:48:03 -0800 Message-Id: <199701060948.BAA05011@sgi.sgi.com> X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 6 Jan 1997 10:47:34 +0100 X400-Received: by mta xr1.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 6 Jan 1997 10:47:34 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; converted (ia5-text,iso (1) (0) (10021) (7) (1) (0) (1),iso (1) (0) (10021) (7) (1) (0) (6),iso (1) (0) (10021) (7) (1) (0) (100)); Relayed; Mon, 6 Jan 1997 10:37:17 +0100 X400-Received: by /PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/; Relayed; Mon, 6 Jan 1997 10:31:05 +0100 Date: Mon, 6 Jan 1997 10:31:05 +0100 X400-Originator: MICHAEL.BOCCARA@siege.aerospatiale.fr X400-Recipients: info-performer@sgi.com, guest@holodeck.csd.sgi.com X400-MTS-Identifier: [/PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/;970106093105] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: CSI NC V3.0 From: BOCCARA Michael To: "P=INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=guest(a)holodeck.csd.sgi" (Receipt Notification Requested) (Non Receipt Notification Requested), Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: RE: Moving eyepoint vs. DCS translations MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Status: O =0C Hi and bonne annee a toi, O maitre es Performer If you take a glance at the source code for pfiTDFXformer class, you= will see that in the pfiTDFXformer::update function it calls the pfiTrackball= ::update function to calculate the matrix to be applied to the DCS, and then = it effectively applies it to the DCS What I did is to derivate the pfiTDFXformer class to overload the up= date() function, to recuperate the xPosMat member matrix,to invert it, and = apply it to the chan ViemMat, somewhat like this (i write it by memory, since= i dont have my source code on this babasse) : void pfi_My_TDFXformer::update() ( pfiTDFXformer::update(); if(motionModel =3D=3D PFITDF_TRACKBALL) ( xPosMat.invertOrthoN(xPosMat); xMotionCoord.mat.pre(or post..?)Mult(xPosMat); xMotionCoord.setMat(xMotionCoord.mat); xPosMat.makeIdent(); xPosDCS->setMat(pfIdentMat); xPosChan->setViewMat(xMotionCoord.mat); // that's it ) ) ____________________________________________________________________= ___________ _ De: P=3DINTERNET; DDA.TYPE=3DRFC-822; DDA.VALUE=3Dguest(a)holodeck.c= sd.sgi.com le Mar 31 D=E9c 1996 23:32 Objet: Moving eyepoint vs. DCS translations A: P=3DINTERNET; DDA.TYPE=3DRFC-822; DDA.VALUE=3Dinfo-performer(a)sg= i.com; BOCCARA Michael Fichiers: BDY12.TXT RFC-822-Headers: Organization: Silicon Graphics, Inc. X-Mailer: Mozilla 3.0 (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 Content-Type: text/plain; charset=3Dus-ascii Content-Transfer-Encoding: 7bit ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 05:41:37 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA13216; Mon, 6 Jan 1997 05:40:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA13200; Mon, 6 Jan 1997 05:40:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA24404; Mon, 6 Jan 1997 05:41:25 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA00220 for ; Mon, 6 Jan 1997 05:40:15 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA04088; Mon, 6 Jan 1997 08:39:10 -0500 Date: Mon, 6 Jan 1997 08:39:10 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701060839.ZM4087@hotsauce.clubfed.sgi.com> In-Reply-To: Eric Heft "Questions on texture and contrast." (Jan 3, 4:43pm) References: <199701032143.QAA23166@picard.dnaco.net> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Eric Heft , info-performer@sgi.com (Performer Mailing List) Subject: Re: Questions on texture and contrast. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Eric try a pfTexEnv of PFTE_DECAL that could fix your problem. Brian On Jan 3, 4:43pm, Eric Heft wrote: > Subject: Questions on texture and contrast. > Hi, > > I was wondering if anyone could tell me what controls the pixel > values of an object that has a texture, when the lighting model in > perfly has been turned off. > > I've got a simple cylinder that has a texture map. The texture > map ranges from 0-255 with an avg is 127.5. When I snap the textured > cylinder its range is 39-165 with an avg of 101.6. So what's going > on? > > Or perhaps a better question might be how do I fully control the > intensity of the pixels in an object? > > Thanks. > Eric > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Eric Heft -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 06:29:40 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA13362; Mon, 6 Jan 1997 06:28:23 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA13346; Mon, 6 Jan 1997 06:28:22 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA25888; Mon, 6 Jan 1997 06:29:30 -0800 Received: from mtolympus.ari.net (mtolympus.ari.net [198.69.192.4]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA06356 for ; Mon, 6 Jan 1997 06:28:13 -0800 Received: from peril.ari.net (peril.ari.net [198.69.194.98]) by mtolympus.ari.net (8.6.12/09161995) with ESMTP id JAA12197 for ; Mon, 6 Jan 1997 09:28:14 -0500 Message-Id: <199701061428.JAA12197@mtolympus.ari.net> From: "Glenn Waldron" To: Subject: VR developer needed Date: Mon, 6 Jan 1997 09:27:09 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: O ANSER, a not-for-profit corporation in Arlington Virginia, has an opening for someone with Performer experience to develop for and maintain an immersive 3-D visualization system. The system is a mini-CAVE running off an 8-proc 3-pipe SGI Infinite Reality. There are a couple deskside Onyx RE2's used for supporting applications, as well as an Indy for driving the audio system. The developer will have almost exclusive use of all these machines. (Check out www.evl.uic.edu/EVL/VR/systems.html#CAVE for more information of the CAVE and related VR systems.) Position: Full-time developer Location: Arlington, Virginia (www.washingtonpost.com/wp-srv/local/counties/arlngton.htm#index) Duties: Developing for, administering, demoing and maintaining the CAVE and supporting systems; Marrying CAVE technology and defense applications Required: BS in relevant field. Experience with real-time graphics systems, SGI, Performer, GL, UNIX, etc. Prefered: Experience with Coryphaeus products, modeling, HCI devices (gloves, trackers), stereographics, simulation-based design. Knowledge of networking, distributed simulation, sys admin, etc. Please email or fax your resume to: Glenn Waldron ANSER - Leading Edge Technologies Division email: gwaldron@peril.com (prefered method!!) fax: 703-416-4451 voicemail: 703-416-8462 PCS: 703-598-7835 address: 1215 Jefferson Davis Hwy., Suite 800 Arlington, VA 22202 -------------------------------------------------------------------- Glenn Waldron - ANSER Leading Edge Technologies PCS: 703.598.7835 email: gwaldron@peril.com voice mail: 703.416.8462 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 08:50:09 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA13573; Mon, 6 Jan 1997 08:48:36 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA13557; Mon, 6 Jan 1997 08:48:35 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA03380; Mon, 6 Jan 1997 08:49:43 -0800 Received: from vulcan.ncsc.navy.mil (vulcan.ncsc.navy.mil [130.109.120.157]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA00388 for ; Mon, 6 Jan 1997 08:48:24 -0800 Received: by vulcan.ncsc.navy.mil (931110.SGI/930416.SGI.AUTO) for info-performer@sgi.com id AA19384; Mon, 6 Jan 97 10:50:52 -0600 From: "Neil Matson" Message-Id: <9701061050.ZM19382@vulcan.ncsc.navy.mil> Date: Mon, 6 Jan 1997 10:50:50 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.com Subject: OpenGL vs Direct 3D comments Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Take a look at John Carmack's (Id Software guy working on the next generation Id technology...same guys that made Doom, Quake, etc.) view on Open GL and Microsoft's Direct 3D. "finger johnc@idsoftware.com" for his soapbox on the two. Very interesting. Neil Matson ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 10:23:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA14020; Mon, 6 Jan 1997 10:22:29 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA14004; Mon, 6 Jan 1997 10:22:28 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA11420; Mon, 6 Jan 1997 10:23:32 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA21054 for ; Mon, 6 Jan 1997 10:22:20 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-9.mail.demon.net id aa915991; 6 Jan 97 16:42 GMT From: Mark Baranowski To: info-vega@daisy.paradigmsim.com, info-performer@sgi.com Subject: Intersection Question Date: Mon, 06 Jan 1997 16:42:11 GMT Organization: Pera Message-ID: <32d12482.27962537@post.demon.co.uk> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O Hi Happy new year to everyone on the list(s). I have been sitting here thinking about implementing a geometry to geometry collision detection capability for our Vega applications and have managed to get myself all confused - nothing new there :) I want the tests to run in the intersection process. I got myself confused over the intersection function specified with pfIsectFunc. I had thought that you can only specify one intersection function, but what would happen if you were to call pfIsectFunc twice with different functions? The reason I ask is that I already have an intersection function for our own motion models which is set up with pfIsectFunc, and uses pfNodeIsectSegs. However we also make use of Vega Isector functions elsewhere. Everything is Ok which makes me think I am wrong about pfIsectFunc. Can anybody confirm whether I can set up a number of intersection functions using pfIsectFunc (I know I should go and test it, but it's almost time to leave!!) Thanks in advance (& forgive my ramblings - I've not got used to being back at work yet). Regards. Mark. --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leicestershire. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 10:50:39 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA14180; Mon, 6 Jan 1997 10:49:05 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA14164; Mon, 6 Jan 1997 10:49:04 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA13748; Mon, 6 Jan 1997 10:50:13 -0800 Received: from tuvok.mugu.navy.mil (tuvok.mugu.navy.mil [143.113.247.22]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA27686 for ; Mon, 6 Jan 1997 10:48:58 -0800 Received: from qmsmtpgw.mugu.navy.mil (qmsendgw.mugu.navy.mil) by tuvok.mugu.navy.mil (4.1/SMI-4.1) id AA06109; Mon, 6 Jan 97 09:49:10 PST Message-Id: Date: 6 Jan 1997 10:48:35 U From: "SCOTT OFRIEL" Subject: Turn off draw To: info-performer@sgi.com X-Mailer: Mail*Link SMTP-QM 3.0.2 Status: O Subject: Time: 10:33 AM OFFICE MEMO Turn off draw Date: 1/6/97 Hello All: Can I just turn off graphics processing? We would like to do this when the user iconifies the program. This way only the programs that are visible are burdening the graphics. Thanks for any input. Scott O' ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 11:14:49 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA14371; Mon, 6 Jan 1997 11:13:15 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA14355; Mon, 6 Jan 1997 11:13:14 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA16097; Mon, 6 Jan 1997 11:14:22 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03739; Mon, 6 Jan 1997 11:13:01 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id TAA09066; Mon, 6 Jan 1997 19:12:51 GMT From: "Angus Dorbie" Message-Id: <9701061912.ZM9064@bitch.reading.sgi.com> Date: Mon, 6 Jan 1997 19:12:51 +0000 In-Reply-To: "Neil Matson" "OpenGL vs Direct 3D comments" (Jan 6, 10:50am) References: <9701061050.ZM19382@vulcan.ncsc.navy.mil> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Neil Matson" , info-performer@sgi.com Subject: Re: OpenGL vs Direct 3D comments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O If you can't obtain the response from the finger, I will email you it's contents on request. It's interesting to note that this impartial and highly respected view completely vindicates what Mark Kilgard and others have been preaching all along at the expense of accusations of bias. Kind of confirms that Microsoft and the NT brigade will tell their customers & prospects any old tat to try gain control of their future reguardless of how painfull the customer will ultimately find the experience. Readers should not only note the history but also that Microsoft and other vested interests are _still_ trying to push this third rate technology. Caveat Emptor. Sorry if you find this a bit off the info-performer beaten path, please refer all replies to me directly or go & join the ever degenerating flame wars on comp.graphics.misc.api (I think). Cheers, Angus. On Jan 6, 10:50am, Neil Matson wrote: > Subject: OpenGL vs Direct 3D comments > > Take a look at John Carmack's (Id Software guy working on the next generation > Id technology...same guys that made Doom, Quake, etc.) view on Open GL and > Microsoft's Direct 3D. "finger johnc@idsoftware.com" for his soapbox on > the two. Very interesting. > > Neil Matson > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Neil Matson ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 12:21:16 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA14808; Mon, 6 Jan 1997 12:19:39 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA14792; Mon, 6 Jan 1997 12:19:38 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA22073; Mon, 6 Jan 1997 12:20:47 -0800 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20661 for ; Mon, 6 Jan 1997 12:19:32 -0800 Received: from poster.cae.ca by bhole with SMTP (DuhMail/2.0) id OAA17945; Mon, 6 Jan 1997 14:58:24 -0500 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA25784; Mon, 6 Jan 1997 15:00:33 -0500 Received: by eagle.cae.ca (951211.SGI.8.6.12.PATCH1042/930416.SGI.AUTO) for info-performer@sgi.com id OAA02763; Mon, 6 Jan 1997 14:59:52 -0500 From: "Bernard Leclerc" Message-Id: <9701061459.ZM2761@eagle.cae.ca> Date: Mon, 6 Jan 1997 14:59:49 -0500 In-Reply-To: "Angus Dorbie" "Re: OpenGL vs Direct 3D comments" (Jan 6, 7:12pm) References: <9701061050.ZM19382@vulcan.ncsc.navy.mil> <9701061912.ZM9064@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Performer Mailing List Subject: Re: OpenGL vs Direct 3D comments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O A colleague just forwarded me an interesting paper on the subject. Take a look at http://www.sgi.com/Technology/OpenGL/direct-3d.html -- Bernard Leclerc CAE Electronics Ltd., 8585 Cote De Liesse Technical Leader Saint-Laurent, Quebec, Canada, H4L-4X4 3-D Graphics Applications tel: +1 514 341 2000 extension 2275 bleclerc@cae.ca fax: +1 514 340 5496 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 13:12:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA15249; Mon, 6 Jan 1997 13:10:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA15233; Mon, 6 Jan 1997 13:10:50 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA25554; Mon, 6 Jan 1997 13:11:59 -0800 Received: from daisy.paradigmsim.com (daisy.paradigmsim.com [206.7.114.129]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA01724; Mon, 6 Jan 1997 13:10:39 -0800 Received: (from eliza@localhost) by daisy.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA15898; Mon, 6 Jan 1997 15:03:57 -0600 From: "Elizabeth Smith" Message-Id: <9701061503.ZM15897@daisy.paradigmsim.com> Date: Mon, 6 Jan 1997 15:03:57 -0600 In-Reply-To: Mark Baranowski "Intersection Question" (Jan 6, 4:42pm) References: <32d12482.27962537@post.demon.co.uk> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Mark Baranowski Subject: Re: Intersection Question Cc: info-vega@daisy.paradigmsim.com, info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 6, 4:42pm, Mark Baranowski wrote: > Subject: Intersection Question > > [ plain text > Encoded with "quoted-printable" ] : Hi > > Happy new year to everyone on the list(s). > > I have been sitting here thinking about implementing a geometry to > geometry collision detection capability for our Vega applications and > have managed to get myself all confused - nothing new there :) > > I want the tests to run in the intersection process. I got myself > confused over the intersection function specified with pfIsectFunc. I > had thought that you can only specify one intersection function, but > what would happen if you were to call pfIsectFunc twice with different > functions? > > The reason I ask is that I already have an intersection function for > our own motion models which is set up with pfIsectFunc, and uses > pfNodeIsectSegs. However we also make use of Vega Isector functions > elsewhere. Everything is Ok which makes me think I am wrong about > pfIsectFunc. Vega calls pfIsectFunc _only_ if an asynchronous isector process has been requested (and granted) through Vega. Otherwise, the intersection handling is done by Vega in a pre-sync callback (i.e., before pfSync). You must not have requested an asychronous isector process either in the application definition file (ADF) or by turning on the VGSYS_ISECTPROC property through API. If you did not, then you really do have only 1 intersection function registered through pfIsectFunc, that function being the one you registered yourself with your call to pfIsectFunc. Glad to hear "Everything is Ok"! :-) > Can anybody confirm whether I can set up a number of intersection > functions using pfIsectFunc (I know I should go and test it, but it's > almost time to leave!!) > > Thanks in advance (& forgive my ramblings - I've not got used to being > back at work yet). > > Regards. > > Mark. > -- > Mark Baranowski at work (baranowski@marklynn.demon.co.uk) > Pera, VR Division. Melton Mowbray, Leicestershire. UK. > Tel: +44 1664 501501, Fax: +44 1664 501553 > All opinions expressed are my own and should not be viewed > viewed as representing my employer unless stated otherwise. > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Mark Baranowski -- |---- Elizabeth Smith ----| | 972-960-2301 (voice) Paradigm Simulation, Inc. | | 972-960-9049 (FAX) 14900 Landmark, Suite 400 | | eliza@paradigmsim.com Dallas, Texas 75240 USA | | www.paradigmsim.com | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 13:36:29 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA15476; Mon, 6 Jan 1997 13:34:54 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA15460; Mon, 6 Jan 1997 13:34:53 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA27255; Mon, 6 Jan 1997 13:36:01 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA06323 for ; Mon, 6 Jan 1997 13:34:50 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA03720; Mon, 6 Jan 97 15:25:14 -0500 Date: Mon, 6 Jan 97 15:25:14 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701062025.AA03720@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: OpenGL vs Direct 3D comments Status: O Having seen the raging arguments on the usenet about OpenGL (hooray) versus Direct 3D (booo!), I'd strongly suggest that we try to keep the discussion out of the info-performer newsgroup by cutting off this thread asap. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 15:03:00 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA16084; Mon, 6 Jan 1997 15:00:40 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA16068; Mon, 6 Jan 1997 15:00:39 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA05254; Mon, 6 Jan 1997 15:01:47 -0800 Received: from dekalb.vf.mmc.com (dekalb.vf.mmc.com [192.35.35.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23926 for ; Mon, 6 Jan 1997 15:00:21 -0800 Received: from franklin.vf.lmco.com ([166.17.5.51]) by dekalb.vf.mmc.com (8.7.6/8.7.3) with ESMTP id SAA08134 for ; Mon, 6 Jan 1997 18:00:13 -0500 (EST) Received: from serling.motown.lmco.com (serling.motown.lmco.com [129.204.6.42]) by franklin.vf.lmco.com (8.7.6/8.7.3) with ESMTP id SAA10472 for ; Mon, 6 Jan 1997 18:00:13 -0500 (EST) Received: from tulip.motown.lmco.com (tulip [129.204.7.93]) by serling.motown.lmco.com (8.7.2/8.7.2) with ESMTP id SAA18108; Mon, 6 Jan 1997 18:00:10 -0500 (EST) From: David Higginbotham Received: (dhigginb@localhost) by tulip.motown.lmco.com (8.6.11/8.6.6) id SAA09455; Mon, 6 Jan 1997 18:00:09 -0500 Date: Mon, 6 Jan 1997 18:00:09 -0500 Message-Id: <199701062300.SAA09455@tulip.motown.lmco.com> To: info-performer@sgi.com Subject: Feedback Buffer Cc: dhigginb@motown.lmco.com, rrabbitz@motown.lmco.com Status: O Hi All, This isn't directly a Performer question, it pertains to the OpenGL feedback mode... We'd like to use feedback mode to support hardcopy by obtaining the graphic primitives via feedback and submitting the approprate printer commands (via PostScript or HGPL). When a feedback buffer becomes full rendering continues and only the data which initially fit into the buffer is available. We could re-render the items which didn't make it into the feedback buffer, but determining where we were in the render process when the buffer became full is prohibitively difficult. What would really help is immediate notification when the feedback buffer becomes full. We could dump the buffer to hardcopy then resume with an emptied buffer. Does anyone know if an immediate "buffer-full" notification mechanism exists; for example a callback or interrupt? Your help is appreciated! Dave ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 15:50:51 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA16374; Mon, 6 Jan 1997 15:48:59 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA16358; Mon, 6 Jan 1997 15:48:58 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA09752; Mon, 6 Jan 1997 15:50:01 -0800 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA05121 for ; Mon, 6 Jan 1997 15:48:49 -0800 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP (peer crosschecked as: uucp2.UU.NET [192.48.96.33]) id QQbxjr20674; Mon, 6 Jan 1997 18:48:45 -0500 (EST) Received: from ds9.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Mon, 6 Jan 1997 18:48:46 -0500 Received: from cavalier.cambridge.com by cambridge.com (4.1/SMI-4.1-SWS) id AA08947; Mon, 6 Jan 97 17:53:55 EST Received: by cavalier.cambridge.com (940816.SGI.8.6.9/SMI-4.1-SWS) id WAA21777; Mon, 6 Jan 1997 22:53:55 GMT From: gan@cavalier.cambridge.com (Gan Wang) Message-Id: <9701061753.ZM21775@cavalier> Date: Mon, 6 Jan 1997 17:53:54 -0500 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.com Subject: Process callbacks Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I wonder how and when exactly the user process callbacks set by pfChanTravFunc() are invoked. Are they before or after cleaning the tree and passing the data, etc, inside the pfFrame()? Since pfFrame() is called inside the APP process, would the return of pfAppFrame() wait for the return of the APP traversal? And, if pfAppFrame() is not called explicitly, say in post frame, would the return of pfFrame() wait for the return of pfAppFrame() or any of the callback functions (and the traversals) in CULL and DRAW processes if multiprocessing? A pseudocode would be greatly appreciated. Thanks, Gan -- Gan Wang Cambridge Research Associates Voice: 703-790-0505 ext.7210 1430 Spring Hill Road, Suite 200 Fax: 703-790-0370 McLean, VA 22102 E-mail: gan@cambridge.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 6 22:11:22 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id WAA17582; Mon, 6 Jan 1997 22:10:02 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id WAA17566; Mon, 6 Jan 1997 22:10:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id WAA26871; Mon, 6 Jan 1997 22:11:10 -0800 Received: from sable.nus.sg (sable.nus.sg [137.132.1.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA01986 for ; Mon, 6 Jan 1997 22:08:47 -0800 Received: from leonis.nus.sg (eng30228@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.8.4/8.6.9) with ESMTP id OAA16232 for ; Tue, 7 Jan 1997 14:06:16 +0800 (SST) Received: from localhost (eng30228@localhost) by leonis.nus.sg (8.8.4/8.6.9/CNS-3.5) with SMTP id OAA30810 for ; Tue, 7 Jan 1997 14:06:14 +0800 (SST) Date: Tue, 7 Jan 1997 14:06:13 +0800 (SST) From: LIM MING WAH To: info-performer@sgi.com Subject: Vertices Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Does performer have the ability to extract coordinates from stl formats? For example, the program uses pfdLoadFile to load in an stl file. I would want my program to be able to through a function list out the coordinates of the vertices. I have seen through the man pages of pfdLoadFile and pfdOpenFile and they don't seem to give a solution. ========================================================================== Jonathan Lim Ming Wah Department of Mechanical and Production Engineering Faculty of Engineering National University of Singapore ========================================================================== ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 01:04:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA17887; Tue, 7 Jan 1997 01:02:45 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA17871; Tue, 7 Jan 1997 01:02:44 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA02845; Tue, 7 Jan 1997 01:03:53 -0800 Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id BAA21301 for ; Tue, 7 Jan 1997 01:02:40 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-5.mail.demon.net id aa511602; 7 Jan 97 8:35 GMT From: Mark Baranowski To: info-vega@daisy.paradigmsim.com, info-performer@sgi.com Subject: Re: Intersection Question Date: Tue, 07 Jan 1997 08:35:49 GMT Organization: Pera Message-ID: <32d209b2.370190@post.demon.co.uk> References: <32d12482.27962537@post.demon.co.uk> <9701061503.ZM15897@daisy.paradigmsim.com> In-Reply-To: <9701061503.ZM15897@daisy.paradigmsim.com> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O On Mon, 6 Jan 1997 15:03:57 -0600, Elizabeth wrote: > >Vega calls pfIsectFunc _only_ if an asynchronous isector process >has been requested (and granted) through Vega. Otherwise, the >intersection handling is done by Vega in a pre-sync callback >(i.e., before pfSync). > >You must not have requested an asychronous isector process either in the >application definition file (ADF) or by turning on the VGSYS_ISECTPROC >property through API. If you did not, then you really do >have only 1 intersection function registered through pfIsectFunc, that >function being the one you registered yourself with your call to >pfIsectFunc. I do have the async intersection box checked in the ADF. So my question still remains: >> Can anybody confirm whether I can set up a number of intersection >> functions using pfIsectFunc=20 --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leicestershire. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 02:49:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA18214; Tue, 7 Jan 1997 02:47:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA18198; Tue, 7 Jan 1997 02:47:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA05586; Tue, 7 Jan 1997 02:49:02 -0800 Received: from server.artemedia.de (server.artemedia.de [194.221.74.66]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id CAA04014 for ; Tue, 7 Jan 1997 02:47:29 -0800 Received: from fitz (10.3.2.5) by jaco.artemedia.de (EMWAC SMTPRS 0.81) with SMTP id ; Tue, 07 Jan 1997 11:36:46 +0100 Sender: claude@artemedia.de Message-ID: <32D22726.41C6@artemedia.de> Date: Tue, 07 Jan 1997 11:36:22 +0100 From: Jean-Claude Bachmann Organization: ARTEMEDIA PRODUCTIONS GmbH X-Mailer: Mozilla 2.01 (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Simon Gibbs CC: info-performer@sgi.com Subject: Re: video textures with Sirius on iR References: <199701070945.KAA22587@viswiz.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Simon Gibbs wrote: > > > > > I am trying to get the example found under > > > > /usr/share/Performer/src/pguide/libpr/C/movietex.c > > > > to work with our Sirius board under Performer2.1 and OpenGL using an > > Infinite Reality. > > > > It must be a problem with your complile flags - I've had no problem > compiling here (an Onyx with two IR pipes, IRIX 6.2, Performer 2.1, > and Sirius boards on each pipe). > > Simon Gibbs It would be great if you are right. Did you compile the OpenGL version with make movietex.ogldso, without getting any errors? And did you define HAVE_VL in the source? You need that to compile with the video library calls enclosed (as you probably know anyway). If so could you send me your Makefile and the source from movietex.c. It may be that my sources got broken somehow, who knows. If you simply typed make you probably compiled the IrisGL version which is compilable on my machine as well. Anyway did you actually see live video coming from your Sirius board using movietex. I am asking because, all examples concerning animated textures using rgb files are working on my machine as well. These do not seem to be the problem. So if you do have a version which works, please send it to me, so I can take a look at it. Thanks J.C. -- ******************************************************************** * Artemedia GmbH | Tel.: +49 [0]30 25443 - 0 * * Jean-Claude Bachmann | Tel.: +49 0172 - 219 13 76 * * Budapesterstr. 40 | Fax.: +49 [0]30 25443 - 240 * * D-10787 Berlin | email: jean-claude.bachmann@artemedia.de * * Germany | Web Page http://www.artemedia.de * ******************************************************************** ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 03:51:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA18431; Tue, 7 Jan 1997 03:49:34 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA18415; Tue, 7 Jan 1997 03:49:33 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA07098; Tue, 7 Jan 1997 03:50:42 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id DAA12542 for ; Tue, 7 Jan 1997 03:49:30 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-10.mail.demon.net id aa1016006; 7 Jan 97 10:31 GMT From: Mark Baranowski To: info-vega@daisy.paradigmsim.com, info-performer@sgi.com Subject: Re: Intersection Question Date: Tue, 07 Jan 1997 10:31:36 GMT Organization: Pera Message-ID: <32d21ff6.6067385@post.demon.co.uk> References: <32d12482.27962537@post.demon.co.uk> <9701061503.ZM15897@daisy.paradigmsim.com> <32d209b2.370190@post.demon.co.uk> In-Reply-To: <32d209b2.370190@post.demon.co.uk> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O Aplologies for having a conversation with myself in public!!! On Tue, 07 Jan 1997 08:35:49 GMT, I wrote: >On Mon, 6 Jan 1997 15:03:57 -0600, Elizabeth wrote: > > >> >>Vega calls pfIsectFunc _only_ if an asynchronous isector process >>has been requested (and granted) through Vega. Otherwise, the >>intersection handling is done by Vega in a pre-sync callback >>(i.e., before pfSync). >> >>You must not have requested an asychronous isector process either in = the >>application definition file (ADF) or by turning on the VGSYS_ISECTPROC >>property through API. If you did not, then you really do >>have only 1 intersection function registered through pfIsectFunc, that >>function being the one you registered yourself with your call to >>pfIsectFunc. > >I do have the async intersection box checked in the ADF. So my >question still remains: > >>> Can anybody confirm whether I can set up a number of intersection >>> functions using pfIsectFunc=20 I just tested registering more than 1 intersection function and surprise surprise only the last function registered gets executed. This makes me worry that I have a timebomb waiting to go off in our Vega applications when using a separate intersection process. At the moment the only Vega intersection functions I can recall us using are some calls to vgPos & vgUpdate on an Isector and vgGetIsectHitObj. I register my intersection function after Vega is configured with vgConfigSys so would now expect that to replace the one registed by Vega - my function is being executed. I get a different pid for the intersection process so my request for a separate process is being granted. As I said before though, everything seems to work as expected, so am I worrying unnecessarily? My question seems to have become totally Vega oriented now so I will restrict any further postings to the Vega list. Regards, Mark. --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leicestershire. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 04:28:09 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA18553; Tue, 7 Jan 1997 04:26:53 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA18537; Tue, 7 Jan 1997 04:26:52 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA08235; Tue, 7 Jan 1997 04:28:01 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id EAA17187 for ; Tue, 7 Jan 1997 04:26:49 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-10.mail.demon.net id aa1015429; 7 Jan 97 12:10 GMT From: Mark Baranowski To: info-performer@sgi.com Subject: pfAllocIsectData Question Date: Tue, 07 Jan 1997 12:10:21 GMT Organization: Pera Message-ID: <32d23c30.13292010@post.demon.co.uk> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O Hi Where does pfAllocIsectData allocate from? Can the space allocated be safely accessed from other processes? TIA Mark. --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leicestershire. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 05:43:19 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA18743; Tue, 7 Jan 1997 05:42:06 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA18727; Tue, 7 Jan 1997 05:42:05 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA10230; Tue, 7 Jan 1997 05:43:14 -0800 Received: from ns.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA26397 for ; Tue, 7 Jan 1997 05:41:43 -0800 Received: by ns.fel.tno.nl; id OAA25729; Tue, 7 Jan 1997 14:48:10 +0100 (MET) Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2) id xma025717; Tue, 7 Jan 97 14:47:43 +0100 Received: (from rioj7@localhost) by s00sn1.fel.tno.nl (8.7.5/8.7.3) id OAA07319; Tue, 7 Jan 1997 14:32:29 +0100 (MET) From: Mario Veraart Message-Id: <199701071332.OAA07319@s00sn1.fel.tno.nl> Subject: Re: Turn off draw To: ofriels1@qmsmtpgw.mugu.navy.mil (SCOTT OFRIEL) Date: Tue, 7 Jan 1997 14:32:28 +0100 (MET) Cc: info-performer@sgi.com In-Reply-To: from "SCOTT OFRIEL" at Jan 6, 97 10:48:35 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Status: O > Can I just turn off graphics processing? We would like to do this when the > user iconifies the program. This way only the programs that are visible are > burdening the graphics. > Scott O' Make a call to pfChanTravMode(myChan,PFTRAV_DRAW,PFDRAW_OFF); to disable the drawing, use PFDRAW_ON to enable drawing again. Mario ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 06:15:49 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA18865; Tue, 7 Jan 1997 06:14:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA18849; Tue, 7 Jan 1997 06:14:15 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA11428; Tue, 7 Jan 1997 06:15:24 -0800 Received: from ns.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA00391 for ; Tue, 7 Jan 1997 06:13:46 -0800 Received: by ns.fel.tno.nl; id PAA27167; Tue, 7 Jan 1997 15:20:10 +0100 (MET) Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2) id xma027159; Tue, 7 Jan 97 15:19:50 +0100 Received: (from rioj7@localhost) by s00sn1.fel.tno.nl (8.7.5/8.7.3) id PAA08127; Tue, 7 Jan 1997 15:04:43 +0100 (MET) From: Mario Veraart Message-Id: <199701071404.PAA08127@s00sn1.fel.tno.nl> Subject: Re: Vertices To: eng30228@leonis.nus.sg (LIM MING WAH) Date: Tue, 7 Jan 1997 15:04:43 +0100 (MET) Cc: info-performer@sgi.com In-Reply-To: from "LIM MING WAH" at Jan 7, 97 02:06:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Status: O > Does performer have the ability to extract coordinates from stl formats? > For example, the program uses pfdLoadFile to load in an stl file. I would > want my program to be able to through a function list out the coordinates > of the vertices. I have seen through the man pages of pfdLoadFile and > pfdOpenFile and they don't seem to give a solution. > Jonathan Lim Ming Wah After loading the file with pfdLoadFile you get a pfNode * back. Just traverse this pointer till pfGset level or use pfPrint() with as much detail as possible. Mario ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 06:25:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA18926; Tue, 7 Jan 1997 06:24:13 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA18910; Tue, 7 Jan 1997 06:24:11 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA11958; Tue, 7 Jan 1997 06:25:21 -0800 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA01576 for ; Tue, 7 Jan 1997 06:24:09 -0800 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA19266; Tue, 7 Jan 1997 09:16:46 -0500 Received: by eagle.cae.ca (951211.SGI.8.6.12.PATCH1042/930416.SGI.AUTO) id JAA07890; Tue, 7 Jan 1997 09:15:31 -0500 From: "Bernard Leclerc" Message-Id: <9701070915.ZM7888@eagle.cae.ca> Date: Tue, 7 Jan 1997 09:15:28 -0500 In-Reply-To: Mark Baranowski "Re: Intersection Question" (Jan 7, 10:31am) References: <32d12482.27962537@post.demon.co.uk> <9701061503.ZM15897@daisy.paradigmsim.com> <32d209b2.370190@post.demon.co.uk> <32d21ff6.6067385@post.demon.co.uk> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Mark Baranowski Subject: Re: Intersection Question Cc: info-vega@daisy.paradigmsim.com, "S. Gottschalk" , info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Mark, I recall that in your original posting, you mentioned you wanted to do collision detection between objects. This is difficult to implement using Isectors. We've used a different approach based on Oriented Bounding Boxes as presented in a SIGGRAPH paper this summer. Contact S. Gottschalk at geom@cs.unc.edu for more info in the RAPID library. We've used it successfully on a research project requiring collision detection between complex shapes such as a space station, a shuttle, a satellite and connected bodies comprising the arms on both the shuttle and the space station. -- Bernard Leclerc CAE Electronics Ltd., 8585 Cote De Liesse Technical Leader Saint-Laurent, Quebec, Canada, H4L-4X4 3-D Graphics Applications tel: +1 514 341 2000 extension 2275 bleclerc@cae.ca fax: +1 514 340 5496 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 08:12:36 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA19232; Tue, 7 Jan 1997 08:11:21 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA19216; Tue, 7 Jan 1997 08:11:20 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA17945; Tue, 7 Jan 1997 08:12:29 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA18689 for ; Tue, 7 Jan 1997 08:11:17 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-9.mail.demon.net id aa919283; 7 Jan 97 15:29 GMT From: Mark Baranowski To: info-vega@daisy.paradigmsim.com, info-performer@sgi.com Subject: Re: Intersection Question Date: Tue, 07 Jan 1997 15:30:01 GMT Organization: Pera Message-ID: <32d36a6c.25117879@post.demon.co.uk> References: <32d12482.27962537@post.demon.co.uk> <9701061503.ZM15897@daisy.paradigmsim.com> <32d209b2.370190@post.demon.co.uk> <32d21ff6.6067385@post.demon.co.uk> <9701070915.ZM7888@eagle.cae.ca> In-Reply-To: <9701070915.ZM7888@eagle.cae.ca> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O On Tue, 7 Jan 1997 09:15:28 -0500, Bernard wrote: >Mark, I recall that in your original posting, you mentioned you wanted = to >do collision detection between objects. This is difficult to implement >using Isectors. We've used a different approach based on Oriented = Bounding >Boxes as presented in a SIGGRAPH paper this summer. Contact S. = Gottschalk >at geom@cs.unc.edu for more info in the RAPID library. We've used it >successfully on a research project requiring collision detection between >complex shapes such as a space station, a shuttle, a satellite and >connected bodies comprising the arms on both the shuttle and the space >station. > Who said I was using Isectors? :) I am actually basing it on the Rapid library developed by S. Gottschalk, but thanks anyway. Hmmmm...seeing as how you have already done all this, do you fancy saving me a lot of work? ;) (in my dreams....) Regards. Mark. --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leicestershire. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 09:59:26 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA19505; Tue, 7 Jan 1997 09:57:42 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA19489; Tue, 7 Jan 1997 09:57:41 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA26682; Tue, 7 Jan 1997 09:58:50 -0800 Received: from geordi.airinc.com (derrick.ott.hookup.net [165.154.43.219]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10605 for ; Tue, 7 Jan 1997 09:57:37 -0800 Received: from geordi by geordi.airinc.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA06180; Tue, 7 Jan 1997 12:47:03 -0500 Sender: prider@airinc.com Message-ID: <32D28C17.41C6@airinc.com> Date: Tue, 07 Jan 1997 12:47:03 -0500 From: Paul Rider Organization: Airborne Data Technologies X-Mailer: Mozilla 3.0 (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: "Performer mailing list." Subject: pfLPointState (and fading near envelope limits) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hey all, Situation: (building VASI, PAPI and their varients.) I've got two points occupying the same space but each is only visible when viewed within their vertical (and horiz) envelope. As soon as I pass the limit of one envelope I wish to have the other visible. This does happen, but as I approach the limit of the envelope the light intensity fades. I do not wish this to happen. Question: How/where can I specify that I don't want the point (pfLPointState) to fade as it nears the border(s) of it's envelope. ciao, Paul J. Rider. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 11:31:41 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA19836; Tue, 7 Jan 1997 11:30:13 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA19820; Tue, 7 Jan 1997 11:30:12 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA10927; Tue, 7 Jan 1997 11:30:08 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA21070; Tue, 7 Jan 1997 11:30:06 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701071930.LAA21070@remi.asd.sgi.com> Subject: Re: pfLPointState (and fading near envelope limits) To: prider@airinc.com (Paul Rider) Date: Tue, 7 Jan 1997 11:30:06 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: <32D28C17.41C6@airinc.com> from "Paul Rider" at Jan 7, 97 12:47:03 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 586 Status: O Hi, > > Situation: > (building VASI, PAPI and their varients.) > > I've got two points occupying the same space but each is only visible > when viewed within their vertical (and horiz) envelope. As soon as I > pass the limit of one envelope I wish to have the other visible. This > does happen, but as I approach the limit of the envelope the light > intensity fades. I do not wish this to happen. > > Question: > How/where can I specify that I don't want the point (pfLPointState) to > fade as it nears the border(s) of it's envelope. > Use a falloff (setShape) equal to 0. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 12:28:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA20035; Tue, 7 Jan 1997 12:26:43 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA20019; Tue, 7 Jan 1997 12:26:42 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA09768; Tue, 7 Jan 1997 12:27:51 -0800 Received: from Ballad.GSC.GTE.com (Ballad-se1.GSC.GTE.COM [192.31.1.201]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14984 for ; Tue, 7 Jan 1997 12:26:37 -0800 Received: from mtvex02.MTN-VIEW ("port 4422"@mtvex02.mtv.gtegsc.com) by Ballad.GSC.GTE.Com (PMDF V5.0-6 #18654) id <01IDXJL7GQD000097G@Ballad.GSC.GTE.Com> for info-performer@sgi.com; Tue, 07 Jan 1997 12:26:17 -0800 (PST) Received: by mtvex02.MTN-VIEW with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBFC95.EC345580@mtvex02.MTN-VIEW>; Tue, 07 Jan 1997 12:25:52 -0800 Date: Tue, 07 Jan 1997 13:22:00 -0800 From: Kaylor Brett Subject: pfHighlight crash To: Performer Group Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Status: O All, Before Christmas, I sent out a message about a pfHighlight crash. I haven't been able to fixed my problem yet. The problem is with pfHighlight on a MultiPipe REII. I am running 2 REII pipes, 2 4400 processors, Performer 2.0 with patch 1414 (using IRISGL), IRIX 5.3. The following is a change to perfly's main loop that duplicates the error. Adjusting the kFrameSkip from 2 to200 makes no difference. Following the code snip is the callstack. This only occurrs in MultiPipe mode. If anyone has any idea or perhaps a similiar configuration and can test this, it would be greatly appreciated. I just use a simple (50 polygon) textured model for perfly. Thanks a bunch. Brett. ============================================ Brett B. Kaylor Software Engineer GTE Government Systems 1805 West Drake Drive Tempe, AZ 85283 brett.kaylor@gsc.gte.com Tel: 602.777.1725 Fax: 602.777.1717 ============================================ ---------------------------------------------------------------------- ------ ------------------ /* Set the MP synchronization phase. */ pfPhase(ViewState->phase); pfHighlight* hl = new(pfGetSharedArena()) pfHighlight; hl->setMode(PFHL_FILL); hl->setColor(PFHL_FGCOLOR, 255.0f, 0.0f, 0.0f); hl->setAlpha(0.8f); int frameCnt = 0; int hlOn = 0; const int kFrameSkip = 10; /* Application main loop */ while (!SimDone()) { frameCnt++; if (frameCnt % kFrameSkip == 0) { if (hlOn) { hlOn = 0; pfuTravNodeHlight(ViewState->sceneGroup, PFHL_OFF); } else { hlOn = 1; pfuTravNodeHlight(ViewState->sceneGroup, hl); } } ... rest of regular perfly loop code. } ---------------------------------------------------------------------- ------ ------ drawX_FLAT_TRISTRIPS_NvVv() ["gststrip.C":732] pfHighlight::pr_hlFill() ["pfHighlight.C":943] pfHighlight::pr_draw() ["pfHighlight.C":784] pfGeoSet::pr_drawHlightOnly() ["gsdraw.C":4402] pfGeoSet::pr_drawHlighted() ["gsdraw.C":4348] genDrawGSet() ["gsdraw.C":4501] pfGeoSet::draw() ["pfGeoSet.C":1671] _pfCuller::popQuick() ["pfCuller.C":766] pfLayer::nb_cull() ["pfLayer.C":192] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfSCS::nb_cull() ["pfSCS.C":308] pfScene::nb_cull() ["pfScene.C":269] _pfCuller::nb_cull() ["pfCuller.C":197] beginDraw() ["pfProcess.C":3865] pfDraw() ["pfProcess.C":3897] DrawFunc() ["main.C":261] pfChannel::pf_callDrawFunc() ["pfChannel.C":1808] doDraw() ["pfProcess.C":3792] mpCullDraw() ["pfProcess.C":4278] pfConfig() ["pfProcess.C":1539] main() ["main.C":102] __start() ["crt1text.s":133] ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 15:05:49 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA20369; Tue, 7 Jan 1997 15:03:17 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA20353; Tue, 7 Jan 1997 15:03:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA22009; Tue, 7 Jan 1997 15:04:25 -0800 Received: from crdems.ge.com (crdems.GE.COM [192.35.44.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA20123 for ; Tue, 7 Jan 1997 15:03:06 -0800 Received: from bart.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA04015; Tue, 7 Jan 97 17:57:16 -0500 Received: from bart by bart.crd.ge.com (SMI-8.6/GE-CRD Standard Sendmail Version S1.5)id RAA11951; Tue, 7 Jan 1997 17:57:24 -0500 Sender: volpe@ash.crd.ge.com Message-Id: <32D2D4D4.1296@ash.crd.ge.com> Date: Tue, 07 Jan 1997 17:57:24 -0500 From: Christopher R Volpe Organization: GE Corporate Research & Development, Schenectady, NY X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: info-performer@sgi.com Subject: Sudden X/Performer problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi folks- I was in the middle of debugging a perf application (purely application-level changes, nothing specifically performer-related), when all of a sudden my app started dying upon startup with the following error: PF Warning/Internal(12): pfWindow::openNewNoPort() - null visual. X Error: 0 Request Major code 0 () Error Serial #33 Current Serial #15 Exit 1 I'm running Performer 2.1 on an Irix 6.2 InfiniteReality engine. Anyone have any ideas on what might be causing this? Thanks in advance. -Chris -- Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr@crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 15:46:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA20528; Tue, 7 Jan 1997 15:45:14 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA20512; Tue, 7 Jan 1997 15:45:14 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA25278; Tue, 7 Jan 1997 15:46:23 -0800 Received: from crdems.ge.com (crdems.GE.COM [192.35.44.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA29419 for ; Tue, 7 Jan 1997 15:45:08 -0800 Received: from bart.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA05003; Tue, 7 Jan 97 18:40:31 -0500 Received: from bart by bart.crd.ge.com (SMI-8.6/GE-CRD Standard Sendmail Version S1.5)id SAA12677; Tue, 7 Jan 1997 18:40:41 -0500 Sender: volpe@ash.crd.ge.com Message-Id: <32D2DEF9.7524@ash.crd.ge.com> Date: Tue, 07 Jan 1997 18:40:41 -0500 From: Christopher R Volpe Organization: GE Corporate Research & Development, Schenectady, NY X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: info-performer@sgi.com Subject: Re: Sudden X/Performer problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O I wrote: > > Hi folks- > I was in the middle of debugging a perf application (purely > application-level changes, nothing specifically performer-related), when > all of a sudden my app started dying upon startup with the following > error: [elided] Just a followup note: It dies within the pfInit() call. Any clues would be greatly appreciated. -Chris -- Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr@crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 17:16:59 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA20823; Tue, 7 Jan 1997 17:15:30 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA20807; Tue, 7 Jan 1997 17:15:29 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA01468; Tue, 7 Jan 1997 17:16:39 -0800 Received: from crdems.ge.com (crdems.GE.COM [192.35.44.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA17301 for ; Tue, 7 Jan 1997 17:15:26 -0800 Received: from bart.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA07540; Tue, 7 Jan 97 20:10:47 -0500 Received: from bart by bart.crd.ge.com (SMI-8.6/GE-CRD Standard Sendmail Version S1.5)id UAA14260; Tue, 7 Jan 1997 20:10:56 -0500 Sender: volpe@ash.crd.ge.com Message-Id: <32D2F420.52E9@ash.crd.ge.com> Date: Tue, 07 Jan 1997 20:10:56 -0500 From: Christopher R Volpe Organization: GE Corporate Research & Development, Schenectady, NY X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: info-performer@sgi.com Subject: More info on sudden problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Regarding my aforementioned X/Perf problem: Jeremy Friesner suggested that the problem may be linked to executable size. This appears to be the case. If I comment out a bunch of code in a routine that doesn't get called (at least not till long after the pfInit()), I can eliminate the startup problem. In fact, I can narrow it down to the presence or absence of something as small as a return statement. Not a specific return statement, though. Any of a number of them have this property. The common denominator seems to be the following: Whenever the executable is less then around 147K, it works. Whever it is greater than around 151K, it dies in pfInit(). The presence of a single return statement in a routine can cause the executable size to jump by that amount. I am building a 64-bit executable, BTW. -Chris -- Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr@crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 21:16:15 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id VAA21284; Tue, 7 Jan 1997 21:14:13 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id VAA21268; Tue, 7 Jan 1997 21:14:12 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id VAA12620; Tue, 7 Jan 1997 21:15:21 -0800 Received: from sable.nus.sg (sable.nus.sg [137.132.1.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA22663 for ; Tue, 7 Jan 1997 21:13:58 -0800 Received: from leonis.nus.sg (eng30228@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.8.4/8.6.9) with ESMTP id NAA14800 for ; Wed, 8 Jan 1997 13:13:55 +0800 (SST) Received: from localhost (eng30228@localhost) by leonis.nus.sg (8.6.10/8.6.9/CNS-3.5) with SMTP id NAA26200 for ; Wed, 8 Jan 1997 13:13:52 +0800 Date: Wed, 8 Jan 1997 13:13:52 +0800 (SST) From: LIM MING WAH To: info-performer@sgi.com Subject: Printing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Performer comes with pfuDrawMessage which prints a message on screen which is a character string. How do I enable it to print other types of variables such as integers of floating point numbers? ========================================================================== Jonathan Lim Ming Wah Department of Mechanical and Production Engineering Faculty of Engineering National University of Singapore ========================================================================== ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 22:06:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id WAA21425; Tue, 7 Jan 1997 22:04:00 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id WAA21409; Tue, 7 Jan 1997 22:04:00 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id WAA14058; Tue, 7 Jan 1997 22:05:09 -0800 Received: from cs.nps.navy.mil (cs.nps.navy.mil [131.120.1.13]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id WAA28630 for ; Tue, 7 Jan 1997 22:03:57 -0800 Received: from elsie.cs.nps.navy.mil ([131.120.7.8]) by cs.nps.navy.mil (4.1/SMI-4.1) id AA03239; Tue, 7 Jan 97 11:17:35 PST From: kapp@cs.nps.navy.mil (John Kapp) Received: by elsie.cs.nps.navy.mil (950413.SGI.8.6.12) id LAA23130; Tue, 7 Jan 1997 11:09:21 -0800 Date: Tue, 7 Jan 1997 11:09:21 -0800 Message-Id: <199701071909.LAA23130@elsie.cs.nps.navy.mil> To: info-performer@sgi.com Subject: Question: pfGetGSetAttrLists() Status: O I was hoping that there might be some good samaritan out there who might be able to shed some light on how the pfGetGSetAttrLists() function works or on why I might be having the problem I'm having. Some background: The following functions (updateLsd and setupLsd) attempt to locate 4 particular geosets and then retrieve the coordinates of their vertices. The model hierarchy is passed in as shipRoot. The model itself was built using MultiGen The Problem: A stand alone program was written and this code worked fine. However, the actual code has been inserted into a large networked battlefield simulation program. Now the pfGetGSetAttrLists() (line 30) causes a segmentation fault, as does any use of pfGeoSet functions (ie pfGetGSetAttrBind() or pfGetGSetAttrRange()) through the geo that was returned in line 18. Any ideas why? Our limited experience leads us to guess that there must be some attempt to access an area of memory that is preventing the pfGetGSetAttrLists(). Is this the right way to go about retrieving coordinates of geometry? Our goal is to overlay other geometry on that retrieved. We accomplished that in a stand alone and thought, much to our naivete, that we would just cut and paste. Thanks in Advance, Jack Kapp Erkan Akyuz ####################################################################### 1 void updateLsd(pfGroup* shipRoot) { 2 3 pfNode *monitor, *object; 4 pfGroup *cic; 5 pfGeode *lsd; 6 pfGeoSet *geo; 7 8 //Find CIC in ship model 9 object = pfFindNode(shipRoot, "CIC", pfGetGroupClassType()); 10 11 //cast object to pfGroup and assign to cic 12 cic=(pfGroup*)object; 13 14 // LSD's are children numbered 31 32 33 34 15 for(int i=31; i<=34; i++){ 16 monitor = pfGetChild(cic, i); 17 lsd = (pfGeode*)monitor; 18 geo = pfGetGSet(lsd, 0); 19 setupLsd(geo); 20 } 21 22 return; 23 } 24 25 void setupLsd(pfGeoSet* geo){ 26 27 pfVec3 *coords; 28 ushort *icoords; 29 30 pfGetGSetAttrLists(geo, PFGS_COORD3, (void**)&coords, &icoords); //******************************************************** . . . CODE USING coords . . . //******************************************************** return; } ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 23:31:22 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id XAA21587; Tue, 7 Jan 1997 23:29:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id XAA21571; Tue, 7 Jan 1997 23:29:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA16488; Tue, 7 Jan 1997 23:31:05 -0800 Received: from sable.nus.sg (sable.nus.sg [137.132.1.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA08326 for ; Tue, 7 Jan 1997 23:29:44 -0800 Received: from leonis.nus.sg (eng30228@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.8.4/8.6.9) with ESMTP id PAA21435 for ; Wed, 8 Jan 1997 15:29:25 +0800 (SST) Received: from localhost (eng30228@localhost) by leonis.nus.sg (8.6.10/8.6.9/CNS-3.5) with SMTP id PAA04537 for ; Wed, 8 Jan 1997 15:29:22 +0800 Date: Wed, 8 Jan 1997 15:29:22 +0800 (SST) From: LIM MING WAH To: info-performer@sgi.com Subject: Object data Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi all, I just used the function pfPrint to print out the data under the dcs that I am currently at and to my surprise, the coordinates that were printed for the object was the same although I had moved the object by the trackball movements. Why is this so? Can I update its position when I move it by the trackball and what is the method of only obtaining the coordinates only? I thought that when the dcs is moved, its position is automatically updated? ========================================================================== Jonathan Lim Ming Wah Department of Mechanical and Production Engineering Faculty of Engineering National University of Singapore ========================================================================== ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 7 23:50:54 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id XAA21719; Tue, 7 Jan 1997 23:49:04 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id XAA21703; Tue, 7 Jan 1997 23:49:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA16966; Tue, 7 Jan 1997 23:50:13 -0800 Received: from tri.kbs.co.kr (tri.kbs.co.kr [202.31.176.32]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA10891 for ; Tue, 7 Jan 1997 23:48:51 -0800 Received: from fortune.kbs.co.kr by tri.kbs.co.kr (8.6.12H1/8.6.4) id QAA00894; Wed, 8 Jan 1997 16:46:50 +0900 Message-ID: <32D35126.F65@tri.kbs.co.kr> Date: Wed, 08 Jan 1997 16:47:50 +0900 From: "Choi, Changrak" Reply-To: fortune@tri.kbs.co.kr Organization: Goddess of Fortune X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: Performer Submissions Subject: Can I get Alias file loader for Performer? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O I know that Alias file can't be imported in performer. If somebody made Alias file loader, I want to know how can i get it. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 00:45:07 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id AAA21877; Wed, 8 Jan 1997 00:43:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id AAA21861; Wed, 8 Jan 1997 00:43:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA19619; Wed, 8 Jan 1997 00:45:04 -0800 Received: from xr1.atlas.fr (xr1.atlas.fr [194.51.9.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA17648 for ; Wed, 8 Jan 1997 00:43:45 -0800 Message-Id: <199701080843.AAA17648@sgi.sgi.com> X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Wed, 8 Jan 1997 09:42:48 +0100 X400-Received: by mta xr1.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Wed, 8 Jan 1997 09:42:48 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; converted (ia5-text,iso (1) (0) (10021) (7) (1) (0) (1),iso (1) (0) (10021) (7) (1) (0) (6),iso (1) (0) (10021) (7) (1) (0) (100)); Relayed; Wed, 8 Jan 1997 09:42:37 +0100 X400-Received: by /PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/; Relayed; Wed, 8 Jan 1997 09:56:29 +0100 Date: Wed, 8 Jan 1997 09:56:29 +0100 X400-Originator: MICHAEL.BOCCARA@siege.aerospatiale.fr X400-Recipients: info-performer@sgi.com, guest@holodeck.csd.sgi.com X400-MTS-Identifier: [/PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/;970108085629] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: CSI NC V3.0 From: BOCCARA Michael To: "P=INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=guest(a)holodeck.csd.sgi" (Receipt Notification Requested) (Non Receipt Notification Requested), Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: RE: Printing MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Status: O =0C Just convert anything to a character string with mecanisms like i= ostreams or functions from stdio.h, and implement this chracter string in pfuDra= wMessage. Mike ____________________________________________________________________= ___________ _ De: P=3DINTERNET; DDA.TYPE=3DRFC-822; DDA.VALUE=3Dguest(a)holodeck.c= sd.sgi.com le Mer 8 Jan 1997 6:28 Objet: Printing A: P=3DINTERNET; DDA.TYPE=3DRFC-822; DDA.VALUE=3Dinfo-performer(a)sg= i.com; BOCCARA Michael Fichiers: BDY178.TXT RFC-822-Headers: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=3DUS-ASCII ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 01:59:16 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA22069; Wed, 8 Jan 1997 01:57:54 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA22053; Wed, 8 Jan 1997 01:57:53 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA21190; Wed, 8 Jan 1997 01:59:03 -0800 Received: from sirssg1.epfl.ch (sirssg1.epfl.ch [128.178.7.205]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA26360 for ; Wed, 8 Jan 1997 01:57:46 -0800 Received: (from tran@localhost) by sirssg1.epfl.ch (940816.SGI.8.6.9/8.6.12) id KAA00900 for info-performer@sgi.com; Wed, 8 Jan 1997 10:57:26 -0800 Date: Wed, 8 Jan 1997 10:57:26 -0800 From: Tran cong Tam Message-Id: <199701081857.KAA00900@sirssg1.epfl.ch> To: info-performer@sgi.com Subject: SIRIUS_BOARD Status: O Hi Performers and Happy new year I am an absolute beginner with SIRIUS board. Actually we can registe only 300 images each time, then rebegin next sequence ( 300 images ). The question is How can I registe 1500 images in one time. Your answer will be very appreciated. Thanks Tran /-------------------------------------------------------/ | TRAN | | IDERALPE Lausanne SWITZERLAND | | Email: tran@sirssg1.epfl.ch | /-------------------------------------------------------/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 02:21:58 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA22197; Wed, 8 Jan 1997 02:20:24 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA22181; Wed, 8 Jan 1997 02:20:23 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA21908; Wed, 8 Jan 1997 02:21:33 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA28938; Wed, 8 Jan 1997 02:20:20 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id KAA01232; Wed, 8 Jan 1997 10:20:18 GMT From: "Angus Dorbie" Message-Id: <9701081020.ZM1230@bitch.reading.sgi.com> Date: Wed, 8 Jan 1997 10:20:17 +0000 In-Reply-To: LIM MING WAH "Printing" (Jan 8, 1:13pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: LIM MING WAH , info-performer@sgi.com Subject: Re: Printing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O use sprintf On Jan 8, 1:13pm, LIM MING WAH wrote: > Subject: Printing > > Performer comes with pfuDrawMessage which prints a message on screen which > is a character string. How do I enable it to print other types of > variables such as integers of floating point numbers? > > > ========================================================================== > Jonathan Lim Ming Wah > Department of Mechanical and Production Engineering > Faculty of Engineering > National University of Singapore > ========================================================================== > > > > > > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from LIM MING WAH ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 02:26:49 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA22222; Wed, 8 Jan 1997 02:25:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA22206; Wed, 8 Jan 1997 02:25:46 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA21988; Wed, 8 Jan 1997 02:26:55 -0800 Received: from server.rtset.co.il ([194.90.96.254]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA29563 for ; Wed, 8 Jan 1997 02:25:38 -0800 Received: from rtset.co.il (jimbo.rtset.co.il [194.90.96.248]) by server.rtset.co.il (8.6.12/8.6.9) with ESMTP id MAA06763; Tue, 9 Jan 1996 12:38:56 +0200 Received: (from rany@localhost) by rtset.co.il (950413.SGI.8.6.12/950213.SGI.AUTOCF) id BAA05089; Wed, 8 Jan 1997 01:50:53 -0800 From: "Ran Yakir" Message-Id: <9701080150.ZM5087@jimbo.rtset.co.il> Date: Wed, 8 Jan 1997 01:50:53 -0800 In-Reply-To: kapp@cs.nps.navy.mil (John Kapp) "Question: pfGetGSetAttrLists()" (Jan 7, 11:09am) References: <199701071909.LAA23130@elsie.cs.nps.navy.mil> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: kapp@cs.nps.navy.mil (John Kapp) Subject: Re: Question: pfGetGSetAttrLists() Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Jack, You don't seem to be checking for a type of geode in the updateLsd function. What if the children of the CIC group are themselves groups and not geodes ? In that case you might get a pointer to an object which is not a geoset at all. Trying to access this geoset with geoset functions will do the job of core dumping. Ran On Jan 7, 11:09am, John Kapp wrote: > > The Problem: A stand alone program was written and this code worked fine. However, > the actual code has been inserted into a large networked battlefield simulation > program. Now the pfGetGSetAttrLists() (line 30) causes a segmentation fault, as does > any use of pfGeoSet functions (ie pfGetGSetAttrBind() or pfGetGSetAttrRange()) > through the geo that was returned in line 18. > > Any ideas why? > > Our limited experience leads us to guess that there must be some > attempt to access an area of memory that is preventing the pfGetGSetAttrLists(). > > Is this the right way to go about retrieving coordinates of geometry? Our goal is > to overlay other geometry on that retrieved. We accomplished that in a stand alone > and thought, much to our naivete, that we would just cut and paste. > > > Thanks in Advance, > > Jack Kapp > Erkan Akyuz > > ####################################################################### > > 1 void updateLsd(pfGroup* shipRoot) { > 2 > 3 pfNode *monitor, *object; > 4 pfGroup *cic; > 5 pfGeode *lsd; > 6 pfGeoSet *geo; > 7 > 8 //Find CIC in ship model > 9 object = pfFindNode(shipRoot, "CIC", pfGetGroupClassType()); > 10 > 11 //cast object to pfGroup and assign to cic > 12 cic=(pfGroup*)object; > 13 > 14 // LSD's are children numbered 31 32 33 34 > 15 for(int i=31; i<=34; i++){ > 16 monitor = pfGetChild(cic, i); > 17 lsd = (pfGeode*)monitor; > 18 geo = pfGetGSet(lsd, 0); > 19 setupLsd(geo); > 20 } > 21 > 22 return; > 23 } > 24 > 25 void setupLsd(pfGeoSet* geo){ > 26 > 27 pfVec3 *coords; > 28 ushort *icoords; > 29 > 30 pfGetGSetAttrLists(geo, PFGS_COORD3, (void**)&coords, &icoords); > -- __ | Ran Yakir /_) _ __ \ / _ / o __ | RT-SET Ltd. / )_ (_(_) ) \/ (_(_/<_(_)( | _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@rtset.co.il Work : 972-9-9552236 | rany@netvision.net.il Res. : 972-9-7489974 | Fax : 972-9-9552239 | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 03:45:16 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA22559; Wed, 8 Jan 1997 03:43:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA22543; Wed, 8 Jan 1997 03:43:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA23813; Wed, 8 Jan 1997 03:45:05 -0800 Received: from centaure.worldnet.net (centaure.worldnet.net [194.2.128.249]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA10195 for ; Wed, 8 Jan 1997 03:43:46 -0800 Received: from world-net.sct.fr (nantes0-015.sct.fr [194.206.158.15]) by centaure.worldnet.net (8.6.12/8.6.12) with SMTP id MAA06489 for ; Wed, 8 Jan 1997 12:43:41 +0100 Message-Id: <199701081143.MAA06489@centaure.worldnet.net> X-Sender: ceti@worldnet.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 08 Jan 1997 12:44:13 +0000 To: info-performer@sgi.com From: ceti Subject: Re: Object data Status: O >Hi all, > I just used the function pfPrint to print out the data under the >dcs that I am currently at and to my surprise, the coordinates that were >printed for the object was the same although I had moved the object by the >trackball movements. Why is this so? When moving using a DCS ( or whatever you wanted ) you move the object by pushing a transformation matrix ( scale , rotation, translation ) in the viewing stack. When rendering, the machine computes the new coordinates using object's ones and transfo matrix's ones to place polygons at their right place. The machine never replace objects coordinates at any time. ================================================================== _/_/ _/ _/_/_/ _/ _/ _/_/_/ _/_/_/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/_/_/ _/_/_/ _/ _/_/_/ _/_/_/ _/ _/ BILLARD Olivier - Ingineer R&D - C&I Software 1 avenue de la mer - 44380 PORNICHET - FRANCE Tel: +33 2 40 11 68 72 Fax: +33 2 40 61 68 14 Email: ceti@worldnet.net URL:http://www.worldnet.net/~ceti ================================================================= \\\|||/// \\ - - // ( @ @ ) +----------------oOOo-(_)-oOOo----------------------+ | " We don't inherit the world from our ancestors, | | it's only a loan from our children ." | | Antoine de Saint Exupery. | +-------------------------Oooo----------------------+ oooO ( ) ( ) ) / \ ( (_/ \_) ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 06:08:13 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA22874; Wed, 8 Jan 1997 06:06:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA22858; Wed, 8 Jan 1997 06:06:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA27895; Wed, 8 Jan 1997 06:08:07 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA26839 for ; Wed, 8 Jan 1997 06:06:55 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA09856; Wed, 8 Jan 1997 09:05:48 -0500 Date: Wed, 8 Jan 1997 09:05:48 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701080905.ZM9855@hotsauce.clubfed.sgi.com> In-Reply-To: "Choi, Changrak" "Can I get Alias file loader for Performer?" (Jan 8, 4:47pm) References: <32D35126.F65@tri.kbs.co.kr> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: fortune@tri.kbs.co.kr, Performer Submissions Subject: Re: Can I get Alias file loader for Performer? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O If you export an sla/stl file from studio then look in the sla directory of your project it will load into performer as well. I was able to get that to work without a problem. Brian On Jan 8, 4:47pm, Choi, Changrak wrote: > Subject: Can I get Alias file loader for Performer? > I know that Alias file can't be imported in performer. > If somebody made Alias file loader, I want to know > how can i get it. > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Choi, Changrak -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 07:39:41 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA23120; Wed, 8 Jan 1997 07:38:24 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA23104; Wed, 8 Jan 1997 07:38:24 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA02131; Wed, 8 Jan 1997 07:39:34 -0800 Received: from gauntlet.ht.com (he.ht.com [207.22.119.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA11684 for ; Wed, 8 Jan 1997 07:38:21 -0800 Received: by gauntlet.ht.com; id WAA08796; Thu, 9 Jan 1997 22:12:03 -0500 (EST) Received: from unknown(10.0.100.2) by gauntlet.ht.com via smap (3.2) id xma008778; Thu, 9 Jan 97 22:11:35 -0500 Received: from zr.ht.com by ht.com (950413.SGI.8.6.12/3.1.090690-High Techsplanations) id PAA28741; Wed, 8 Jan 1997 15:36:50 GMT Received: by zr.ht.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA00960; Wed, 8 Jan 1997 10:36:49 -0500 Date: Wed, 8 Jan 1997 10:36:49 -0500 From: david@ht.com (David Helfrick) Message-Id: <199701081536.KAA00960@zr.ht.com> To: info-performer@sgi.com Subject: Writing / executing Performer apps on the O2. Cc: david@ht.com Status: O We are expecting an O2 'any day', so a few issues come to mind. Currently, we are using Performer 2.0.2 under Irix 6.2. 1) Will our Performer apps run on the O2? Or in other words, does Performer 2.0.2 run on an O2? 2) If the answer(s) to 1) are "No", then is there a version of Performer that does run on an O2? If so, what is it...? 3) If there is an affirmative answer to 2), is a Performer version optimized for the O2 architecture? TIA for any help, especially for where, how, when, etc. to get info and/or software. ---- Dave Helfrick Addr: HT Medical, Inc. Email: david@ht.com 6001 MONTROSE ROAD Phone: 301-984-3706 / 800-929-4709 SUITE 902 Fax: 301-984-2104 ROCKVILLE, MD 20852 Web: http://www.ht.com/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 08:16:24 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA23255; Wed, 8 Jan 1997 08:14:46 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA23239; Wed, 8 Jan 1997 08:14:45 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA04780; Wed, 8 Jan 1997 08:15:55 -0800 Received: from geordi.airinc.com (derrick.ott.hookup.net [165.154.43.219]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA18581 for ; Wed, 8 Jan 1997 08:14:37 -0800 Received: from geordi by geordi.airinc.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA08429; Wed, 8 Jan 1997 11:03:28 -0500 Sender: prider@airinc.com Message-ID: <32D3C54F.167E@airinc.com> Date: Wed, 08 Jan 1997 11:03:27 -0500 From: Paul Rider Organization: Airborne Data Technologies X-Mailer: Mozilla 3.0 (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: David Helfrick CC: info-performer@sgi.com Subject: Re: Writing / executing Performer apps on the O2. References: <199701081536.KAA00960@zr.ht.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O David Helfrick wrote: > > We are expecting an O2 'any day', > so a few issues come to mind. > Hey, > Currently, we are using Performer 2.0.2 under > Irix 6.2. > > 1) Will our Performer apps run on the O2? > Or in other words, does Performer 2.0.2 run > on an O2? I'm not sure if 2.0.2 does, but we're running performer libs at 2.0.3 on ours BTW:(in response to your question 2, and 3) performer runs optimally regardless of which sgi it's on. hope this helps, Paul J. Rider. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 08:59:40 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA23401; Wed, 8 Jan 1997 08:58:14 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA23385; Wed, 8 Jan 1997 08:58:13 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA08368; Wed, 8 Jan 1997 08:59:24 -0800 Received: from alpha.luc.ac.be (alpha.luc.ac.be [193.190.2.30]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA27712 for ; Wed, 8 Jan 1997 08:58:08 -0800 Received: from donald.luc.ac.be by alpha.luc.ac.be; (5.65v3.2/1.1.8.2/28Jul95-1212AM) id AA28633; Wed, 8 Jan 1997 17:59:05 +0100 Sender: brassaer@luc.ac.be Message-Id: <32D3D1BD.41C6@luc.ac.be> Date: Wed, 08 Jan 1997 17:56:29 +0100 From: Bruno Rassaerts Organization: Expertisecentrum Digitale Media X-Mailer: Mozilla 3.01Gold (X11; I; IRIX64 6.2 IP19) Mime-Version: 1.0 To: info-performer@sgi.com Subject: pfGeoSet with PFGS_POLYS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi, In a Performer program that I'm working on, I need pfGeoSets with the PFGS_POLYS flag. When creating a geoset like this I fill in the lengths array with the correct number of vertices for each polygon. The problem is that perfly crashes on these geosets. I tried other sample programs and they seem to work. For testing purposes I created a geoset with triangles but still used the PFGS_POLYS flag and create a lengths array with all the values set to 3. The perfly program still crashes on the geoset. When I change the primtype flag to PFGS_TRIS without changing anything else perfly seems to work just fine. My code looks like this: /******************************/ create coords array, create lengths array (shared arena) geode = pfNewGeode (); gset = pfNewGSet (arena); pfGSetAttr (gset, PFGS_COORD3, PFGS_PER_VERTEX, coords, NULL); pfGSetPrimLengths (gset, lengths); pfGSetNumPrims (gset, lengthsCount); pfGSetPrimType (gset, PFGS_POLYS); pfAddGSet (geode, gset); pfAddChild (parent, geode); /******************************/ I am sure that the coords and lengths arrays are correct. I checked them using pfPrint. I was wondering if one should do something extra when using PFGS_POLYS. Perfly crashes in the following functions. (Note: I did not change the perfly program, this is the standard version.) 0 cacheTri(_pfTriCache*,pfVec3&,pfVec3&,pfVec3&)(0x1810b780, 0x38d81970, 0xd3c3c460, 0x180f8f48) ["../../../lib/libpr/pfGeoSet.C":2142, 0x61eb38] 1 pfGeoSet::pr_computeCache(void)(0x180d8dd0, 0x38d81970, 0xd3c3c460, 0x180f8f48) ["../../../lib/libpr/pfGeoSet.C":2304, 0x629fc0] 2 pfGeoSet::setIsectMask(unsigned int,int,int)(0x180d8dd0, 0xffffffff, 0xb0, 0x2) ["../../../lib/libpr/pfGeoSet.C":1359, 0x6288dc] 3 pfGeode::nb_setTravMask(int,unsigned int,int,int)(0x180d0720, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGeode.C":505, 0x4fa25c] 4 pfGroup::nb_setTravMask(int,unsigned int,int,int)(0x180d6c20, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGroup.C":478, 0x4fd50c] 5 pfGroup::nb_setTravMask(int,unsigned int,int,int)(0x180d06a0, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGroup.C":478, 0x4fd50c] 6 pfGroup::nb_setTravMask(int,unsigned int,int,int)(0x180f2b30, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGroup.C":478, 0x4fd50c] 7 pfGroup::nb_setTravMask(int,unsigned int,int,int)(0x180d8d40, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGroup.C":478, 0x4fd50c] 8 pfNodeTravMask(0x180d8d40, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/cNode.C":37, 0x540370] 9 pfuCollideSetup(0x180d8d40, 0x0, 0xffffffff, 0x180f8f48) ["../../../lib/libpfutil/collide.c":80, 0x4aef98] 10 InitScene(0x1810b780, 0x38d81970, 0xd3c3c460, 0x180f8f48) ["../../../../../sample/apps/C/common/generic.c":342, 0x461e48] 11 main(0x4, 0x7fff2f44, 0xd3c3c460, 0x180f8f48) ["../../../../../sample/apps/C/common/main.c":104, 0x4613a0] 12 __start() ["crt1text.s":133, 0x4612ac] bye, -- // Bruno Rassaerts - EDM (Expertisecentrum Digitale Media) ('> Wetenschapspark 2 - B-3590 Diepenbeek - Tel: +32-(0)11268411 /rr Fax: +32-(0)11269400 - eMail: brassaer@luc.ac.be *\))_ URL: http://www.luc.ac.be/~brassaer/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 09:20:59 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA23502; Wed, 8 Jan 1997 09:19:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA23486; Wed, 8 Jan 1997 09:19:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA10237; Wed, 8 Jan 1997 09:20:44 -0800 Received: from cs.nps.navy.mil (cs.nps.navy.mil [131.120.1.13]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA02407 for ; Wed, 8 Jan 1997 09:19:32 -0800 Received: from gravy5.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA03587; Wed, 8 Jan 97 09:17:35 PST From: kapp@cs.nps.navy.mil (John Kapp) Received: by gravy5.cs.nps.navy.mil (950215.SGI.8.6.10) id JAA05205; Wed, 8 Jan 1997 09:17:34 -0800 Date: Wed, 8 Jan 1997 09:17:34 -0800 Message-Id: <199701081717.JAA05205@gravy5.cs.nps.navy.mil> To: info-performer@sgi.com Subject: pfGetGSetAttrLists() Problem SOlved Status: O Thanks to everyone who looked at the pfGetGSetAttrLists() problem I posted. The experts have spoken and the answers we got all pointed out the problem. We did not have what we thought we had. What we thought was pfGeode was in fact pfGroup. We were led to believe it was pfGeode because we queried it with pfGetNumGSets() and the expected number 1 was returned. Unfortunately, we took this as good enough and never tested pfGetTypeName() or pfIsExactType() which probably would have led us to the answer we got from the mailing list. The loading of the model within the simulation was different, adding levels of nodes. We're tracking it down but it appears that it is the result of the implementation of a PVS algorithm or possibly to allow for manipulation of objects. Thanks to everyone who reviewed our problem! Jack Kapp kapp@cs.nps.navy.mil ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 09:35:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA23577; Wed, 8 Jan 1997 09:33:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA23561; Wed, 8 Jan 1997 09:33:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA11673; Wed, 8 Jan 1997 09:34:44 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA05605; Wed, 8 Jan 1997 09:33:30 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA01727; Wed, 8 Jan 1997 17:33:23 GMT From: "Angus Dorbie" Message-Id: <9701081733.ZM1725@bitch.reading.sgi.com> Date: Wed, 8 Jan 1997 17:33:23 +0000 In-Reply-To: Paul Rider "Re: Writing / executing Performer apps on the O2." (Jan 8, 11:03am) References: <199701081536.KAA00960@zr.ht.com> <32D3C54F.167E@airinc.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Paul Rider , David Helfrick Subject: Re: Writing / executing Performer apps on the O2. Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 8, 11:03am, Paul Rider wrote: > BTW:(in response to your question 2, and 3) > performer runs optimally regardless of which sgi it's on. Such faith :-) There are probably some O2 specific optimisations which could be done but it's still your best route. You may want to do stuff like modify the texture filters to point sampled MIPmapped min and point sampled mag and reduce blended transparency, perhaps just use glalphafunc to cull transparent pixels on 'cookiecut' style textures. These should go a long way towards improving fill performance. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 10:10:51 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA23783; Wed, 8 Jan 1997 10:09:23 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA23767; Wed, 8 Jan 1997 10:09:22 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA14516; Wed, 8 Jan 1997 10:10:32 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13493; Wed, 8 Jan 1997 10:09:19 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA01804; Wed, 8 Jan 1997 18:09:16 GMT From: "Angus Dorbie" Message-Id: <9701081809.ZM1802@bitch.reading.sgi.com> Date: Wed, 8 Jan 1997 18:09:15 +0000 In-Reply-To: "Angus Dorbie" "Re: Writing / executing Performer apps on the O2." (Jan 8, 5:33pm) References: <199701081536.KAA00960@zr.ht.com> <32D3C54F.167E@airinc.com> <9701081733.ZM1725@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Paul Rider , David Helfrick Subject: Re: Writing / executing Performer apps on the O2. Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 8, 5:33pm, Angus Dorbie wrote: > There are probably some O2 specific optimisations which could be done > but it's still your best route. > From guest Wed Jan 8 10:14:58 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA23811; Wed, 8 Jan 1997 10:13:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA23795; Wed, 8 Jan 1997 10:13:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA14805; Wed, 8 Jan 1997 10:15:07 -0800 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14623 for ; Wed, 8 Jan 1997 10:13:55 -0800 Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbxqe24754; Wed, 8 Jan 1997 13:13:53 -0500 (EST) Received: from ds9.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 8 Jan 1997 13:13:54 -0500 Received: from octave.cambridge.com by cambridge.com (4.1/SMI-4.1-SWS) id AA16872; Wed, 8 Jan 97 13:04:29 EST Received: by octave.cambridge.com (940816.SGI.8.6.9/SMI-4.1-SWS) id SAA13844; Wed, 8 Jan 1997 18:04:29 GMT From: "Fred Clyne" Message-Id: <9701081304.ZM13842@octave> Date: Wed, 8 Jan 1997 13:04:29 -0500 In-Reply-To: Christopher R Volpe "Sudden X/Performer problem" (Jan 7, 5:57pm) References: <32D2D4D4.1296@ash.crd.ge.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Christopher R Volpe , uunet.uu.net!uunet!sgi.com!info-performer Subject: Re: Sudden X/Performer problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 7, 5:57pm, Christopher R Volpe wrote: > Subject: Sudden X/Performer problem > Hi folks- > I was in the middle of debugging a perf application (purely > application-level changes, nothing specifically performer-related), when > all of a sudden my app started dying upon startup with the following > error: > > PF Warning/Internal(12): pfWindow::openNewNoPort() - null visual. > X Error: 0 > Request Major code 0 () > Error Serial #33 > Current Serial #15 > Exit 1 > > I'm running Performer 2.1 on an Irix 6.2 InfiniteReality engine. Anyone > have any ideas on what might be causing this? > > Thanks in advance. > > -Chris > -- > > Chris Volpe Phone: (518) 387-7766 > GE Corporate R&D Fax: (518) 387-6560 > PO Box 8 Email: volpecr@crd.ge.com > Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Christopher R Volpe >From the Performer 2.2 Beta Release Notes: o 6.2 OS bug with shared arena placement An obscure bug in IRIX 65.2 with default placement of the shared arena can cause programs to die due to lack of heap space for malloc. Typcially the program will die during X or GL initialization with a message like [what you stated above]. WAR: through the environment variable PFSHAREDBASE or in with pfSharedArenaBase() before pfInit(), explicitly set the address of the arena so that it is not too close to the heap and does not collide with other DSOs. An address that has worked with programs exhibiting the problem that are very close to perfly is: 0x18000000. ex: pfSharedArenaBase(0x18000000); or setenv PFSHAREDBASE 0x18000000 If this address is not sufficient, run again with par [they had an example earlier: par -s -i -SS prog options] and the following environment variables set: setenv _RLD_PATH /usr/lib/rld.debug; setenv _RLD_ARGS -v and redirect all output to a file. Look for the addresses of the mmap() calls and of address of DSO load actions to find a free address range in which to place the arena. Compiling with some libraries statically can make this operation easier. Whew! I hope I don't run into this bug. Hope this helps. -- Fred Clyne Cambridge Research Associates office: 703-790-0505 x 7211 1430 Spring Hill Road, Suite 200 fax: 703-790-0370 McLean, VA 22102 email: fred@cambridge.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 10:47:05 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA24035; Wed, 8 Jan 1997 10:45:25 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA24019; Wed, 8 Jan 1997 10:45:24 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA17469; Wed, 8 Jan 1997 10:46:34 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22382 for ; Wed, 8 Jan 1997 10:45:23 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA01533; Wed, 8 Jan 1997 10:45:18 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA27964; Wed, 8 Jan 1997 10:45:20 -0800 From: "Sharon Clay" Message-Id: <9701081045.ZM27962@rose.asd.sgi.com> Date: Wed, 8 Jan 1997 10:45:20 -0800 In-Reply-To: david@ht.com (David Helfrick) "Writing / executing Performer apps on the O2." (Jan 8, 10:36am) References: <199701081536.KAA00960@zr.ht.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: david@ht.com (David Helfrick), info-performer@sgi.com Subject: Re: Writing / executing Performer apps on the O2. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 8, 10:36am, David Helfrick wrote: > Subject: Writing / executing Performer apps on the O2. ->Cc: david@ht.com -> ->We are expecting an O2 'any day', ->so a few issues come to mind. -> ->Currently, we are using Performer 2.0.2 under ->Irix 6.2. -> ->1) Will our Performer apps run on the O2? -> Or in other words, does Performer 2.0.2 run -> on an O2? Yes. We tested on O2 before releasing the 2.0.2 patches. 2.0.2 specifically knows about O2. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 11:01:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA24163; Wed, 8 Jan 1997 10:59:12 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA24147; Wed, 8 Jan 1997 10:59:11 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA18921; Wed, 8 Jan 1997 11:00:21 -0800 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26109 for ; Wed, 8 Jan 1997 10:59:04 -0800 Received: from sgi.sgi.com by relay2.UU.NET with SMTP (peer crosschecked as: SGI.COM [192.48.153.1]) id QQbxqh01788; Wed, 8 Jan 1997 13:58:44 -0500 (EST) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26003; Wed, 8 Jan 1997 10:58:42 -0800 Received: from giraffe.asd.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA04209; Wed, 8 Jan 1997 10:58:41 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA02542; Wed, 8 Jan 1997 10:58:38 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA28019; Wed, 8 Jan 1997 10:58:38 -0800 From: "Sharon Clay" Message-Id: <9701081058.ZM28017@rose.asd.sgi.com> Date: Wed, 8 Jan 1997 10:58:38 -0800 In-Reply-To: "Fred Clyne" "Re: Sudden X/Performer problem" (Jan 8, 1:04pm) References: <32D2D4D4.1296@ash.crd.ge.com> <9701081304.ZM13842@octave> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Fred Clyne" , Christopher R Volpe , uunet.uu.net!uunet!sgi.com!info-performer Subject: Re: Sudden X/Performer problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 8, 1:04pm, Fred Clyne wrote: -> ->On Jan 7, 5:57pm, Christopher R Volpe wrote: ->> Subject: Sudden X/Performer problem ->> Hi folks- ->> I was in the middle of debugging a perf application (purely ->> application-level changes, nothing specifically performer-related), when ->> all of a sudden my app started dying upon startup with the following ->> error: ->> ->> PF Warning/Internal(12): pfWindow::openNewNoPort() - null visual. ->> X Error: 0 ->> Request Major code 0 () ->> Error Serial #33 ->> Current Serial #15 ->> Exit 1 ->> ->> I'm running Performer 2.1 on an Irix 6.2 InfiniteReality engine. Anyone ->> have any ideas on what might be causing this? ->> [ ... ] -> ->>From the Performer 2.2 Beta Release Notes: -> ->o 6.2 OS bug with shared arena placement -> -> An obscure bug in IRIX 65.2 with default placement of the shared arena -> can cause programs to die due to lack of heap space for malloc. -> Typcially the program will die during X or GL initialization with -> a message like [what you stated above]. It is easy enough to see if you are being bit by this. Run your program through par: par -s -i -SS prog [options] and see if you get messages in the output about brk failing due to lack of space. If you do, then this is your beast. -> ->WAR: through the environment variable PFSHAREDBASE or in with -> pfSharedArenaBase() before pfInit(), explicitly set the address of the -> arena so that it is not too close to the heap and does not collide -> with other DSOs. An address that has worked with programs exhibiting -> the problem that are very close to perfly is: 0x18000000. FYI, I added the PFSHAREDBASE when I ran into this problem so it isn't in currently released versions of Performer -- you have to use the API, or else a tricky rld WAR from Don Hatch - contact us for more info. -> -> ex: pfSharedArenaBase(0x18000000); or -> setenv PFSHAREDBASE 0x18000000 -> -> If this address is not sufficient, run again with par [they had an -> example earlier: par -s -i -SS prog options] and the following -> environment variables set: -> setenv _RLD_PATH /usr/lib/rld.debug; setenv _RLD_ARGS -v -> and redirect all output to a file. Look for the addresses of the -> mmap() calls and of address of DSO load actions to find a free -> address range in which to place the arena. Compiling with some -> libraries statically can make this operation easier. -> ->Whew! I hope I don't run into this bug. Hope this helps. -> ->-- -> ->Fred Clyne -> ->Cambridge Research Associates office: 703-790-0505 x 7211 ->1430 Spring Hill Road, Suite 200 fax: 703-790-0370 ->McLean, VA 22102 email: fred@cambridge.com -> Thanx! src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 10:55:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA24060; Wed, 8 Jan 1997 10:51:15 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA24044; Wed, 8 Jan 1997 10:51:14 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA18100; Wed, 8 Jan 1997 10:52:23 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23810 for ; Wed, 8 Jan 1997 10:51:12 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA02017; Wed, 8 Jan 1997 10:51:01 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA28003; Wed, 8 Jan 1997 10:50:49 -0800 From: "Sharon Clay" Message-Id: <9701081050.ZM28001@rose.asd.sgi.com> Date: Wed, 8 Jan 1997 10:50:49 -0800 In-Reply-To: Bruno Rassaerts "pfGeoSet with PFGS_POLYS" (Jan 8, 5:56pm) References: <32D3D1BD.41C6@luc.ac.be> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: Bruno Rassaerts , info-performer@sgi.com Subject: Re: pfGeoSet with PFGS_POLYS Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19701081050.ZM28001.asd.sgi.com" Status: O -- --PART-BOUNDARY=.19701081050.ZM28001.asd.sgi.com Content-Type: text/plain; charset=us-ascii +>---- On Jan 8, 5:56pm, Bruno Rassaerts wrote: > Subject: pfGeoSet with PFGS_POLYS -> ->Hi, -> ->In a Performer program that I'm working on, I need pfGeoSets with ->the PFGS_POLYS flag. When creating a geoset like this I fill in ->the lengths array with the correct number of vertices for each ->polygon. The problem is that perfly crashes on these geosets. I ->tried other sample programs and they seem to work. -> ->For testing purposes I created a geoset with triangles but still ->used the PFGS_POLYS flag and create a lengths array with all the ->values set to 3. The perfly program still crashes on the geoset. ->When I change the primtype flag to PFGS_TRIS without changing ->anything else perfly seems to work just fine. By any chance are yu running Performer 2.0 with no Performer patches? This smells like a bug that we fixed in the 2.0.2 patches (1347 and 1392) and fixed in 2.1. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ --PART-BOUNDARY=.19701081050.ZM28001.asd.sgi.com Content-Description: Message from Bruno Rassaerts Content-Type: message/rfc822 Received: from giraffe.asd.sgi.com by rose.asd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA27776; Wed, 8 Jan 1997 09:27:35 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id JAA25874; Wed, 8 Jan 1997 09:27:32 -0800 Received: from giraffe.asd.sgi.com by rose.asd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA27773; Wed, 8 Jan 1997 09:27:32 -0800 Received: from holodeck.csd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id JAA25863; Wed, 8 Jan 1997 09:27:26 -0800 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA23401; Wed, 8 Jan 1997 08:58:14 -0800 Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA23385; Wed, 8 Jan 1997 08:58:13 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA08368; Wed, 8 Jan 1997 08:59:24 -0800 Received: from alpha.luc.ac.be (alpha.luc.ac.be [193.190.2.30]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA27712 for ; Wed, 8 Jan 1997 08:58:08 -0800 Received: from donald.luc.ac.be by alpha.luc.ac.be; (5.65v3.2/1.1.8.2/28Jul95-1212AM) id AA28633; Wed, 8 Jan 1997 17:59:05 +0100 Sender: brassaer@luc.ac.be Message-Id: <32D3D1BD.41C6@luc.ac.be> Date: Wed, 08 Jan 1997 17:56:29 +0100 From: Bruno Rassaerts Organization: Expertisecentrum Digitale Media X-Mailer: Mozilla 3.01Gold (X11; I; IRIX64 6.2 IP19) Mime-Version: 1.0 To: info-performer@sgi.com Subject: pfGeoSet with PFGS_POLYS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, In a Performer program that I'm working on, I need pfGeoSets with the PFGS_POLYS flag. When creating a geoset like this I fill in the lengths array with the correct number of vertices for each polygon. The problem is that perfly crashes on these geosets. I tried other sample programs and they seem to work. For testing purposes I created a geoset with triangles but still used the PFGS_POLYS flag and create a lengths array with all the values set to 3. The perfly program still crashes on the geoset. When I change the primtype flag to PFGS_TRIS without changing anything else perfly seems to work just fine. My code looks like this: /******************************/ create coords array, create lengths array (shared arena) geode = pfNewGeode (); gset = pfNewGSet (arena); pfGSetAttr (gset, PFGS_COORD3, PFGS_PER_VERTEX, coords, NULL); pfGSetPrimLengths (gset, lengths); pfGSetNumPrims (gset, lengthsCount); pfGSetPrimType (gset, PFGS_POLYS); pfAddGSet (geode, gset); pfAddChild (parent, geode); /******************************/ I am sure that the coords and lengths arrays are correct. I checked them using pfPrint. I was wondering if one should do something extra when using PFGS_POLYS. Perfly crashes in the following functions. (Note: I did not change the perfly program, this is the standard version.) 0 cacheTri(_pfTriCache*,pfVec3&,pfVec3&,pfVec3&)(0x1810b780, 0x38d81970, 0xd3c3c460, 0x180f8f48) ["../../../lib/libpr/pfGeoSet.C":2142, 0x61eb38] 1 pfGeoSet::pr_computeCache(void)(0x180d8dd0, 0x38d81970, 0xd3c3c460, 0x180f8f48) ["../../../lib/libpr/pfGeoSet.C":2304, 0x629fc0] 2 pfGeoSet::setIsectMask(unsigned int,int,int)(0x180d8dd0, 0xffffffff, 0xb0, 0x2) ["../../../lib/libpr/pfGeoSet.C":1359, 0x6288dc] 3 pfGeode::nb_setTravMask(int,unsigned int,int,int)(0x180d0720, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGeode.C":505, 0x4fa25c] 4 pfGroup::nb_setTravMask(int,unsigned int,int,int)(0x180d6c20, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGroup.C":478, 0x4fd50c] 5 pfGroup::nb_setTravMask(int,unsigned int,int,int)(0x180d06a0, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGroup.C":478, 0x4fd50c] 6 pfGroup::nb_setTravMask(int,unsigned int,int,int)(0x180f2b30, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGroup.C":478, 0x4fd50c] 7 pfGroup::nb_setTravMask(int,unsigned int,int,int)(0x180d8d40, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/pfGroup.C":478, 0x4fd50c] 8 pfNodeTravMask(0x180d8d40, 0x0, 0xffffffff, 0xb0) ["../../../lib/libpf/cNode.C":37, 0x540370] 9 pfuCollideSetup(0x180d8d40, 0x0, 0xffffffff, 0x180f8f48) ["../../../lib/libpfutil/collide.c":80, 0x4aef98] 10 InitScene(0x1810b780, 0x38d81970, 0xd3c3c460, 0x180f8f48) ["../../../../../sample/apps/C/common/generic.c":342, 0x461e48] 11 main(0x4, 0x7fff2f44, 0xd3c3c460, 0x180f8f48) ["../../../../../sample/apps/C/common/main.c":104, 0x4613a0] 12 __start() ["crt1text.s":133, 0x4612ac] bye, -- // Bruno Rassaerts - EDM (Expertisecentrum Digitale Media) ('> Wetenschapspark 2 - B-3590 Diepenbeek - Tel: +32-(0)11268411 /rr Fax: +32-(0)11269400 - eMail: brassaer@luc.ac.be *\))_ URL: http://www.luc.ac.be/~brassaer/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com --PART-BOUNDARY=.19701081050.ZM28001.asd.sgi.com-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 12:31:09 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA24565; Wed, 8 Jan 1997 12:29:40 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA24549; Wed, 8 Jan 1997 12:29:39 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA26616; Wed, 8 Jan 1997 12:30:50 -0800 Received: from physics.ucla.edu (physics.ucla.edu [128.97.23.13]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA18356 for ; Wed, 8 Jan 1997 12:29:37 -0800 Received: from scotch.physics.ucla.edu by physics.ucla.edu (SMI-8.6/SMI-SVR4) id MAA03214; Wed, 8 Jan 1997 12:29:32 -0800 Received: (from chris@localhost) by scotch.physics.ucla.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA16664 for info-performer@sgi.com; Wed, 8 Jan 1997 12:47:16 -0800 Date: Wed, 8 Jan 1997 12:47:16 -0800 From: chris@scotch.physics.ucla.edu (chris) Message-Id: <199701082047.MAA16664@scotch.physics.ucla.edu> To: info-performer@sgi.com Subject: pfFlatten Status: O Hi all. Hope some helpful soul can point me in the right direction. The scs->flatten(0) below causes a bus error. The weird thing is that this code is functionally identical to perfly.C around line 315. The only difference I can see is that the call to scs->addChild() in perfly adds a pfGroup, whereas mine adds a pfLOD. Does that matter? I'm using performer 2.1 on an Indigo2 Max Impact. My code: pfLOD* V = makeLODs(arena); pfMatrix scsMat; pfVec3 veci,vecf,trans; pfSCS* scs; veci.set(0.f,1.f,0.f); for(j=0,i=0;jaddChild(V); scs->flatten(FLATTEN_MODE); scs->removeChild(V); dcsmom->addChild(scs); pfDelete(scs); i+=3; } Perfly code: 297 if (ViewState->explode > 0.0f) 298 { 299 float x; 300 float y; 301 float z; 302 pfMatrix matrix; 303 pfSCS *scs; 304 305 x = ViewState->explode*((random() & 0xffff)/65535.0f - 0.5f); 306 y = ViewState->explode*((random() & 0xffff)/65535.0f - 0.5f); 307 z = ViewState->explode*((random() & 0xffff)/65535.0f - 0.5f); 308 309 /* move the object by placing it beneath an SCS node */ 310 matrix.makeTrans(x, y, z); 311 scs = new pfSCS(matrix); 312 scs->addChild(root); 313 314 /* go ahead and apply the SCS matrix to the geometry */ 315 scs->flatten(0); 316 317 /* detach (transformed) object from SCS; discard SCS */ 318 scs->removeChild(root); 319 pfDelete(scs); 320 } Thanks for any help. I really appreciate it. Chris Chris Mitchell UCLA Physics Department LAPD Plasma Lab 310-206-1772 chrism@ucla.edu http://scotch.physics.ucla.edu/~chris ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 17:08:34 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA25246; Wed, 8 Jan 1997 17:07:10 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA25230; Wed, 8 Jan 1997 17:07:09 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA19332; Wed, 8 Jan 1997 17:08:20 -0800 Received: from tri.kbs.co.kr (tri.kbs.co.kr [202.31.176.32]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17634 for ; Wed, 8 Jan 1997 17:07:01 -0800 Received: from kpc26.kbs.co.kr by tri.kbs.co.kr (8.6.12H1/8.6.4) id KAA08431; Thu, 9 Jan 1997 10:06:16 +0900 Date: Thu, 9 Jan 1997 10:06:16 +0900 Message-Id: <199701090106.KAA08431@tri.kbs.co.kr> X-Sender: ycyoon@tri.kbs.co.kr X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.com From: "YOON, YEO CHEON" Subject: Registing electronic forum for IRIS Performer Status: O Hi. I want to regist to electronic forum for dicussing of IRIS Performer including technical and non-technical issues. ================================================= E-mail address : ycyoon@tri.kbs.co.kr YOON, YEO CHEON Technical Research Institute, KBS, #18, Yoido-Dong, Youngdeungpo-Gu, Seoul, 150-790, Korea, [Telephone] 82-2-781-5972 [FAX] 82-2-781-5999 ================================================ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 8 17:37:31 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA25392; Wed, 8 Jan 1997 17:35:50 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA25376; Wed, 8 Jan 1997 17:35:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA21507; Wed, 8 Jan 1997 17:37:00 -0800 Received: from yacko.csd.sgi.com ([150.166.145.94]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA22694 for ; Wed, 8 Jan 1997 17:35:49 -0800 Received: from localhost by yacko.csd.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id RAA03066; Wed, 8 Jan 1997 17:35:45 -0800 Message-Id: <199701090135.RAA03066@yacko.csd.sgi.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Tran cong Tam cc: info-performer@sgi.com Subject: Re: SIRIUS_BOARD In-reply-to: Your message of "Wed, 08 Jan 1997 10:57:26 PST." <199701081857.KAA00900@sirssg1.epfl.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Jan 1997 17:35:44 -0800 From: Eric Kunze Status: O > Actually we can registe only 300 images each time, > then rebegin next sequence ( 300 images ). > > The question is How can I registe 1500 images in > one time. I'm assuming that you mean capture to disk. If you are trying to capture 1500 frames to disk, you are going to be constrained by your disk bandwidth. Unless you have high disk bandwidth, you will need to break up your captures into smaller chunks. For a list of the bandwidth required, see the sirius (7) man page towards the end. If you are capturing off of tape, a possible way to work this out is to use Videomedia's VLAN deck control to break your capture into smaller bits. Eric ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 9 03:24:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA26160; Thu, 9 Jan 1997 03:23:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA26144; Thu, 9 Jan 1997 03:23:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA11341; Thu, 9 Jan 1997 03:24:00 -0800 Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id DAA11162 for ; Thu, 9 Jan 1997 03:22:39 -0800 Received: from helios (actually helios.tnt.uni-hannover.de) by mgate with SMTP (PP); Thu, 9 Jan 1997 12:21:53 +0100 Received: from chopin by helios (SMI-8.6/SMI-SVR4) id MAA29497; Thu, 9 Jan 1997 12:21:01 +0100 Sender: schulze@helios Message-ID: <32D4D49A.41C6@tnt.uni-hannover.de> Date: Thu, 09 Jan 1997 12:20:58 +0100 From: Peter Schulze Organization: Universitaet Hannover, Theoretische Nachrichtentechnik X-Mailer: Mozilla 2.01S (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: info-performer@sgi.com Subject: pfLayer & overlapping geometry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi performers, I'm using a modell containing a structure of 3 layers. This structure shares 1 large geometry and 3 textures (RGB). Each layer got a separate value for the transparency-material-component to support a blending of the different textures. -->When I take a look on the modell from a bird's-eye-view (no overlapping parts of geometry) all the textures are rendered in the right order, inclusive blending. -->But when I take a side view and there exist some geometry parts overlapped by others in the foreground (and both surface normals point to the eye) only the texture of the base-layer will be rendered on the geometry of the foreground, INSTEAD of the texture of the decal-layer. -->When I enable only one of the 3 layers everything works fine(side view). To avoid this failure I changed pfLayerMode and pfChanBinOrder but without success. Does anybody know what's going wrong ? Peter ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 9 03:57:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA26263; Thu, 9 Jan 1997 03:55:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA26247; Thu, 9 Jan 1997 03:55:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA12051; Thu, 9 Jan 1997 03:56:58 -0800 Received: from MOEsun.edu.tw (moesun.edu.tw [140.111.1.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA15735 for ; Thu, 9 Jan 1997 03:54:39 -0800 Received: from nchc.gov.tw (dns.nchc.gov.tw [140.110.192.11]) by MOEsun.edu.tw (8.6.13/8.6.13) with SMTP id TAA20619 for ; Thu, 9 Jan 1997 19:56:30 +0800 Received: by nchc.gov.tw (th3.8s.nchc.gov) from ceres.nchc.gov.tw id AA04453; Thu, 9 Jan 97 19:39:24 CST Received: by ceres.nchc.gov.tw (station v4.0) id AA27239; Thu, 9 Jan 97 19:53:09 CST From: a00chc00@nchc.gov.tw (Charlie H. Chang) Message-Id: <9701091153.AA27239@ceres.nchc.gov.tw> Subject: update coord via network To: info-performer@sgi.com Date: Thu, 9 Jan 1997 19:53:08 +0800 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 594 Status: O Hi there, I am trying to read the coordination data from other device(radar) on the network passed to my Performer program, and then update the position of an airplane. Is there any example that I can follow? I guess there some performance issue like keeping the other simulation process running while waiting for data from networks... Thank you in advance. --------------------------------------------------------------- Charlie H. Chang (ext 209) E-mail: a00chc00@nchc.gov.tw National Center for High-performance Computing Scientific Visualization and Interactive Media Lab ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 9 10:40:00 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA26882; Thu, 9 Jan 1997 10:21:46 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA26866; Thu, 9 Jan 1997 10:21:45 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA02882; Thu, 9 Jan 1997 10:22:52 -0800 Received: from mailhost.multigen.com (mailhost.multigen.com [204.119.69.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25913 for ; Thu, 9 Jan 1997 10:21:13 -0800 Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [204.119.70.10]) by mailhost.multigen.com (8.6.11/8.6.12) with ESMTP id KAA02622 for ; Thu, 9 Jan 1997 10:26:49 -0800 Received: from vaisyas.engr.multigen.com (vaisyas.engr.multigen.com [204.119.70.76]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id SAA10027 for ; Thu, 9 Jan 1997 18:18:23 GMT Received: (from marcus@localhost) by vaisyas.engr.multigen.com (950413.SGI.8.6.12/8.6.12) id KAA08283 for info-performer@sgi.com; Thu, 9 Jan 1997 10:25:42 -0800 From: "Marcus Barnes" Message-Id: <9701091025.ZM8282@vaisyas.engr.multigen.com> Date: Thu, 9 Jan 1997 10:25:42 -0800 In-Reply-To: Peter Schulze "pfLayer & overlapping geometry" (Jan 9, 12:20pm) References: <32D4D49A.41C6@tnt.uni-hannover.de> Organization: MultiGen Inc. X-Phones: 1-408-556-2654 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Re: pfLayer & overlapping geometry Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 9, 12:20pm, Peter Schulze wrote: > Subject: pfLayer & overlapping geometry > Hi performers, > I'm using a modell containing a structure of 3 layers. > This structure shares 1 large geometry and 3 textures (RGB). > Each layer got a separate value for the transparency-material-component ^^^^^ ^^^^^^^^^^^^ ... important clues. 1. pfLayer attempts to impose a well defined draw ordering of its children. 2. Transparent geometry is CULL sorted separately from opaque geometry. > to support a blending of the different textures. > > -->But when I take a side view and there exist some geometry parts > overlapped by others in the foreground (and both surface normals point > to the eye) only the texture of the base-layer will be rendered on the > geometry of the foreground, INSTEAD of the texture of the decal-layer. > > Does anybody know what's going wrong ? pfLayer draw ordering does not work correctly when the pfLayer's decal geometry has transparency enabled. There is a conflict between the transparency sort and the pfLayer logic. This is a known Performer bug. Regards. -- + Marcus Barnes, Technical Staff mailto:marcus@multigen.com + + Multigen Inc. http://www.multigen.com + + 550 S. Winchester Blvd. phoneto:1-408-556-2654 + + Suite 500 San Jose CA 95128 faxto:1-408-261-4102 + ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 9 20:30:16 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id UAA27858; Thu, 9 Jan 1997 20:10:27 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id UAA27842; Thu, 9 Jan 1997 20:10:26 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id UAA14676; Thu, 9 Jan 1997 20:11:27 -0800 Received: from systech.hinet.net (systech.hinet.net [168.95.200.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA25380 for ; Thu, 9 Jan 1997 20:09:35 -0800 Received: by systech.hinet.net (931110.SGI/930416.SGI.AUTO) for info-performer@sgi.com id AA16153; Fri, 10 Jan 97 12:10:50 -0800 From: "Jim" Message-Id: <9701101210.ZM16151@systech.hinet.net> Date: Fri, 10 Jan 1997 12:10:26 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.com Subject: Difference between O-GL & Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi Performer: Would anybody be able to tell me - what is the difference of graphical and CPU load between the same Open-GL app. and Performer app. cheer and a bright new year! -- Jim Tsai Software Engineer Visual Simulation sec. System & Technology Corp. Taipei Email : jim@systech.hinet.net Tel: 886-2-6981599 Fax: 886-2-6981211 Address: 18F-5, No. 79, Hsin Tai Wu Road, Sec. 1, Hsi-chih, Taipei Hsien, Taiwan, R.O.C. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 9 21:10:02 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id VAA28004; Thu, 9 Jan 1997 21:07:34 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id VAA27988; Thu, 9 Jan 1997 21:07:32 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id VAA20410; Thu, 9 Jan 1997 21:07:17 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id VAA05108; Thu, 9 Jan 1997 21:07:16 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701100507.VAA05108@remi.asd.sgi.com> Subject: Re: Difference between O-GL & Performer To: jim@systech.hinet.net (Jim) Date: Thu, 9 Jan 1997 21:07:16 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: <9701101210.ZM16151@systech.hinet.net> from "Jim" at Jan 10, 97 12:10:26 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 905 Status: O > > Hi Performer: > Would anybody be able to tell me - what is the difference of graphical > and CPU load between the same Open-GL app. and Performer app. > Performer is a layer on top of OpenGL (or IrisGL). It is dedicated to real-time visualisation, and handle multiprocessing, multi-channel, multi-pipe ... Performer knows about reading a database, OpenGL does not know what a file is. So the 'same application' on top of OpenGL would have include a lot of code to do what Performer does, and would necessitate a lot of knowledge of how to use openGL and IRIX to get the best performance out of an SGI. Unless the application is not a VisSim application ;-) Best Regards _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ Have a look at the web below for more information ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 9 21:38:03 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id VAA28144; Thu, 9 Jan 1997 21:36:21 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id VAA28128; Thu, 9 Jan 1997 21:36:20 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id VAA17513; Thu, 9 Jan 1997 21:37:22 -0800 Received: from matsumura.nsg.sgi.com ([155.11.119.16]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA07819 for ; Thu, 9 Jan 1997 21:36:08 -0800 Received: by matsumura.nsg.sgi.com (950413.SGI.8.6.12/930416.SGI) for info-performer@sgi.com id OAA23730; Fri, 10 Jan 1997 14:36:07 +0900 From: "Matsumura Makoto" Message-Id: <9701101436.ZM23728@matsumura.nsg.sgi.com> Date: Fri, 10 Jan 1997 14:36:06 +0900 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: setmon&screensize Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi,all. one of my customer want to change vfo in doing his presentation, eg: start presentation with 1280x1024_60 and change to 640x480_120s and go back. it is basically ok with setmon command, however there is a problem, when the video format is changed , it is not always full screen. i.e. we can move mouse cursor beyond the bottom/right of display. is there any good way to make the display area full screen in this situation. I'd like to avoid stopgfx/startgfx if possible. wow/wow2 does this, i think. Thanks In Advance. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 9 21:49:48 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id VAA28205; Thu, 9 Jan 1997 21:47:44 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id VAA28189; Thu, 9 Jan 1997 21:47:41 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id VAA21677; Thu, 9 Jan 1997 21:47:26 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id VAA05467; Thu, 9 Jan 1997 21:47:25 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701100547.VAA05467@remi.asd.sgi.com> Subject: Re: setmon & screen To: matumura@matsumura.nsg.sgi.com (Matsumura Makoto) Date: Thu, 9 Jan 1997 21:47:25 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: <9701101433.ZM23691@matsumura.nsg.sgi.com> from "Matsumura Makoto" at Jan 10, 97 02:33:24 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 867 Status: O > > one of my customer want to change vfo > in doing his presentation, eg: > start presentation with 1280x1024_60 > and change to 640x480_120s and go back. > > it is basically ok with setmon command, however > there is a problem, when the video format is changed > , it is not always full screen. > i.e. > we can move mouse cursor beyond the bottom/right of display. > > is there any good way to make the display area full screen > in this situation. I'd like to avoid stopgfx/startgfx if possible. > > wow/wow2 does this, i think. > > Thanks In Advance. > If you are on RE2, there is the -m option of setmon that let you specifie the the area that the X server should manage. Hope this helps _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 9 22:18:44 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id WAA28383; Thu, 9 Jan 1997 22:17:10 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id WAA28367; Thu, 9 Jan 1997 22:17:09 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id WAA18621; Thu, 9 Jan 1997 22:18:11 -0800 Received: from sable.nus.sg (sable.nus.sg [137.132.1.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA13085 for ; Thu, 9 Jan 1997 22:16:27 -0800 Received: from leonis.nus.sg (eng30228@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.8.4/8.6.9) with ESMTP id OAA14384 for ; Fri, 10 Jan 1997 14:15:54 +0800 (SST) Received: from localhost (eng30228@localhost) by leonis.nus.sg (8.6.10/8.6.9/CNS-3.5) with SMTP id OAA19559 for ; Fri, 10 Jan 1997 14:15:53 +0800 Date: Fri, 10 Jan 1997 14:15:53 +0800 (SST) From: LIM MING WAH To: info-performer@sgi.com Subject: Isect? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi all, Is it true that isect is not enable during trackball mode? ========================================================================== Jonathan Lim Ming Wah Department of Mechanical and Production Engineering Faculty of Engineering National University of Singapore ========================================================================== ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 9 23:47:50 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id XAA28534; Thu, 9 Jan 1997 23:46:28 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id XAA28518; Thu, 9 Jan 1997 23:46:27 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA21218; Thu, 9 Jan 1997 23:47:29 -0800 Received: from teil.soft.net (tata_elxsi.soft.net [164.164.10.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA24127 for ; Thu, 9 Jan 1997 23:44:53 -0800 Received: by teil.soft.net (940816.SGI.8.6.9/940406.SGI) id NAA05540; Fri, 10 Jan 1997 13:10:22 -0530 Date: Fri, 10 Jan 1997 13:03:47 -0530 (IST) From: IRIS Performer user group To: info-performer@sgi.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi all, On RE2, setmon gives problem for the sterio viewing. If I use 'setmon STR_RECT', the currsor just disappears. This does not happen when I use 'setmon STR_BOT/STR_TOP'. I just know that it has somthing to do with XDisplay mannager not knowing the new display settings. In that case how to solve the problem. Even if I re-start the graphics, i.e. display manager etc this does not work. Secondly what is differences in new style stereo modes and old style stereo modes. See /usr/gfx/ucode/RE/dg2/vof/README Thanks a lot Sunil Hadap Tata Elxsi (India) Ltd. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 01:38:59 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA28801; Fri, 10 Jan 1997 01:37:13 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA28785; Fri, 10 Jan 1997 01:37:12 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA25740; Fri, 10 Jan 1997 01:38:14 -0800 Received: from alpha.luc.ac.be (alpha.luc.ac.be [193.190.2.30]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id BAA07059 for ; Fri, 10 Jan 1997 01:36:56 -0800 Received: from donald.luc.ac.be by alpha.luc.ac.be; (5.65v3.2/1.1.8.2/28Jul95-1212AM) id AA18927; Fri, 10 Jan 1997 10:28:08 +0100 Sender: brassaer@luc.ac.be Message-Id: <32D60B0B.41C6@luc.ac.be> Date: Fri, 10 Jan 1997 10:25:31 +0100 From: Bruno Rassaerts Organization: Expertisecentrum Digitale Media X-Mailer: Mozilla 3.01Gold (X11; I; IRIX64 6.2 IP19) Mime-Version: 1.0 To: info-performer@sgi.com Subject: PFGS_POLYS problem Content-Type: multipart/mixed; boundary="------------167E2781446B" Status: O This is a multi-part message in MIME format. --------------167E2781446B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I know now the the problem that I had with perfly is caused by a bug in Performer 2.0 and that this problem is fixed in 2.0.2. But I stumbled on something else that's weird. In my application I want to draw a polygon with 5 vertices. The geoset of this polygon looks like this (printed with pfPrint) -------- GeoSet: 0x180998e0 { Primitive: PFGS_POLYS, NON-INDEXED, pfPrims=1, glPrims=3, verts=5 Attribute Bindings: PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_PRIM PFGS_TEXCOORD2=PFGS_OFF Attribute List Pointers: PFGS_COORD3: 0x180a5130 PFGS_COLOR4: 0x0 PFGS_NORMAL3: 0x180a5450 PFGS_TEXCOORD2: 0x0 Attribute Index List Pointers: PFGS_COLOR4: 0x0 PFGS_NORMAL3: 0x0 PFGS_TEXCOORD2: 0x0 PFGS_COORD3: 0x0 Strip Lengths: 5 Prim Normal 0: NX: 0.000000 NY: -1.000000 NZ: 0.000000 Coord 0: X: -1.750000 Y: 0.000000 Z: -1.300000 Coord 1: X: 0.800000 Y: 0.000000 Z: -0.950000 Coord 2: X: 1.550000 Y: 0.000000 Z: 0.700000 Coord 3: X: -1.300000 Y: 0.000000 Z: 1.650000 Coord 4: X: -2.350000 Y: 0.000000 Z: 0.600000 } GeoSet: 0x180998e0 -------- The problem that Performer draws this polygon with a hole in it. I attached a small picture (4k) that shows this problem. (Sorry for putting a binary on the mailing list but is was hard to explain otherwise) The polygon was highlighted with PFHL_LINES so that you can see the edges. Note: I am still using Performer 2.0 on an ONYX RE2 IRIX 6.2 Thanks, -- // Bruno Rassaerts - EDM (Expertisecentrum Digitale Media) ('> Wetenschapspark 2 - B-3590 Diepenbeek - Tel: +32-(0)11268411 /rr Fax: +32-(0)11269400 - eMail: brassaer@luc.ac.be *\))_ URL: http://www.luc.ac.be/~brassaer/ --------------167E2781446B Content-Type: image/jpeg; name="snap.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="snap.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD//gBIQ1JFQVRPUjogWFYgVmVyc2lvbiAzLjEwYSAgUmV2 OiAxMi8yOS85NCAgUXVhbGl0eSA9IDc1LCBTbW9vdGhpbmcgPSAwCv/bAEMACAYGBwYFCAcH BwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0 Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMv/AABEIAJEAmwMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAA AAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFla Y2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPE xcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAA AAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APPKKKK8 A9sKKKKACiip7OzuNQvYbO1jMk8zhI0HcnpQIv8Ah/w3qfia+NppsHmMgDSOThUGcZJrc1H4 W+LNPLEaeLpB/HbSB8/gcN+lWfH2u23w28Ijwbo0qtreoR7tTuUPMakfdHpkEgeg56tmvKNI 8deKtCCrpuv38MajasRmLxgf7jZX9K9GGDjy+9ucM8W+b3djo7qyu7GXyry1mt5P7s0ZQ/ka grc0/wDaA8SpD9n1mw03V4D98TQ7Gb/vn5f/AB2tiL4ifC/Xfk1bwvdaRK/Hm2eCideflI/9 ANRLBP7LLjjF9pHF0V6BF4X8BeIMHw743gjkY4WC+wrE+gDbD3HY1DqHwl8U2YD20NtfxEZD 20w6fRsE/hmueWHqx6G0a9OXU4Wir1/ouqaU23UNPurUnp50TKD9CR7iqNYtNbmqd9gooooG FFFFABRRRQAtFFFABRRRQAV6RpjWnwv8GP4s1WNX1q+Qx6XauORkfePtggn0GB1OKzvAPhyz uPtHiXX3SHQtMBd3kOFkcdF9wMjjuSBzmvNPiB42vPHXiaXUp90dqmY7S3zxFHnjPP3j1J9f YCu/CUP+XkvkcWJrfYRz+pajd6vqVxqF/O891cOZJZHPLE/56dqq0UV6BwhRRRQAVraT4n17 QmzpWsXtn6rDMyqfqM4NZNFAHqGl/HzxpYx+XePY6nH3+1W4Bx6ZTb+ua3Yfix4E1tiPEXgk 2zscmawcEn3ONh9O5rxKik4qW6GpNbM98h0v4Ya+oOk+MTp0rAnytQwoHt8wX/0I068+EOvJ EZ9NubHUoeqmGXaWH48dMd68Bq5p+rajpM3nabf3VnL/AH7eZoyec9j7CsJYWlLpY2jiai6n pGpeGNd0jJv9Ju4EBwZGiJT/AL6HH61k1Po3xv8AHGkbFfUo7+JT9y9iDk/8CGG/Wumh+Nfh zV/l8UeB7aRm5e4s2G8njsQCOn9+ueWB/lZtHGfzI5Kiug8Y2Gm2Otx/2SssVpcWsNytvMCH g3qDsbJOTjB6/wAWO1c/XFKLi3FnZGSkk0FFFFSUFbXhbw3deKdch062BVT800uMiJB1J/kP cisq2tpry5itraJpZpWCIiDJYnoBXdeNNah+Ffg4eGdMmDeJNUjEl5cxnmBDxwfzA/FuOK3w 9H2ktdjCvV9nHzOb+L3jW2lMfgnw6RHommnZMUP+vmU85PcA/m2T2FeTUUV7CVtEeW3cKKKK ACiirENjdXGPKgdge+MD86TaWrGk3sV6K0J9Gu7e1adwuF6qpyQPWs+lGcZaxY5RlHdBRRRV EhRRRQAV0HgnQl8ReLrCxmH+iB/Ou27LAg3SH/vkEfUiufr0bwNANL8F67rbDE9866XbNnkL xJMcfQIv/AjUzlyRcioR5pKJPreqS61rV5qU3D3Ehfb/AHR2UewGB+FUKKK8Ju7uz2ErKwUU V2fgHwxb6tc3GsauyxaJpg825d+jkDO33GOT7cd6qEHOXKhSkoq7NTQI7L4d+D5PG+tQrJfT jy9LtXzlmIOD04JAJz2X64rwfV9Wvdd1a51TUZjNd3LmSVyMZP0HQDoB7V2PxB8Sap8QfErX aQSQ6ZbgxWMMmFCJxliPVsAn8B2rn4fDZ6zzge0Y/qa9SM6VGPLc86UKlWXNYwafHDLM22KN nPoozXWQ6NYw4/c7z6uc/p0q8qqgwqhR6AYrKWNX2UaRwj+0zlYdCvZcFlWIf7Z5/IVow+HI VwZpnf2UbRW1RXPLFVJdbG8cNTj0uVodPtLf/V26A+pGT+ZqzRRXO5N6tm6SWwEAjB5Fcnq+ mmym8yMfuHPH+yfSusqOeCO5gaKQZVhWtCs6Ur9DKtSVSNupwtFWL20ksrloX57q3qPWq9ew mmro8tpp2YUUUUxAASQAMk9BXrfiG1GiW2leGkbP9mWoE+O9xJ+8k/IsF/4DXH/DnTob7xpa T3a5sdODX9z/ALkXzAY77m2r/wACrbvryXUL+4vZ23TXErSufVmOT/OuLGztFR7nXhIXk5Fe iiivNPQCvS/hwIdd8L+IvCzLGtzcRefbsQAWYccn0DBT+JrzWt3wbrX9geLNO1Bm2wpKEmJ/ 55t8rH8Ac/hWlKSjNX2M6kXKLsYRUqxVgQRwQe1JXY/E3Rho/jW6MagQXgF1HgcfNnd/48D+ dcfUzi4ycWVGXMk0JRS0VJQlFLRQAlFLRQAlFLR0GTQBR1KwS+tipwJF5RvT/wCtXHEYOK2t Y1czlra3b910Zx/F7fSsWvWwsJxh7x5mJnGUvdCiipIIJbq4it4ULyyuERR1ZicAfnXSc56N 4YtP7H+G9xfsu261y68iIn/n3hwXx9ZCo/4BVOt3xR5dpeWuhwFTBo1slkCowHkXmR8e7ljW HXj4mfPUbPVoQ5YISilorA2CiiikB6Z4gUeKPhNpOtqd13pLG1uMD+Hhecf9sz/wI15nXonw ru47y41Twvdvi21S2cIPRwO3vtyf+AiuDv7KXTtQubKcYlt5WifjuDitqvvJT+X3GNP3W4Fe iiisTYKKKKACiiigArnNZ1fzN1rbt8nR3Hf2FO1jV9261tm+Xo7jv7CsGvRw2Gt78zhxFf7E QooorvOIK7j4W2a/8JNNrk6A22iWz3p3DhpR8sS59S7Kf+AmuMtbW4vbqO1tIJbi4lbbHFEh d3PoAOSa9Qi0qfwd4RfRrwCLWNRuFnvYQQxiiQfukJBIySzsR1HGayrVOSDkaUoc80jLd2lk aR2LOxLMx6knvTaKK8Q9cKKKKACiiigC7o+pTaNrNnqMBIkt5VkGO4B5H0IyPxrsfivpscfi G21q1BNpq1usyv2LAAH/AMd2H8TXA16ZA/8AwlXwbmt8M97oMgkHPWLk5+gUsP8AgFbU/ejK Hz+4xn7slL5HmdFFFYmwUUUUAFYOs6vt3Wts3PR3Hb2FLrOr+Xutbdvn6O47ewrna78Nhvtz OLEV/sRCiiuy0P4dX99ax6lrVxHomksNyz3KkyTD0ii+8/14HvXoNpK7OJJvRHHIjSOqIpZ2 OFVRkk+grvNK+G7w2seoeLL3+x7V13x2gXfeTDttj/gB9XI+lbsGoaT4bPl+FLAwSgYOp3eJ Lp/Ur/DEPZRn3rHmmluJmmnleWVzlndixJ9ya4quMS0hqddPCt6zNeLW4NHt3tPDFiulQuNr 3AbfdSjn70uMgc9FwKxiSzFmJJJySe9JRXBOcpu8mdkYRirRQUUUVBYUUUUAFFFFABXc/CrW F07xcLKfJttSjNs69t3VT/Mf8CrhqkgmktriOeJiskbh0YdiDkGrhLkkpEzjzRaNDxHpLaF4 jv8ATGBAt5iqZ6lDyp/FSDWXXpPxRt4dUstE8W2qKI7+BY5tp6OBkA+/3h/wGvNqdWPLNpE0 5c0U2FYusauIQ1tbt+96O4/h9vrTtY1b7Mpt7dv3x+8w/g/+vVXQfCGs+JN8tlbhLSP/AFt7 cOI4I/q54/AZPtXVhsPf357HPXr29yO5hdTXUeHvAera9CL2TytN0r+LUL4lIj7J3c+yg++K 62y07wr4UUG1iXxBqwxm6u48WkR/6ZxdXPu/HGcdqq6lq1/q9x59/dSTuBhdxwqD0VRwo9gA K2q4uMdI6syp4aUtZaF22PhzwsgTQLIahqC9dW1CMHB9YoTlU+rbjWbeX11qN09zeXEtxO5+ aSRixP51BRXn1Ks6jvJnbCnGC91BRRRWZoFFFFABRRRQAUUUUAFFLRQAlFLRQB6b4NQeKfhx rfhp/mubQ/arQZ5z1wPxBH/A68yTTNa1a6fT9G0+aa5UZmkI2x269dzscBeDnk1p6Dr1/wCH NTW/06QJMFKHIyGU9QR+AqxrninUdcBik8q1s95kFpap5cW4nJYgfeYn+I5NdCqU7JyV2jBw ndqL0ZT07w94Y8NEz6myeI9U6iGNmWziPqzcNKfYYXr1p2q67qGssgu5v3Ef+ptolCQwj0RB wP5+uazqKmpXnU32Kp0Yw2EopaKxNRKKWigBKKWigBKKWigBKKWigBKKWigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooA//Z --------------167E2781446B-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 01:56:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA28860; Fri, 10 Jan 1997 01:54:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA28842; Fri, 10 Jan 1997 01:54:50 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA26168; Fri, 10 Jan 1997 01:55:52 -0800 Received: from MOEsun.edu.tw (moesun.edu.tw [140.111.1.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA08748 for ; Fri, 10 Jan 1997 01:52:09 -0800 Received: from nchc.gov.tw (dns.nchc.gov.tw [140.110.192.11]) by MOEsun.edu.tw (8.6.13/8.6.13) with SMTP id RAA24373 for ; Fri, 10 Jan 1997 17:53:59 +0800 Received: by nchc.gov.tw (th3.8s.nchc.gov) from ceres.nchc.gov.tw id AA07918; Fri, 10 Jan 97 17:36:53 CST Received: by ceres.nchc.gov.tw (station v4.0) from elc044.dt1.nchc id AA08313; Fri, 10 Jan 97 17:50:34 CST From: c00chu00@nchc.gov.tw (Sam Chu) Message-Id: <9701100950.AA08313@ceres.nchc.gov.tw> Subject: R10000 or R4400 To: info-performer@sgi.com Date: Fri, 10 Jan 1997 17:50:36 +0800 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 610 Status: O Hi Performer: We got a visual simulation project and plan to buy the 4CPU Oynx wiht IR. But we can't make a decision to buy R10000 or R4400. The reason that we afraid to buy R10000 is that we heard some people say that R10000 is unstable and not gain too much performance. Is this True? (with IRIX6.2)(price is not a issue) Is there anyone have R10000 Oynx with very good performance? or Any sugguestion? Thank a lot. Regards, Sam Chu National Center for High-Performance Computing Scientific Visualization Lab Email: c00chu00@nchc.gov.tw Tel: (886)35-776085 Ext 248 Fax : (886)35-773538 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 03:14:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA29119; Fri, 10 Jan 1997 03:12:42 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA29103; Fri, 10 Jan 1997 03:12:41 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA28177; Fri, 10 Jan 1997 03:13:38 -0800 Received: from mailsvr.mumbai.tcs.co.in ([202.54.5.70]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id DAA18141 for ; Fri, 10 Jan 1997 03:12:16 -0800 Received: from [145.17.40.178] by mailsvr.mumbai.tcs.co.in (NTMail 3.02.07) with ESMTP id va008939 for ; Fri, 10 Jan 1997 16:43:20 +0530 Message-ID: <32D62337.2D0A@mumbai.tcs.co.in> Date: Fri, 10 Jan 1997 16:38:39 +0530 From: Rajesh Thakur Reply-To: rajesht@mumbai.tcs.co.in Organization: Tata Consultancy Services X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: tran@sirssg1.epfl.ch CC: info-performer@sgi.com Subject: SIRIUS Board Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi Tran, We have developed an utility based on basic sirius commands which will help you to dump 1500 or more images at one strech. This utility is fully tested with IRIX5.2, sirius1.1 The download is available at following URL: http://www.tcs.co.in/tcshome/visalt/html/login.htm You will have to register (free registration) first with your name and then download the first GUI based utility. All the documentation is provided alongwith. However, if you have any queries regarding the setup or operation, you can send a mail to me any time. Would appreciate your feedback on the usability of this utility - Rajesh Thakur ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 06:54:36 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA29479; Fri, 10 Jan 1997 06:53:11 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA29463; Fri, 10 Jan 1997 06:53:10 -0800 Received: from odin.corp.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA05999; Fri, 10 Jan 1997 06:54:12 -0800 Received: from hotsauce.clubfed.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id GAA21203; Fri, 10 Jan 1997 06:52:58 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA14889; Fri, 10 Jan 1997 09:51:57 -0500 Date: Fri, 10 Jan 1997 09:51:57 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701100951.ZM14888@hotsauce.clubfed.sgi.com> In-Reply-To: "Jim" "Difference between O-GL & Performer" (Jan 10, 12:10pm) References: <9701101210.ZM16151@systech.hinet.net> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Jim" Subject: Re: Difference between O-GL & Performer Cc: info-performer@fddi-odin.corp.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Jim, Performer is a high level render library created and distributed by SGI. Performer runs on all SGI models and takes advantage of hardware and software features that are unique to each model. This gives you the best rendering performance across the entire SGI product line with one common api. So no code changes between platforms, the performer libraries do all the work. Performer does its work using OpenGL. So to answer your question I would have to say it depends. For most cases Performer is going to run the fastest making the best possible utilization of the CPU and graphics pipeline. I imagine though their could be cases where Performer does not do the best job and an application written in OpenGL could do much better. I have not seen an example of this yet however. One thing to keep in mind is that Performer is not yet an Open standard it only runs on SGI. OpenGL however runs on every platform, so if you want to minimize porting between vendors platforms use OpenGL or Open Inventor which also has implementations on many other platforms. Its a good idea to learn OpenGL even if you will be writing in Performer. OpenGL provides the basics and you will understand how Performer does its magic. Another advantage of Performer is that many of SGI's partners have written GUI interfaces to it. So you just worry about modeling your scene and leave the details to the other guys. Here is a partial list of Partners/packages: Alias/Wavefront Studio Multigen Multigen/ModelGen Medit Coryphaeus EasyScene Paradigm Lynx You should look at each package and decide which is best for your task. Brian On Jan 10, 12:10pm, Jim wrote: > Subject: Difference between O-GL & Performer > Hi Performer: > Would anybody be able to tell me - what is the difference of graphical > and CPU load between the same Open-GL app. and Performer app. > > cheer and a bright new year! > > -- > Jim Tsai > Software Engineer Visual Simulation sec. > System & Technology Corp. Taipei > > Email : jim@systech.hinet.net Tel: 886-2-6981599 Fax: 886-2-6981211 > Address: 18F-5, No. 79, Hsin Tai Wu Road, Sec. 1, Hsi-chih, Taipei Hsien, Taiwan, R.O.C. > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Jim -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 07:01:49 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA29515; Fri, 10 Jan 1997 07:00:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA29499; Fri, 10 Jan 1997 07:00:46 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA06500; Fri, 10 Jan 1997 07:01:48 -0800 Received: from lescrt.lesc.lockheed.com ([192.58.159.8]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA18301 for ; Fri, 10 Jan 1997 07:00:32 -0800 Received: from gruel.hq.lesc.lockheed.com by lescrt.lesc.lockheed.com with ESMTP (1.40.112.4/16.2) id AA165298548; Fri, 10 Jan 1997 09:02:29 -0600 Received: from MKTPO.mkt.lesc.lockheed.com (mktnt1.mkt.lesc.lockheed.com) by gruel.hq.lesc.lockheed.com with ESMTP (1.39.111.2/16.3) id AA049038141; Fri, 10 Jan 1997 08:55:41 -0600 Received: from Microsoft Mail (PU Serial #1074) by MKTPO.mkt.lesc.lockheed.com (PostalUnion/SMTP(tm) v2.1.6 for Windows NT(tm)) id AA-1997Jan10.075200.1074.20874; Fri, 10 Jan 1997 08:56:48 -0600 From: jbrickley@lmwsmr.lesc.lockheed.com (Jeff Brickley) To: c00chu00@nchc.gov.tw (Sam Chu), info-performer@sgi.com (info-performer) Message-Id: <1997Jan10.075200.1074.20874@MKTPO.mkt.lesc.lockheed.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Lockheed Martin Engineering & Sciences Date: Fri, 10 Jan 1997 08:56:48 -0600 Subject: RE: R10000 or R4400 Status: O ---------- From: Sam Chu To: info-performer Subject: R10000 or R4400 Date: Friday, January 10, 1997 3:07AM Hi Performer: We got a visual simulation project and plan to buy the 4CPU Onyx with IR. But we can't make a decision to buy R10000 or R4400. The reason that we afraid to buy R10000 is that we heard some people say that R10000 is unstable and not gain too much performance. Is this True? (with IRIX6.2)(price is not a issue) Is there anyone have R10000 Onyx with very good performance? or Any suggestion? Thank a lot. ------------------------------------------- Well, our project at WSMR does have an R10000 Onyx Infinite Reality. Yes, we have had a few problems, but SGI has been VERY good at handling them. Off hand, I would say that the R10000 based SGIs have been more stable than the Pentium chip from Intel when it was released and I'm sure you know how well it is selling now. We had not had any problems with the CPUs that had shut us down completely, we have a 16 processor Onyx and only 2 chips seemed to be causing problems and we just didn't use them.... SGI replaced all 16 chips since they were all on the recall list, and as far as I know there have been no further problems with the processors. I can't tell you performance differences, we have some older systems, but I don't know the processor numbers, plus the fact that our main system was upgraded from a 2 processor Onyx to a 16 processor Onyx and the performance, as expected, was incredible by comparison. If price is not an issue, do like any other system, and compare specs and don't worry as much over the past, unless SGI is not providing you adequate service (in which case talk to your local sales office -- because that isn't normal from everything I have experienced). Jeff =============================================================== Jeffry J. Brickley jbrickley@lmwsmr.lesc.lockheed.com 3D Systems Programmer for Lockheed Martin, White Sands Missile Range =============================================================== You can help wipe out COBOL in our Lifetime.... =============================================================== ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 07:17:30 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA29595; Fri, 10 Jan 1997 07:16:03 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA29579; Fri, 10 Jan 1997 07:16:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA07330; Fri, 10 Jan 1997 07:17:03 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA20805 for ; Fri, 10 Jan 1997 07:15:48 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id KAA10009; Fri, 10 Jan 1997 10:15:44 -0500 Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 10 Jan 97 10:13:04 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 10 Jan 97 10:12:46 EST From: "Jude Anthony" Organization: Enzian Technology, Inc. To: info-performer@sgi.com, info-vega@paradigmsim.com Date: Fri, 10 Jan 1997 10:12:41 EST Subject: Scene Density Requirements X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: Status: O OK, I'm back again. This question goes to both Performer and Vega groups. Our TTPRR requires that we render, at 30Hz, a scene with: 150 tris, 101x101 1350 tris, 51x51 1500 tris, 10x10 We're not getting 30Hz at 1024x768. When we bought the Onyx/RE2, we had 1 RM4. The salesman looked at our screen size, projected depth complexity, and iteration rate, and told us we'd need to upgrade to 2 RM4s to get the job done. Our average depth complexity for the scene is somewhere between 3.31 and 3.33. My manager tells me the threshold was around 3.1. The rated pixel fill rate for 2 RM4s is 110Mpix/sec. Our scene contains: 150 x 101 x 101 / 2 = 765,075 + 1350 x 51 x 51 / 2 = 1,755,675 + 1500 x 10 x 10 / 2 = 75,000 -------------------------------- 2,595,750 pixels. At 30Hz, that makes 2,595,750 * 30 = 77,872,500pix/sec. 77,872,500pix/sec is below the rated pixel fill rate. It's even below the 90Mpix/sec conservative fill rate on the salesman's sheets. The problem is to increase the iteration rate to 30Hz. My manager has me shifting polygons around, trying to decrease the depth complexity. I'm making the attempt, but my experience with renderers tells me this is not going to work; the depth complexity is calculated, and is only useful for culling and pixel fill estimates. Is this the case, or am I working with a different beast? The current thinking is that there is some Performer bottleneck. Any ideas on how to bring the iteration rate up? The scene is composed of strips of polygons. Perfly shows me that all the strips are meshed, all at more than 14 tris/strip. The strips are offset in such a way that no more than 6 are ever layered. Each strip is a different color than the one above it, so as to facilitate counting (6 colors total). There are no textures. The whole thing eventually runs as a vega app. Any help would be greatly appreciated. Thanks, Jude Anthony jude@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 07:23:36 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA29668; Fri, 10 Jan 1997 07:22:38 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA29652; Fri, 10 Jan 1997 07:22:37 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA07730; Fri, 10 Jan 1997 07:23:39 -0800 Received: from imtsg12.epfl.ch (imtsg12.epfl.ch [128.178.45.26]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA22130 for ; Fri, 10 Jan 1997 07:22:16 -0800 Received: (from quinet@localhost) by imtsg12.epfl.ch (950413.SGI.8.6.12/8.6.12) id QAA06516 for info-performer@sgi.com; Fri, 10 Jan 1997 16:23:00 +0100 From: "Frederic Quinet" Message-Id: <9701101623.ZM6515@imtsg12.epfl.ch> Date: Fri, 10 Jan 1997 16:23:00 +0100 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Indigo2 Video Live Texturing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Great news, at least for me :) Video Live texturing works on Indigo2 Max Impact with Indigo2 video board !!! Thank to all of you who gave me infos, I've learned much... Though ( Special thank to Eric Rose for his hint ) it can be done only with Performer 2.2 beta. It seems that the pfTexLoadMode ( share->tex, PFTEX_LOAD_SOURCE, PFTEX_SOURCE_VIDEO) NOW works. The frame rate is around 8 to 10. Anyone able to tell me if there is a way to improve this rate ? Fred quinet@imtsg12.epfl.ch ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 07:34:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA29756; Fri, 10 Jan 1997 07:33:22 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA29740; Fri, 10 Jan 1997 07:33:21 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA08337; Fri, 10 Jan 1997 07:34:23 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id HAA23840 for ; Fri, 10 Jan 1997 07:33:06 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA25724; Fri, 10 Jan 97 09:25:19 -0500 Date: Fri, 10 Jan 97 09:25:19 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701101425.AA25724@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: PFGS_POLYS problem Status: O Bruno Rassaerts said :- > In my application I want to draw a polygon > with 5 vertices. The geoset of this polygon looks like this > Coord 0: X: -1.750000 Y: 0.000000 Z: -1.300000 > Coord 1: X: 0.800000 Y: 0.000000 Z: -0.950000 > Coord 2: X: 1.550000 Y: 0.000000 Z: 0.700000 > Coord 3: X: -1.300000 Y: 0.000000 Z: 1.650000 > Coord 4: X: -2.350000 Y: 0.000000 Z: 0.600000 > The problem that Performer draws this polygon with a hole in it. It looks like the polygon has been chopped up into triangles incorrectly. For those who didn't decode Bruno's JPG file, the five vertices look something like this:- D C E B A The system appears to have generated 3 triangles A-B-C, B-C-D and C-D-E which doesn't draw any pixels between A and E and renders those between C and D and between B and C twice. The is obviously **WRONG** - it looks like a Performer error. I can't *see* anything wrong with the polygon definition - although it's a little unusual not to have any colours on the geoset, I don't think that's illegal. For a work-around, I'd suggest splitting complex polygons into simpler triangles yourself - that is usually more efficient anyway since you only have to split them once (when you create them) instead of Performer having to split them up every frame. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 07:41:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA29874; Fri, 10 Jan 1997 07:40:46 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA29858; Fri, 10 Jan 1997 07:40:45 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA08759; Fri, 10 Jan 1997 07:41:47 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id HAA24944 for ; Fri, 10 Jan 1997 07:40:33 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA25899; Fri, 10 Jan 97 09:32:47 -0500 Date: Fri, 10 Jan 97 09:32:47 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701101432.AA25899@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: Difference between O-GL & Performer Status: O One important point about the OpenGL-or-Performer question is that it isn't an either-or kind of a decision. If you choose to write the majority of your application using Performer, and later find something that you can express better using the lower level interface of OpenGL, then you can still do that. Performer doesn't block access to the lower levels - you can still make OpenGL calls in your Performer application. If you need to do image processing (for example) then you will want to use OpenGL calls in the Performer DRAW callback. The only reason I can imagine for *not* using Performer is if you need to be able to port onto a non-SGI platform. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 10:07:44 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA00397; Fri, 10 Jan 1997 10:06:40 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA00381; Fri, 10 Jan 1997 10:06:39 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA21510; Fri, 10 Jan 1997 10:07:40 -0800 Received: from smorgum.coryphaeus.com (smorgum.coryphaeus.com [204.247.110.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA28030 for ; Fri, 10 Jan 1997 10:06:25 -0800 Received: by smorgum.coryphaeus.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer@sgi.com id KAA13269; Fri, 10 Jan 1997 10:04:42 -0800 Date: Fri, 10 Jan 1997 10:04:42 -0800 From: rfox@coryphaeus.com (Randy Fox) Message-Id: <9701101004.ZM13267@smorgum.coryphaeus.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: pfPVChanStressFilter Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O What is the 'max' parameter for? I didn't see any reference to it in the man pages or the 2.1 write up. Randy -- Randy Fox Coryphaeus Software, Inc. Sr. Software Engineer 985 University Ave. Suite 31 rfox@coryphaeus.com Los Gatos CA, 95030 www.coryphaeus.com Tel: 408/395-4537 Fax: 408/395-6351 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 10:05:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA00371; Fri, 10 Jan 1997 10:03:48 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA00355; Fri, 10 Jan 1997 10:03:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA21230; Fri, 10 Jan 1997 10:04:49 -0800 Received: from nvsgi1.netvision.net.il (nvsgi1.NetVision.net.il [194.90.1.31]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA27216 for ; Fri, 10 Jan 1997 10:03:30 -0800 Received: from EFRAT.netvision.net.il (ts016p13.pop9a.netvision.net.il [194.90.5.51]) by nvsgi1.netvision.net.il (8.7.5/8.7.3) with SMTP id UAA27262; Fri, 10 Jan 1997 20:03:29 +0200 (IST) Message-ID: <32D71095.5CA6@netvision.net.il> Date: Fri, 10 Jan 1997 20:01:25 -0800 From: Moshe Nissim Reply-To: orad_u@netvision.net.il Organization: Orad Hi-Tec Systems X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Sam Chu CC: info-performer@sgi.com Subject: Re: R10000 or R4400 References: <9701100950.AA08313@ceres.nchc.gov.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Sam Chu wrote: > > Hi Performer: > > We got a visual simulation project and plan to buy the 4CPU > Oynx wiht IR. But we can't make a decision to buy R10000 or R4400. > The reason that we afraid to buy R10000 is that we heard some people > say that R10000 is unstable and not gain too much performance. Is > this True? (with IRIX6.2)(price is not a issue) > > Is there anyone have R10000 Oynx with very good performance? > or Any sugguestion? Thank a lot. > Most definitely, R10000 has better *graphics* performance, pushing geometry to an iR pipeline, than a R4400. Although neither can push geometry fast enough to "satisfy" the graphics hw (GE), the R10000 does a much better job. I am not sure if this is a function of the actual CPU chip or the overall CPU board re-design, but the end-result is the same for you. I haven't experienced any significant problems with R10000 stability on 6.2. Moshe Nissim Orad Hi-Tec Systems ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 10:49:56 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA00641; Fri, 10 Jan 1997 10:48:11 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA00625; Fri, 10 Jan 1997 10:48:10 -0800 Received: from odin.corp.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA25111; Fri, 10 Jan 1997 10:49:12 -0800 Received: from deliverator.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id KAA26730; Fri, 10 Jan 1997 10:47:58 -0800 Received: from relay5.UU.NET by deliverator.sgi.com via ESMTP (950413.SGI.8.6.12/951211.SGI.AUTO) for id KAA10309; Fri, 10 Jan 1997 10:47:58 -0800 Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQbxxq05512; Fri, 10 Jan 1997 13:44:08 -0500 (EST) Received: from ds9.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Fri, 10 Jan 1997 13:44:10 -0500 Received: from cerebus.cambridge.com by cambridge.com (4.1/SMI-4.1-SWS) id AA24780; Fri, 10 Jan 97 13:27:50 EST Received: by cerebus.cambridge.com (940816.SGI.8.6.9/SMI-4.1-SWS) id SAA29273; Fri, 10 Jan 1997 18:27:49 GMT From: "Jason Williams" Message-Id: <9701101327.ZM29271@cerebus> Date: Fri, 10 Jan 1997 13:27:48 -0500 In-Reply-To: uunet!sgi.com!brian (Brian Furtaw) "Re: Difference between O-GL & Performer" (Jan 10, 9:51am) References: <9701101210.ZM16151@systech.hinet.net> <9701100951.ZM14888@hotsauce.clubfed.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: uunet.uu.net!cerebus!info-performer, uunet.uu.net!uunet!fddi-odin.corp.sgi.com!info-performer Subject: Re: Difference between O-GL & Performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 10, 9:51am, Brian Furtaw wrote: > Subject: Re: Difference between O-GL & Performer > Jim, > > Performer is a high level render library created and distributed by SGI. > Performer runs on all SGI models and takes advantage of hardware and software > features that are unique to each model. This gives you the best rendering > performance across the entire SGI product line with one common api. So no code > changes between platforms, the performer libraries do all the work. Performer > does its work using OpenGL. > > So to answer your question I would have to say it depends. For most cases > Performer is going to run the fastest making the best possible utilization of > the CPU and graphics pipeline. I imagine though their could be cases where > Performer does not do the best job and an application written in OpenGL could > do much better. I have not seen an example of this yet however. > > One thing to keep in mind is that Performer is not yet an Open standard it only > runs on SGI. OpenGL however runs on every platform, so if you want to minimize > porting between vendors platforms use OpenGL or Open Inventor which also has > implementations on many other platforms. > Question, does anyone know the plans SGI has for Performer. Should we expect to see Performer go the same way that inventor has or is there going to be a new product which will include the Performer API in it, such as the Cosmo products? I would like to hear from the SGI people on this. Jason Williams Cambridge Research Associates. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 11:17:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA00871; Fri, 10 Jan 1997 11:15:23 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA00855; Fri, 10 Jan 1997 11:15:22 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA27209; Fri, 10 Jan 1997 11:16:24 -0800 Received: from mbsgi3.mdc.com (MBSGI3.MDC.COM [129.200.1.61]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14566 for ; Fri, 10 Jan 1997 11:15:09 -0800 Received: (from sal@localhost) by mbsgi3.mdc.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA03462; Fri, 10 Jan 1997 11:09:08 -0800 From: "Salvador Cabaruvias" Message-Id: <9701101109.ZM3460@mbsgi3.mdc.com> Date: Fri, 10 Jan 1997 11:09:07 -0800 In-Reply-To: c00chu00@nchc.gov.tw (Sam Chu) "R10000 or R4400" (Jan 10, 5:50pm) References: <9701100950.AA08313@ceres.nchc.gov.tw> Reply-to: sal@sgidev.mdc.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: c00chu00@nchc.gov.tw (Sam Chu) Subject: Re: R10000 or R4400 Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 10, 5:50pm, Sam Chu wrote: > Subject: R10000 or R4400 > > Hi Performer: > > We got a visual simulation project and plan to buy the 4CPU > Oynx wiht IR. But we can't make a decision to buy R10000 or R4400. > The reason that we afraid to buy R10000 is that we heard some people > say that R10000 is unstable and not gain too much performance. Is > this True? (with IRIX6.2)(price is not a issue) > We have a 8 R10000 CPUs IR with 2 graphic pipes. The CPUs had the problem that SGI announced, even so, it didn't affect us. Our SGI Field Service Engineer said it was mostly a heat problem. As far as performance, I haven't done any benchmarks, but we have noticed that our visual simulation is running noticeably faster. The only problems we have had, had to do with the differences IR versus RE, GL versus OpenGL, and software patches, etc. In other words, the usual stuff you see in the Performer mailing list. > Is there anyone have R10000 Oynx with very good performance? > or Any sugguestion? Thank a lot. > > Regards, > > Sam Chu > National Center for High-Performance Computing > Scientific Visualization Lab Email: c00chu00@nchc.gov.tw > Tel: (886)35-776085 Ext 248 Fax : (886)35-773538 > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Sam Chu -- ---------------------------------------------------------------. Salvador Cabaruvias | sal@sgidev.mdc.com | ---------------------------------------------------------------. CSSL | "Well I be done seen about every | McDonnell Douglas thing when I see an elephant | (310) 593-6719 | fly" --Dumbo-- | ---------------------------------------------------------------: ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 11:17:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA00889; Fri, 10 Jan 1997 11:15:43 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA00873; Fri, 10 Jan 1997 11:15:43 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA10949; Fri, 10 Jan 1997 11:15:27 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA01141; Fri, 10 Jan 1997 11:15:26 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701101915.LAA01141@remi.asd.sgi.com> Subject: Re: pfPVChanStressFilter To: rfox@coryphaeus.com (Randy Fox) Date: Fri, 10 Jan 1997 11:15:26 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: <9701101004.ZM13267@smorgum.coryphaeus.com> from "Randy Fox" at Jan 10, 97 10:04:42 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 455 Status: O Randy Fox wrote: > > What is the 'max' parameter for? I didn't see any reference to it in the > man pages or the 2.1 write up. > The stress level computed by performer (pfGetPVChanStress()) is clamped to 1. by default. it is also clamped to 'max' if 'max' is less than 1. Best Regards _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 11:41:31 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA01044; Fri, 10 Jan 1997 11:36:38 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA01028; Fri, 10 Jan 1997 11:36:37 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA29104; Fri, 10 Jan 1997 11:37:39 -0800 Received: from tuvok.mugu.navy.mil (tuvok.mugu.navy.mil [143.113.247.22]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA19918 for ; Fri, 10 Jan 1997 11:36:25 -0800 Received: from qmsmtpgw.mugu.navy.mil (qmsendgw.mugu.navy.mil) by tuvok.mugu.navy.mil (4.1/SMI-4.1) id AA09711; Fri, 10 Jan 97 11:37:27 PST Message-Id: Date: 10 Jan 1997 11:35:03 U From: "GARY ADAIR" Subject: Fixed Object Size To: "Performer" X-Mailer: Mail*Link SMTP-QM 3.0.2 Status: O I have a Performer scene with a number of 3D objects, such as F-18 aircraft, ships, and missiles. Is there a way to force the size of an object to appear constant, so that as the eyepoint either moves toward or away from the object, it does not get bigger or smaller, but appears to be the same size no matter where the eyepoint is. Thanks in Advance Gary Adair ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 11:42:42 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA01118; Fri, 10 Jan 1997 11:41:36 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA01100; Fri, 10 Jan 1997 11:41:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA29620; Fri, 10 Jan 1997 11:42:36 -0800 Received: from tuvok.mugu.navy.mil (tuvok.mugu.navy.mil [143.113.247.22]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA21143 for ; Fri, 10 Jan 1997 11:41:22 -0800 Received: from qmsmtpgw.mugu.navy.mil (qmsendgw.mugu.navy.mil) by tuvok.mugu.navy.mil (4.1/SMI-4.1) id AA09722; Fri, 10 Jan 97 11:42:26 PST Message-Id: Date: 10 Jan 1997 11:44:42 U From: "GARY ADAIR" Subject: Explosion Sequence To: "Performer Performer" X-Mailer: Mail*Link SMTP-QM 3.0.2 Status: O I would like to have a Performer explosion sequence for a surface to air missile. Does anyone have code that I could use for this? Thanks in Advance Gary Adair ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 11:41:14 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA01022; Fri, 10 Jan 1997 11:35:34 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA01006; Fri, 10 Jan 1997 11:35:33 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA12095; Fri, 10 Jan 1997 11:35:21 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA01181; Fri, 10 Jan 1997 11:35:20 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701101935.LAA01181@remi.asd.sgi.com> Subject: Re: Scene Density Requirements To: jude@p3.enzian.com (Jude Anthony) Date: Fri, 10 Jan 1997 11:35:20 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: from "Jude Anthony" at Jan 10, 97 10:12:41 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 2404 Status: O Jude Anthony wrote: > > OK, I'm back again. This question goes to both Performer and Vega groups. > > Our TTPRR requires that we render, at 30Hz, a scene with: > 150 tris, 101x101 > 1350 tris, 51x51 > 1500 tris, 10x10 > > We're not getting 30Hz at 1024x768. > > When we bought the Onyx/RE2, we had 1 RM4. The salesman looked at our > screen size, projected depth complexity, and iteration rate, and told us we'd > need to upgrade to 2 RM4s to get the job done. > > Our average depth complexity for the scene is somewhere between 3.31 and > 3.33. My manager tells me the threshold was around 3.1. > > The rated pixel fill rate for 2 RM4s is 110Mpix/sec. Our scene contains: > 150 x 101 x 101 / 2 = 765,075 > + 1350 x 51 x 51 / 2 = 1,755,675 > + 1500 x 10 x 10 / 2 = 75,000 > -------------------------------- > 2,595,750 pixels. > At 30Hz, that makes 2,595,750 * 30 = 77,872,500pix/sec. > > 77,872,500pix/sec is below the rated pixel fill rate. It's even below the > 90Mpix/sec conservative fill rate on the salesman's sheets. > > The problem is to increase the iteration rate to 30Hz. My manager has me > shifting polygons around, trying to decrease the depth complexity. I'm > making the attempt, but my experience with renderers tells me this is not > going to work; the depth complexity is calculated, and is only useful for > culling and pixel fill estimates. Is this the case, or am I working with a > different beast? > > The current thinking is that there is some Performer bottleneck. Any ideas > on how to bring the iteration rate up? > > The scene is composed of strips of polygons. Perfly shows me that all the > strips are meshed, all at more than 14 tris/strip. The strips are offset in > such a way that no more than 6 are ever layered. Each strip is a different > color than the one above it, so as to facilitate counting (6 colors total). > There are no textures. The whole thing eventually runs as a vega app. > I'm confused. Is your polygon count is the part of the database that is displayed ? a 10x10 triangle in the database can be full screen after projection, if you have 6 layers, that makes a depth complexity of 6, requiring 141 Mpixels/s. _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 12:04:23 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA01425; Fri, 10 Jan 1997 12:02:48 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA01409; Fri, 10 Jan 1997 12:02:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA01756; Fri, 10 Jan 1997 12:03:49 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26451 for ; Fri, 10 Jan 1997 12:02:35 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA16510; Fri, 10 Jan 1997 15:01:35 -0500 Date: Fri, 10 Jan 1997 15:01:35 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701101501.ZM16509@hotsauce.clubfed.sgi.com> In-Reply-To: "GARY ADAIR" "Explosion Sequence" (Jan 10, 11:44am) References: Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "GARY ADAIR" , "Performer Performer" Subject: Re: Explosion Sequence Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Gary do a man on pfuSmoke Brian On Jan 10, 11:44am, GARY ADAIR wrote: > Subject: Explosion Sequence > > I would like to have a Performer explosion sequence for a surface to air > missile. Does anyone have code that I could use for this? > > Thanks in Advance > Gary Adair > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from GARY ADAIR -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 12:06:16 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA01460; Fri, 10 Jan 1997 12:05:01 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA01444; Fri, 10 Jan 1997 12:05:00 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA01994; Fri, 10 Jan 1997 12:06:02 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26885 for ; Fri, 10 Jan 1997 12:04:48 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA16544; Fri, 10 Jan 1997 15:03:47 -0500 Date: Fri, 10 Jan 1997 15:03:47 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701101503.ZM16543@hotsauce.clubfed.sgi.com> In-Reply-To: "GARY ADAIR" "Fixed Object Size" (Jan 10, 11:35am) References: Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "GARY ADAIR" , "Performer" Subject: Re: Fixed Object Size Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Maybe you want an Orthographic frustum try looking at the manpage for pfChannel pfChannel::makeOrtho(float left, float right, float bottom, float top); in particular. Brian On Jan 10, 11:35am, GARY ADAIR wrote: > Subject: Fixed Object Size > > > I have a Performer scene with a number of 3D objects, such as F-18 > aircraft, ships, and missiles. Is there a way to force the size of an object > to appear constant, so that as the eyepoint either moves toward or away from > the object, it does not get bigger or smaller, but appears to be the same size > no matter where the eyepoint is. > > Thanks in Advance > Gary Adair > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from GARY ADAIR -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 12:22:59 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA01627; Fri, 10 Jan 1997 12:21:34 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA01611; Fri, 10 Jan 1997 12:21:33 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for <@giraffe.asd.sgi.com:info-performer@holodeck.csd.sgi.com> id MAA14601; Fri, 10 Jan 1997 12:21:19 -0800 Received: from giraffe.asd.sgi.com by remi.asd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) id MAA01472; Fri, 10 Jan 1997 12:21:17 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id MAA14597; Fri, 10 Jan 1997 12:21:17 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00739; Fri, 10 Jan 1997 12:21:14 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id PAA11383; Fri, 10 Jan 1997 15:20:57 -0500 Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 10 Jan 97 15:18:17 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 10 Jan 97 15:17:52 EST From: "Jude Anthony" Organization: Enzian Technology, Inc. To: remi@remi.asd.sgi.com (R_mi Arnaud), info-performer@remi.asd.sgi.com Date: Fri, 10 Jan 1997 15:17:46 EST Subject: Re: Scene Density Requirements X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: Status: O > Jude Anthony wrote: > > > > OK, I'm back again. This question goes to both Performer and Vega groups. > > > > Our TTPRR requires that we render, at 30Hz, a scene with: > > 150 tris, 101x101 > > 1350 tris, 51x51 > > 1500 tris, 10x10 > > > > We're not getting 30Hz at 1024x768. > > > > When we bought the Onyx/RE2, we had 1 RM4. The salesman looked at our > > screen size, projected depth complexity, and iteration rate, and told us > > we'd need to upgrade to 2 RM4s to get the job done. > > > > Our average depth complexity for the scene is somewhere between 3.31 and > > 3.33. My manager tells me the threshold was around 3.1. > > > > The rated pixel fill rate for 2 RM4s is 110Mpix/sec. Our scene contains: > > 150 x 101 x 101 / 2 = 765,075 > > + 1350 x 51 x 51 / 2 = 1,755,675 > > + 1500 x 10 x 10 / 2 = 75,000 > > -------------------------------- > > 2,595,750 pixels. > > At 30Hz, that makes 2,595,750 * 30 = 77,872,500pix/sec. > > > > 77,872,500pix/sec is below the rated pixel fill rate. It's even below the > > 90Mpix/sec conservative fill rate on the salesman's sheets. > > > > The problem is to increase the iteration rate to 30Hz. My manager has me > > shifting polygons around, trying to decrease the depth complexity. I'm > > making the attempt, but my experience with renderers tells me this is not > > going to work; the depth complexity is calculated, and is only useful for > > culling and pixel fill estimates. Is this the case, or am I working with > > a different beast? > > > > The current thinking is that there is some Performer bottleneck. Any > > ideas on how to bring the iteration rate up? > > > > The scene is composed of strips of polygons. Perfly shows me that all the > > strips are meshed, all at more than 14 tris/strip. The strips are offset > > in such a way that no more than 6 are ever layered. Each strip is a > > different color than the one above it, so as to facilitate counting (6 > > colors total). There are no textures. The whole thing eventually runs as > > a vega app. > > > > I'm confused. Is your polygon count is the part of the database that is > displayed ? a 10x10 triangle in the database can be full screen after > projection, if you have 6 layers, that makes a depth complexity of 6, > requiring 141 Mpixels/s. The polygons and the observer are placed in such a way that one database unit (meter) is one on-screen pixel. (The TTPRR specifies pixels.) They are layered more-or-less like this: +-----------+ | +-----------+ | | +------------+ + | | | + | | +------------+ So that the strips are never more than 6 deep. Later, Jude Anthony jude@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 12:39:46 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA01719; Fri, 10 Jan 1997 12:38:11 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA01703; Fri, 10 Jan 1997 12:38:11 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id MAA15252; Fri, 10 Jan 1997 12:37:42 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id MAA01562; Fri, 10 Jan 1997 12:37:19 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701102037.MAA01562@remi.asd.sgi.com> Subject: Re: pfPVChanStressFilter To: info-performer@remi.asd.sgi.com Date: Fri, 10 Jan 1997 12:37:19 -0800 (PST) Cc: src@rose.asd.sgi.com (Sharon Clay) In-Reply-To: <9701101159.ZM5925@rose.asd.sgi.com> from "Sharon Clay" at Jan 10, 97 11:59:02 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 690 Status: O Remi wrote: >Randy Fox wrote: >> = >> What is the 'max' parameter for? I didn't see any reference to it in= the >> man pages or the 2.1 write up. >> = > > The stress level computed by performer (pfGetPVChanStress()) is clampe= d to 1. by default. > it is also clamped to 'max' if 'max' is less than 1. > Sorry, it's wrong. Let me do that again: The stress level computed by performer is always clamped to 1. as minimum value It can also be clamped by 'max' as its maximum value Thanks to Sharon to notice the mistake. _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 12:45:12 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA01780; Fri, 10 Jan 1997 12:44:10 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA01764; Fri, 10 Jan 1997 12:44:09 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA05619; Fri, 10 Jan 1997 12:45:11 -0800 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA05631 for ; Fri, 10 Jan 1997 12:43:56 -0800 Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQbxxy15728; Fri, 10 Jan 1997 15:43:55 -0500 (EST) Received: from ds9.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Fri, 10 Jan 1997 15:43:55 -0500 Received: from octave.cambridge.com by cambridge.com (4.1/SMI-4.1-SWS) id AA25434; Fri, 10 Jan 97 15:35:40 EST Received: by octave.cambridge.com (940816.SGI.8.6.9/SMI-4.1-SWS) id UAA17685; Fri, 10 Jan 1997 20:35:40 GMT From: "Fred Clyne" Message-Id: <9701101535.ZM17683@octave> Date: Fri, 10 Jan 1997 15:35:39 -0500 In-Reply-To: Bruno Rassaerts "PFGS_POLYS problem" (Jan 10, 10:25am) References: <32D60B0B.41C6@luc.ac.be> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Bruno Rassaerts , uunet.uu.net!uunet!sgi.com!info-performer Subject: Re: PFGS_POLYS problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 10, 10:25am, Bruno Rassaerts wrote: > Subject: PFGS_POLYS problem > > Hi, > > I know now the the problem that I had with perfly is caused by a bug in > Performer 2.0 and that this problem is fixed in 2.0.2. But I stumbled on > something else that's weird. In my application I want to draw a polygon > with 5 vertices. The geoset of this polygon looks like this (printed > with pfPrint) > > -------- > GeoSet: 0x180998e0 { > Primitive: PFGS_POLYS, NON-INDEXED, pfPrims=1, glPrims=3, > verts=5 > Attribute Bindings: > PFGS_COLOR4=PFGS_OFF PFGS_NORMAL3=PFGS_PER_PRIM > PFGS_TEXCOORD2=PFGS_OFF > Attribute List Pointers: > PFGS_COORD3: 0x180a5130 > PFGS_COLOR4: 0x0 > PFGS_NORMAL3: 0x180a5450 > PFGS_TEXCOORD2: 0x0 > Attribute Index List Pointers: > PFGS_COLOR4: 0x0 > PFGS_NORMAL3: 0x0 > PFGS_TEXCOORD2: 0x0 > PFGS_COORD3: 0x0 > Strip Lengths: 5 > > Prim Normal 0: NX: 0.000000 NY: -1.000000 NZ: 0.000000 > Coord 0: X: -1.750000 Y: 0.000000 Z: -1.300000 > Coord 1: X: 0.800000 Y: 0.000000 Z: -0.950000 > Coord 2: X: 1.550000 Y: 0.000000 Z: 0.700000 > Coord 3: X: -1.300000 Y: 0.000000 Z: 1.650000 > Coord 4: X: -2.350000 Y: 0.000000 Z: 0.600000 > > } GeoSet: 0x180998e0 > -------- > > The problem that Performer draws this polygon with a hole in it. I > attached a small picture (4k) that shows this problem. (Sorry for > putting a binary on the mailing list but is was hard to explain > otherwise) The polygon was highlighted with PFHL_LINES so that you can > see the edges. > > Note: I am still using Performer 2.0 on an ONYX RE2 IRIX 6.2 > > Thanks, > -- > // Bruno Rassaerts - EDM (Expertisecentrum Digitale Media) > ('> Wetenschapspark 2 - B-3590 Diepenbeek - Tel: +32-(0)11268411 > /rr Fax: +32-(0)11269400 - eMail: brassaer@luc.ac.be > *\))_ URL: http://www.luc.ac.be/~brassaer/ > > [ Attachment (image/jpeg): "snap.jpg" 5081 bytes > Encoded with "base64" ] >-- End of excerpt from Bruno Rassaerts Look at the end of the man page for pfGeoSet under BUGS. PFGS_POLYS is broken for IRIS GL! To solve this, I triangulated such polygons myself. Or better yet, use OpenGL. We haven't noticed any significant performance problems with our RE2 running OpenGL. -- Fred Clyne Cambridge Research Associates office: 703-790-0505 x 7211 1430 Spring Hill Road, Suite 200 fax: 703-790-0370 McLean, VA 22102 email: fred@cambridge.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 12:57:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA02041; Fri, 10 Jan 1997 12:53:23 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA01969; Fri, 10 Jan 1997 12:52:37 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id MAA15772; Fri, 10 Jan 1997 12:51:58 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id MAA01594; Fri, 10 Jan 1997 12:51:53 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701102051.MAA01594@remi.asd.sgi.com> Subject: Re: Scene Density Requirements To: jude@p3.enzian.com (Jude Anthony) Date: Fri, 10 Jan 1997 12:51:53 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: from "Jude Anthony" at Jan 10, 97 03:17:46 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 3674 Status: O Jude Anthony wrote: > > > Jude Anthony wrote: > > > > > > OK, I'm back again. This question goes to both Performer and Vega groups. > > > > > > Our TTPRR requires that we render, at 30Hz, a scene with: > > > 150 tris, 101x101 > > > 1350 tris, 51x51 > > > 1500 tris, 10x10 > > > > > > We're not getting 30Hz at 1024x768. > > > > > > When we bought the Onyx/RE2, we had 1 RM4. The salesman looked at our > > > screen size, projected depth complexity, and iteration rate, and told us > > > we'd need to upgrade to 2 RM4s to get the job done. > > > > > > Our average depth complexity for the scene is somewhere between 3.31 and > > > 3.33. My manager tells me the threshold was around 3.1. > > > > > > The rated pixel fill rate for 2 RM4s is 110Mpix/sec. Our scene contains: > > > 150 x 101 x 101 / 2 = 765,075 > > > + 1350 x 51 x 51 / 2 = 1,755,675 > > > + 1500 x 10 x 10 / 2 = 75,000 > > > -------------------------------- > > > 2,595,750 pixels. > > > At 30Hz, that makes 2,595,750 * 30 = 77,872,500pix/sec. > > > > > > 77,872,500pix/sec is below the rated pixel fill rate. It's even below the > > > 90Mpix/sec conservative fill rate on the salesman's sheets. > > > > > > The problem is to increase the iteration rate to 30Hz. My manager has me > > > shifting polygons around, trying to decrease the depth complexity. I'm > > > making the attempt, but my experience with renderers tells me this is not > > > going to work; the depth complexity is calculated, and is only useful for > > > culling and pixel fill estimates. Is this the case, or am I working with > > > a different beast? > > > > > > The current thinking is that there is some Performer bottleneck. Any > > > ideas on how to bring the iteration rate up? > > > > > > The scene is composed of strips of polygons. Perfly shows me that all the > > > strips are meshed, all at more than 14 tris/strip. The strips are offset > > > in such a way that no more than 6 are ever layered. Each strip is a > > > different color than the one above it, so as to facilitate counting (6 > > > colors total). There are no textures. The whole thing eventually runs as > > > a vega app. > > > > > > > I'm confused. Is your polygon count is the part of the database that is > > displayed ? a 10x10 triangle in the database can be full screen after > > projection, if you have 6 layers, that makes a depth complexity of 6, > > requiring 141 Mpixels/s. > > The polygons and the observer are placed in such a way that one database unit > (meter) is one on-screen pixel. (The TTPRR specifies pixels.) They are > layered more-or-less like this: > +-----------+ > | +-----------+ > | | +------------+ > + | | | > + | | > +------------+ > So that the strips are never more than 6 deep. If I understand correctly, you have a test, where all the polygons are on the screen (no clipping, no culling). All polygons are facing the observer, so are perfectly flat in screen space. Using a perspective matrix, you place the polygons at some distance from the observer so you exactly know the surface of all triangles in screen space. If my understanding is OK, then what you could do, is to move back the observer until the frame rate is 30Hz. The displayed database will display the same number of polygons, but the fill rate will be less, as you will use less than the screen. If you never reach 30Hz with the same polygon count (performer stats) then the problem is not fill rate. If you reach 30HZ, then get the depth complexity factor at this point, and calculate the Mpix/s your system gives you. -- Remi ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 10 14:29:31 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA02929; Fri, 10 Jan 1997 14:27:53 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA02913; Fri, 10 Jan 1997 14:27:52 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA14675; Fri, 10 Jan 1997 14:28:54 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA00271 for ; Fri, 10 Jan 1997 14:27:41 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id OAA14671; Fri, 10 Jan 1997 14:28:53 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id OAA09006; Fri, 10 Jan 1997 14:27:50 -0800 From: "Rob Jenkins" Message-Id: <9701101427.ZM9004@quid.csd.sgi.com> Date: Fri, 10 Jan 1997 14:27:49 -0800 In-Reply-To: "GARY ADAIR" "Explosion Sequence" (Jan 10, 11:44am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "GARY ADAIR" , "Performer Performer" Subject: Re: Explosion Sequence Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 10, 11:44am, GARY ADAIR wrote: > Subject: Explosion Sequence > > I would like to have a Performer explosion sequence for a surface to air > missile. Does anyone have code that I could use for this? > > Thanks in Advance > Gary Adair > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from GARY ADAIR take look in the ftp archive at the Performer web page - particually under 'Reality Center' Cheers Rob -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 11 01:55:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA04867; Sat, 11 Jan 1997 01:53:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA04851; Sat, 11 Jan 1997 01:53:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA12349; Sat, 11 Jan 1997 01:54:57 -0800 Received: from server.rtset.co.il ([194.90.96.254]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA08669 for ; Sat, 11 Jan 1997 01:53:38 -0800 Received: from dialup.netvision.net.il (ts004p5.pop9a.netvision.net.il [194.90.11.79]) by server.rtset.co.il (8.6.12/8.6.9) with SMTP id LAA11605; Fri, 12 Jan 1996 11:55:55 +0200 Message-ID: <32D83207.3C3C@rtset.co.il> Date: Sat, 11 Jan 1997 16:36:52 -0800 From: Ran Yakir Reply-To: rany@rtset.co.il Organization: RT-SET X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: GARY ADAIR CC: info-performer@sgi.com Subject: Re: Fixed Object Size References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O GARY ADAIR wrote: > > I have a Performer scene with a number of 3D objects, such as F-18 > aircraft, ships, and missiles. Is there a way to force the size of an object > to appear constant, so that as the eyepoint either moves toward or away from > the object, it does not get bigger or smaller, but appears to be the same size > no matter where the eyepoint is. Here is an easy, and fairly accurate way : You have to decide which is the reference range, at which the plane is seen in a one-to-one ratio (i.e. at its real size). For each frame, calculate the range of the plane from the eyepoint, and scale the plane's DCS by the ratio of the range and the reference range. Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | 28 Ben Gurion St. / )_ (_(_) ) \/ (_(_/<_(_)( | Hod Hasharon 54200 _/ | Israel -------------------------------------+-------------------------------- At Home : | At Work : | RT-SET Voice : +972-9-989974 | Voice : +972-9-552236 Fax : +972-9-422149 | Fax : +972-9-552239 E-mail : rany@netvision.net.il | E-mail : rany@rtset.co.il ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 11 08:29:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA05409; Sat, 11 Jan 1997 08:23:10 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA05393; Sat, 11 Jan 1997 08:23:08 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA20491; Sat, 11 Jan 1997 08:24:11 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17909 for ; Sat, 11 Jan 1997 08:22:56 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA05336; Sat, 11 Jan 1997 16:22:41 GMT From: "Angus Dorbie" Message-Id: <9701111622.ZM5334@bitch.reading.sgi.com> Date: Sat, 11 Jan 1997 16:22:41 +0000 In-Reply-To: "Matsumura Makoto" "setmon&screensize" (Jan 10, 2:36pm) References: <9701101436.ZM23728@matsumura.nsg.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Matsumura Makoto" , info-performer@sgi.com Subject: Re: setmon&screensize Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O It sounds like you want to use DVR. There is support for this in the Performer API. You can see DVR being used in the perfly example code. Look at the manual page for: pfPipeVideoChannel On Jan 10, 2:36pm, Matsumura Makoto wrote: > Subject: setmon&screensize > Hi,all. > > one of my customer want to change vfo > in doing his presentation, eg: > start presentation with 1280x1024_60 > and change to 640x480_120s and go back. > > it is basically ok with setmon command, however > there is a problem, when the video format is changed > , it is not always full screen. > i.e. > we can move mouse cursor beyond the bottom/right of display. > > is there any good way to make the display area full screen > in this situation. I'd like to avoid stopgfx/startgfx if possible. > > wow/wow2 does this, i think. > > Thanks In Advance. > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Matsumura Makoto ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 11 08:53:09 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA05490; Sat, 11 Jan 1997 08:46:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA05474; Sat, 11 Jan 1997 08:46:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA21078; Sat, 11 Jan 1997 08:47:57 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA20356; Sat, 11 Jan 1997 08:44:22 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA05365; Sat, 11 Jan 1997 16:44:15 GMT From: "Angus Dorbie" Message-Id: <9701111644.ZM5363@bitch.reading.sgi.com> Date: Sat, 11 Jan 1997 16:44:15 +0000 In-Reply-To: c00chu00@nchc.gov.tw (Sam Chu) "R10000 or R4400" (Jan 10, 5:50pm) References: <9701100950.AA08313@ceres.nchc.gov.tw> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: c00chu00@nchc.gov.tw (Sam Chu), info-performer@sgi.com Subject: Re: R10000 or R4400 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O The R10000 is much faster than the 250MHz R4400. This is particularly helpfull if you are in a situation where you have a heavy CULL process (off hand I'd say double the cull performance without even recompiling), but the R10000 is also much better at feeding the graphics pipe if host limits are affecting your draw times. This is very often the case with Infinite Reality in ONYX. Initially there were reliability problems with R10000 due to a fault in manufacturing. This has been resolved and _all_ affected customers have had the part replaced. This happened months ago and is no longer a problem for currently shipping R10000 systems. Cheers, Angus. On Jan 10, 5:50pm, Sam Chu wrote: > Subject: R10000 or R4400 > > Hi Performer: > > We got a visual simulation project and plan to buy the 4CPU > Oynx wiht IR. But we can't make a decision to buy R10000 or R4400. > The reason that we afraid to buy R10000 is that we heard some people > say that R10000 is unstable and not gain too much performance. Is > this True? (with IRIX6.2)(price is not a issue) > > Is there anyone have R10000 Oynx with very good performance? > or Any sugguestion? Thank a lot. > > Regards, > > Sam Chu > National Center for High-Performance Computing > Scientific Visualization Lab Email: c00chu00@nchc.gov.tw > Tel: (886)35-776085 Ext 248 Fax : (886)35-773538 > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Sam Chu ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 12 18:39:58 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id SAA07572; Sun, 12 Jan 1997 18:34:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id SAA07556; Sun, 12 Jan 1997 18:34:15 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id SAA08008; Sun, 12 Jan 1997 18:35:19 -0800 Received: from MOEsun.edu.tw (moesun.edu.tw [140.111.1.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA23733 for ; Sun, 12 Jan 1997 18:33:53 -0800 Received: from nchc.gov.tw (dns.nchc.gov.tw [140.110.192.11]) by MOEsun.edu.tw (8.6.13/8.6.13) with SMTP id KAA06981 for ; Mon, 13 Jan 1997 10:35:48 +0800 Received: by nchc.gov.tw (th3.8s.nchc.gov) from ceres.nchc.gov.tw id AA12717; Mon, 13 Jan 97 10:18:39 CST Received: by ceres.nchc.gov.tw (station v4.0) id AA01680; Mon, 13 Jan 97 10:33:36 CST From: a00chc00@nchc.gov.tw (Charlie H. Chang) Message-Id: <9701130233.AA01680@ceres.nchc.gov.tw> Subject: about pathFly.c To: info-performer@sgi.com Date: Mon, 13 Jan 1997 10:33:36 +0800 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 442 Status: O Hi there, In the example of "pathFly.c" there is a car model (pfDCS object) and I would like print out its coordinate while it's moving. So is there a function providing this information? Thank you in advance. --------------------------------------------------------------- Charlie H. Chang (ext 209) E-mail: a00chc00@nchc.gov.tw National Center for High-performance Computing Scientific Visualization and Interactive Media Lab ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 12 18:37:52 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id SAA07553; Sun, 12 Jan 1997 18:31:09 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id SAA07537; Sun, 12 Jan 1997 18:31:08 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id SAA07919; Sun, 12 Jan 1997 18:32:12 -0800 Received: from MOEsun.edu.tw (moesun.edu.tw [140.111.1.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA23236 for ; Sun, 12 Jan 1997 18:30:37 -0800 Received: from nchc.gov.tw (dns.nchc.gov.tw [140.110.192.11]) by MOEsun.edu.tw (8.6.13/8.6.13) with SMTP id KAA06965 for ; Mon, 13 Jan 1997 10:31:52 +0800 Received: by nchc.gov.tw (th3.8s.nchc.gov) from ceres.nchc.gov.tw id AA12711; Mon, 13 Jan 97 10:14:43 CST Received: by ceres.nchc.gov.tw (station v4.0) from elc046.dt1.nchc id AA01653; Mon, 13 Jan 97 10:29:40 CST From: c00mrn00@nchc.gov.tw (Mei-Ling Hsu) Message-Id: <9701130229.AA01653@ceres.nchc.gov.tw> Subject: sky with cloud texture To: info-performer@sgi.com Date: Mon, 13 Jan 1997 10:29:41 +0800 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 358 Status: O Hi, performers: In the man page of pfESkyxx, it's said that PFES_OVERCAST is the only choice for PFES_CLOUDS when defining the pfESkyMode, and this cloud type is a non-textured one. So, if I want to have a cloud texture on the sky, what should I do? Mei-Ling Hsu. National Center for High-performance Computing. Taiwan, R.O.C. Email: c00mrn00@nchc.gov.tw ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 12 19:29:19 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id TAA07751; Sun, 12 Jan 1997 19:23:11 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id TAA07735; Sun, 12 Jan 1997 19:23:10 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id TAA09285; Sun, 12 Jan 1997 19:24:14 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA29668; Sun, 12 Jan 1997 19:22:57 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id DAA06473; Mon, 13 Jan 1997 03:22:52 GMT From: "Angus Dorbie" Message-Id: <9701130322.ZM6471@bitch.reading.sgi.com> Date: Mon, 13 Jan 1997 03:22:52 +0000 In-Reply-To: a00chc00@nchc.gov.tw (Charlie H. Chang) "about pathFly.c" (Jan 13, 10:33am) References: <9701130233.AA01680@ceres.nchc.gov.tw> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: a00chc00@nchc.gov.tw (Charlie H. Chang), info-performer@sgi.com Subject: Re: about pathFly.c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O If pfPrint is to general then try this _untested_ code. void print_dcs_pos(pfDCS *dcs) { pfMatrix *matey; pfVec3 zeropos, position; pfSetVec3(zeropos, 0.0f, 0.0f, 0.0f); matey = pfGetDCSMatPtr(dcs); pfXformVec3(position, zeropos, *matey); printf("%.3f, %.3f, %.3f\n", position[PF_X], position[PF_Y], position[PF_Z]); } Cheers, Angus. On Jan 13, 10:33am, Charlie H. Chang wrote: > Subject: about pathFly.c > > Hi there, > > In the example of "pathFly.c" there is a car model (pfDCS object) > and I would like print out its coordinate while it's moving. > So is there a function providing this information? > > Thank you in advance. > > --------------------------------------------------------------- > Charlie H. Chang (ext 209) E-mail: a00chc00@nchc.gov.tw > National Center for High-performance Computing > Scientific Visualization and Interactive Media Lab > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Charlie H. Chang ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 12 19:41:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id TAA07777; Sun, 12 Jan 1997 19:34:43 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id TAA07761; Sun, 12 Jan 1997 19:34:43 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id TAA09544; Sun, 12 Jan 1997 19:35:47 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA00970; Sun, 12 Jan 1997 19:34:30 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id DAA06480; Mon, 13 Jan 1997 03:34:27 GMT From: "Angus Dorbie" Message-Id: <9701130334.ZM6478@bitch.reading.sgi.com> Date: Mon, 13 Jan 1997 03:34:27 +0000 In-Reply-To: c00mrn00@nchc.gov.tw (Mei-Ling Hsu) "sky with cloud texture" (Jan 13, 10:29am) References: <9701130229.AA01653@ceres.nchc.gov.tw> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: c00mrn00@nchc.gov.tw (Mei-Ling Hsu), info-performer@sgi.com Subject: Re: sky with cloud texture Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O The simplest way is to build a textured model of the sky and load this. You then have the option of attaching it to a DCS to translate parts of it around with the eye position. If you want a really impressive and flexible sky effect then you may have to create the geosets & geostates in code, or at least write code to modify a sky model you've loaded. It might be usefull to have an improved pfEarthSky but it's almost pointless trying to do this because for most applications you see performer being used for the requirements are so varied. It would also be a shame if everyones textured performer sky wound up looking the same. Cheers, Angus. On Jan 13, 10:29am, Mei-Ling Hsu wrote: > Subject: sky with cloud texture > So, if I want to have a cloud texture on the sky, what should I do? >-- End of excerpt from Mei-Ling Hsu ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 12 19:59:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id TAA07901; Sun, 12 Jan 1997 19:53:36 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id TAA07885; Sun, 12 Jan 1997 19:53:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id TAA10018; Sun, 12 Jan 1997 19:54:38 -0800 Received: from s1000e.cs.tsinghua.edu.cn (s1000e.cs.tsinghua.edu.cn [166.111.89.241]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA03431 for ; Sun, 12 Jan 1997 19:52:24 -0800 Received: (from yl@localhost) by s1000e.cs.tsinghua.edu.cn (8.6.11/8.6.9) id MAA05695; Mon, 13 Jan 1997 12:02:00 +0800 Date: Mon, 13 Jan 1997 12:02:00 +0800 (HKT) From: Yang Lei To: "Charlie H. Chang" cc: info-performer@sgi.com Subject: Re: about pathFly.c In-Reply-To: <9701130233.AA01680@ceres.nchc.gov.tw> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O can you tell me where you get pathFly.c? I get a perpath. But It is just running under Performer 1.0. Your version is 1.0 or 2.0 ? yanglei On Mon, 13 Jan 1997, Charlie H. Chang wrote: > > Hi there, > > In the example of "pathFly.c" there is a car model (pfDCS object) > and I would like print out its coordinate while it's moving. > So is there a function providing this information? > > Thank you in advance. > > --------------------------------------------------------------- > Charlie H. Chang (ext 209) E-mail: a00chc00@nchc.gov.tw > National Center for High-performance Computing > Scientific Visualization and Interactive Media Lab > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 12 21:38:05 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id VAA08084; Sun, 12 Jan 1997 21:31:19 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id VAA08068; Sun, 12 Jan 1997 21:31:18 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id VAA12446; Sun, 12 Jan 1997 21:32:21 -0800 Received: from cucs18.cs.cuhk.hk (cucs18.cs.cuhk.hk [137.189.91.190]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA14424 for ; Sun, 12 Jan 1997 21:31:00 -0800 Received: from sgi18.cs.cuhk.hk by cs.cuhk.hk with ESMTP id NAA17855; Mon, 13 Jan 1997 13:30:56 +0800 Received: by sgi18.cs.cuhk.hk (940816.SGI.8.6.9/Spike-2.0) id NAA27265; Mon, 13 Jan 1997 13:30:53 +0800 Date: Mon, 13 Jan 1997 13:30:53 +0800 (HKT) From: Ah Fei To: info-performer@sgi.com Subject: animation of iv models? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi all, I want to animate the opening of door and moving of car in my iv format scene. Are there any software which may create iv animation models? Does the iv loader of Performer support objects moving along a path? Moreover, I want to animate the door such that it will open when someone moving to it. Are there any demo programs do the similar things? Any suggestion are welcome. Thanks. Fred Chan [CS, CUHK] ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 04:42:14 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA08821; Mon, 13 Jan 1997 04:41:01 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA08805; Mon, 13 Jan 1997 04:41:00 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA24776; Mon, 13 Jan 1997 04:42:04 -0800 Received: from tds-akron.lmco.com (tds-akron.lmco.com [158.186.100.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA02858 for ; Mon, 13 Jan 1997 04:40:47 -0800 From: david.heskamp@lmco.com Received: from ldsa by tds-akron.lmco.com (SMI-8.6/SMI-SVR4) id HAA06856; Mon, 13 Jan 1997 07:24:36 -0500 Received: from pc1197.ldsa by ldsa (SMI-8.6/SMI-SVR4) id HAA19883; Mon, 13 Jan 1997 07:39:23 -0500 To: orad_u@netvision.net.il, c00chu00@nchc.gov.tw, info-performer@sgi.com Subject: Re: R10000 or R4400 Date: Mon, 13 Jan 97 07:34:41 EST Message-Id: <9701131234.293078@pc1197.ldsa> X-Mailer: SelectMAIL 1.2 Status: O I have found a factor of two increase in performance between a 4 CPU R4400 w/ RE2 and a 4 CPU R10000 w/ IR. I believe the performance was due to the CPU although I'm not 100% certain. Dave Heskamp Lockheed Martin Tactical Defense Systems 1210 Massillon Road Akron, Ohio 44315-0001 phone: (330) 796 - 5383 fax: (330) 796 - 7009 email: david.heskamp@lmco.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 05:48:13 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA08963; Mon, 13 Jan 1997 05:46:54 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA08947; Mon, 13 Jan 1997 05:46:53 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA27031; Mon, 13 Jan 1997 05:47:57 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA11870 for ; Mon, 13 Jan 1997 05:46:41 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA22143; Mon, 13 Jan 1997 08:45:44 -0500 Date: Mon, 13 Jan 1997 08:45:44 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701130845.ZM22142@hotsauce.clubfed.sgi.com> In-Reply-To: c00mrn00@nchc.gov.tw (Mei-Ling Hsu) "sky with cloud texture" (Jan 13, 10:29am) References: <9701130229.AA01653@ceres.nchc.gov.tw> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: c00mrn00@nchc.gov.tw (Mei-Ling Hsu), info-performer@sgi.com Subject: Re: sky with cloud texture Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O You could put a large polygon in the sky and texture map it. You could build a dome or pyramid in the sky and texture map it. I actually made individual cloud textures and pasted them on to randomized pfBillboard's, I will warn you I still have not passed judgement on this, it looks great but it seems to slow things down a bit. Brian On Jan 13, 10:29am, Mei-Ling Hsu wrote: > Subject: sky with cloud texture > Hi, performers: > > In the man page of pfESkyxx, it's said that PFES_OVERCAST is the only > choice for PFES_CLOUDS when defining the pfESkyMode, and this cloud > type is a non-textured one. > So, if I want to have a cloud texture on the sky, what should I do? > > Mei-Ling Hsu. > National Center for High-performance Computing. > Taiwan, R.O.C. > Email: c00mrn00@nchc.gov.tw > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Mei-Ling Hsu -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 05:53:34 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA08987; Mon, 13 Jan 1997 05:52:34 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA08971; Mon, 13 Jan 1997 05:52:33 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA27225; Mon, 13 Jan 1997 05:53:37 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA12589 for ; Mon, 13 Jan 1997 05:52:21 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA22173; Mon, 13 Jan 1997 08:51:19 -0500 Date: Mon, 13 Jan 1997 08:51:19 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701130851.ZM22172@hotsauce.clubfed.sgi.com> In-Reply-To: a00chc00@nchc.gov.tw (Charlie H. Chang) "about pathFly.c" (Jan 13, 10:33am) References: <9701130233.AA01680@ceres.nchc.gov.tw> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: a00chc00@nchc.gov.tw (Charlie H. Chang), info-performer@sgi.com Subject: Re: about pathFly.c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O pfPrint or the print method of pfMemory pfMemory::print Prints information to a file about the specified object. The file argument specifies the file. If file is NULL, the listing is printed to stderr. pfMemory::print takes a verbosity indicator, verbose. Valid selections in order of increasing verbosity are: PFPRINT_VB_OFF no printing PFPRINT_VB_ON minimal printing (default) PFPRINT_VB_NOTICE minimal printing (default) PFPRINT_VB_INFO considerable printing PFPRINT_VB_DEBUG exhaustive printing If mem is a type of pfNode, then which specifies whether the print traversal should only traverse the current node (PFTRAV_SELF) or print out the entire scene graph rooted by node mem by traversing node and its descendents in the graph (PFTRAV_SELF | PFTRAV_DESCEND). If mem is a pfFrameStats, then which specifies a bitmask of frame statistics classes that should be printed. If mem is a pfGeoSet, then which is ignored and information about that pfGeoSet is printed according to the verbosity indicator. The output contains the types, names and bounds of the nodes and pfGeoSets in the hierarchy. This routine is provided for debugging purposes only and the content and format may change in future releases. Example 3: Print entire contents of a pfGeoSet, gset, to stderr. gset->print(NULL, PFPRINT_VB_DEBUG, NULL); Example 4: Print entire scene graph under node to a file file with default verbosity. file = fopen ("scene.out","w"); scene->print(PFTRAV_SELF | PFTRAV_DESCEND, PFPRINT_VB_ON, file); fclose(file); Brian On Jan 13, 10:33am, Charlie H. Chang wrote: > Subject: about pathFly.c > > Hi there, > > In the example of "pathFly.c" there is a car model (pfDCS object) > and I would like print out its coordinate while it's moving. > So is there a function providing this information? > > Thank you in advance. > > --------------------------------------------------------------- > Charlie H. Chang (ext 209) E-mail: a00chc00@nchc.gov.tw > National Center for High-performance Computing > Scientific Visualization and Interactive Media Lab > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Charlie H. Chang -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 06:32:42 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA09205; Mon, 13 Jan 1997 06:31:24 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA09189; Mon, 13 Jan 1997 06:31:23 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA28973; Mon, 13 Jan 1997 06:32:27 -0800 Received: from gate.volvo.se (gate.volvo.se [192.138.110.253]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA18279 for ; Mon, 13 Jan 1997 06:31:10 -0800 Received: (mail@localhost) by gate.volvo.se (8.6.12/8.6.5) id PAA21595 for ; Mon, 13 Jan 1997 15:31:07 +0100 Received: from unknown(131.97.124.70) by gate.volvo.se via smap (V1.3) id sma021565; Mon Jan 13 15:30:56 1997 Received: from challenge by nike.volvo.se with ESMTP (8.6.12/1.37) id PAA16895; Mon, 13 Jan 1997 15:30:56 +0100 Received: by challenge (950413.SGI.8.6.12/930416.SGI) for info-performer@sgi.com id PAA02789; Mon, 13 Jan 1997 15:31:53 +0100 From: "VR@onyx" Message-Id: <9701131531.ZM2787@challenge> Date: Mon, 13 Jan 1997 15:31:53 +0100 In-Reply-To: david.heskamp@lmco.com "Re: R10000 or R4400" (Jan 13, 7:34am) References: <9701131234.293078@pc1197.ldsa> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Re: R10000 or R4400 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi ! We have done simple benchmarks on some code(realtime dynamics model of a car), and the R10000 shows a performance boost of up to 3-4 times. Also, we have had NO problems with the R10000 in our Onyx. I guess we were lucky... ;-) In general, the R10000 seems to do a lot of stuff a whole lot faster, not just crunching code; database loading, feeding the graphics pipeline, etc. All in all, I would strongly recommend the R10000 instead of the R4400. It is also e better investment for the future, with upgrades of different sorts in mind. Dennis Saluaar, Volvo E-mail : dennis@vtd.volvo.se -- AB Volvo, Technological Development _/_/_/_/ Cognitive Ergonomics _/_/_/ _/ Phone : +46-31-595647 Fax : +46-31-595415 "So many polygons, E-mail: vr_dev@vtd.volvo.se so little time..." ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 06:32:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA09166; Mon, 13 Jan 1997 06:30:33 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA09150; Mon, 13 Jan 1997 06:30:32 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA28923; Mon, 13 Jan 1997 06:31:37 -0800 Received: from geordi.airinc.com (derrick.ott.hookup.net [165.154.43.219]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA18157 for ; Mon, 13 Jan 1997 06:30:17 -0800 Received: from geordi by geordi.airinc.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA15406; Mon, 13 Jan 1997 09:28:16 -0500 Sender: prider@airinc.com Message-ID: <32DA467F.41C6@airinc.com> Date: Mon, 13 Jan 1997 09:28:15 -0500 From: Paul Rider Organization: Airborne Data Technologies X-Mailer: Mozilla 3.0 (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: "Performer mailing list." Subject: Flashing geometry under pfLayer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hey All. Situation: Flashing geometry, and lights (pfLPointState) under a pfLayer. -creating a pfLayer and setMode( PFDECAL_BASE_STENCIL ). -under this pfLayer, I have the runway, then all it's geometry. Each major stripe component is under it's own separator. Following the stripes, I have the lights (whose parent is also the pfLayer). Each major light group is under it's own separator. One of the light groups contains a pfSequence if that makes any difference. The runway, it's texture, and a few stripes are drawn correctly, everyting else is flashing... Question: How do I make it stop ;-) ciao, Paul J. Rider. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 06:38:42 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA09233; Mon, 13 Jan 1997 06:37:39 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA09217; Mon, 13 Jan 1997 06:37:39 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA29179; Mon, 13 Jan 1997 06:38:43 -0800 Received: from gate.volvo.se (gate.volvo.se [192.138.110.253]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA19391 for ; Mon, 13 Jan 1997 06:37:26 -0800 Received: (mail@localhost) by gate.volvo.se (8.6.12/8.6.5) id PAA22014 for ; Mon, 13 Jan 1997 15:37:24 +0100 Received: from unknown(131.97.124.70) by gate.volvo.se via smap (V1.3) id sma022004; Mon Jan 13 15:37:13 1997 Received: from challenge by nike.volvo.se with ESMTP (8.6.12/1.37) id PAA17580; Mon, 13 Jan 1997 15:37:13 +0100 Received: by challenge (950413.SGI.8.6.12/930416.SGI) for info-performer@sgi.com id PAA02951; Mon, 13 Jan 1997 15:38:10 +0100 From: "VR@onyx" Message-Id: <9701131538.ZM2949@challenge> Date: Mon, 13 Jan 1997 15:38:10 +0100 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: vga for PC-monitor Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi everbody ! Are there anyone out there with experience from running a "ordinary" PC-monitor from a iR-machine ? By ordinary I mean the analog, 15-pin, VGA-style connector on the monitor. There is a cabling problem, taking the connector on the iR to the connector needed for PC, but most of all, what does the videosignal look like ? What settings in the ircombiner-tool is recommended ? We are mainly interested in the 800x600 resolution, but 600x480 could be interesting as well. Any ideas or pointers to info is very appreciated ! Thanks ! -- Dennis Saluaar, Volvo My email : dennis@vtd.volvo.se -- AB Volvo, Technological Development _/_/_/_/ Cognitive Ergonomics _/_/_/ _/ Phone : +46-31-595647 Fax : +46-31-595415 "So many polygons, E-mail: vr_dev@vtd.volvo.se so little time..." ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 07:09:59 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA09465; Mon, 13 Jan 1997 07:08:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA09449; Mon, 13 Jan 1997 07:08:35 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA01067; Mon, 13 Jan 1997 07:09:39 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA25136 for ; Mon, 13 Jan 1997 07:08:23 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA22418; Mon, 13 Jan 1997 10:07:19 -0500 Date: Mon, 13 Jan 1997 10:07:19 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701131007.ZM22417@hotsauce.clubfed.sgi.com> In-Reply-To: "VR@onyx" "vga for PC-monitor" (Jan 13, 3:38pm) References: <9701131538.ZM2949@challenge> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "VR@onyx" , info-performer@sgi.com Subject: Re: vga for PC-monitor Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O To find out common PC video formats and update rates try looking at PC graphics cards web sites. I was looking at www.diamondmm.com last night. As far as cable pinouts I would reccomend getting the pinout for your monitor and the output port of the SGI. I don't know anything about the pinout of an Onyx but customer support should be able to provide you with the necessary documents. Brian On Jan 13, 3:38pm, VR@onyx wrote: > Subject: vga for PC-monitor > Hi everbody ! > > Are there anyone out there with experience from running a "ordinary" PC-monitor > from a iR-machine ? By ordinary I mean the analog, 15-pin, VGA-style connector > on the monitor. There is a cabling problem, taking the connector on the iR to > the connector needed for PC, but most of all, what does the videosignal look > like ? What settings in the ircombiner-tool is recommended ? We are mainly > interested in the 800x600 resolution, but 600x480 could be interesting as well. > > Any ideas or pointers to info is very appreciated ! Thanks ! > > -- Dennis Saluaar, Volvo > > My email : dennis@vtd.volvo.se > > -- > > AB Volvo, Technological Development _/_/_/_/ > Cognitive Ergonomics _/_/_/ > _/ > Phone : +46-31-595647 > Fax : +46-31-595415 "So many polygons, > E-mail: vr_dev@vtd.volvo.se so little time..." > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from VR@onyx -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 08:06:44 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA09632; Mon, 13 Jan 1997 08:05:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA09616; Mon, 13 Jan 1997 08:05:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA05189; Mon, 13 Jan 1997 08:06:21 -0800 Received: from alf.mandator.se (mandator.se [195.84.33.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA05785 for ; Mon, 13 Jan 1997 08:05:02 -0800 From: ulf.yngwe@mandator.se Received: by alf.mandator.se; id AA25542; Mon, 13 Jan 97 17:06:49 +0100 Received: from mail.mandator.se(192.168.140.10) by alf.mandator.se via smap (3.2) id xma025537; Mon, 13 Jan 97 17:06:33 +0100 Received: by mail.mandator.se(Lotus SMTP MTA v1.05b3 (266.7 11-15-1996)) id C125641E.00582001 ; Mon, 13 Jan 1997 17:02:33 +0200 X-Lotus-Fromdomain: MANDATOR To: info-performer@sgi.com Message-Id: Date: Mon, 13 Jan 1997 17:01:39 +0200 Subject: Performer with dm pbuffers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Is there anybody who has used the digital media pbuffers with performer. I am trying to create a pbuffer to use performer to draw in, but i can't find out how to create one. If anyone has some piece of code it would be greatly apreciated. /uy ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 08:22:40 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA09678; Mon, 13 Jan 1997 08:21:22 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA09662; Mon, 13 Jan 1997 08:21:21 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA06205; Mon, 13 Jan 1997 08:22:25 -0800 Received: from relay1.oleane.net (Relay1.OLEANE.NET [194.2.1.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA08323 for ; Mon, 13 Jan 1997 08:21:06 -0800 Received: from corysmailserv (mailhost.corys.fr [194.2.225.1]) by relay1.oleane.net (8.6.10/8.6.9) with SMTP id QAA27757 for ; Mon, 13 Jan 1997 16:55:09 +0100 Received: from cos2.4s205.corys by corysmailserv (5.x/SMI-SVR4) id AA11873; Mon, 13 Jan 1997 16:25:55 +0100 Received: by cos2.4s205.corys (5.x/SMI-SVR4) id AA00483; Mon, 13 Jan 1997 16:29:51 +0100 Date: Mon, 13 Jan 1997 16:29:51 +0100 From: reymond@corysmailserv.corys.fr (Gilles Reymond) Message-Id: <9701131529.AA00483@cos2.4s205.corys> To: info-performer@sgi.com Subject: Custom texture filtering Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: uY4O0QTWLtnOPiQV2vmrwQ== Status: O Hi, Has anyone some experience with gltexfilterfuncsgis - or its IrisGl counterpart texdef2d(TX_MIPMAP_FILTER_KERNEL) ? My particular problem is to deal with a repeated RGBA texture mapped onto a polygon strip going away to the horizon. Using mipmapping GL_LINEAR_MIPMAP_LINEAR causes some artifacts in the rendering of the farthest side of the object, where the min_filter supposedly becomes active. I guess this is due to the particular structure of the texture. This effect was experienced both on iR and RE2 systems, though with slight rendering aspect differences. Hence, my questions are : - was is the weighting policy used by standard trilinear mipmapping on those systems ? - would a custom-designed set of weights help solve my problem ? - what is the recommended method for chosing these weights (through Performer calls, maybe)? Thank you very much for any helpful hints, Gilles ------------------------------------------------------------------------ Gilles Reymond | CORYS SA Email: reymond@corys.fr | 74 avenue des Martyrs, tel: (33) 76 28 82 00 | 38027 GRENOBLE Cedex 01, FRANCE ------------------------------------------------------------------------ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 09:23:15 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA09891; Mon, 13 Jan 1997 09:20:14 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA09875; Mon, 13 Jan 1997 09:20:13 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA10619; Mon, 13 Jan 1997 09:21:18 -0800 Received: from huey.ntsc.navy.mil ([192.44.253.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA18427 for ; Mon, 13 Jan 1997 09:19:24 -0800 From: WILLIAM_MARINELLI@ntsc.navy.mil Received: from CCMAIL.NTSC.NAVY.MIL ([192.44.253.30]) by huey.ntsc.navy.mil (4.1/SMI-4.1) id AA07244; Mon, 13 Jan 97 12:17:35 EST Received: from ccMail by CCMAIL.NTSC.NAVY.MIL (SMTPLINK V2.11) id AA853186749; Mon, 13 Jan 97 12:17:26 EST Date: Mon, 13 Jan 97 12:17:26 EST Message-Id: <9700138531.AA853186749@CCMAIL.NTSC.NAVY.MIL> To: info-performer@sgi.com Subject: Showcase files from IITSEC Status: O At the Performer Users group meeting I asked about the possibility of getting a copy of the showcase file(s) that were used for the presentation. The answer was that they could be put on the web site in the performer section. Has this happened? If so, I missed it (I have checked from time to time). ??? Regards, Billyboy ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 09:44:27 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA09997; Mon, 13 Jan 1997 09:41:23 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA09981; Mon, 13 Jan 1997 09:41:22 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA12134; Mon, 13 Jan 1997 09:42:26 -0800 Received: from huey.ntsc.navy.mil (huey.ntsc.navy.mil [192.44.253.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA23125 for ; Mon, 13 Jan 1997 09:41:09 -0800 From: WILLIAM_MARINELLI@ntsc.navy.mil Received: from CCMAIL.NTSC.NAVY.MIL ([192.44.253.30]) by huey.ntsc.navy.mil (4.1/SMI-4.1) id AA07354; Mon, 13 Jan 97 12:38:25 EST Received: from ccMail by CCMAIL.NTSC.NAVY.MIL (SMTPLINK V2.11) id AA853187997; Mon, 13 Jan 97 12:35:29 EST Date: Mon, 13 Jan 97 12:35:29 EST Message-Id: <9700138531.AA853187997@CCMAIL.NTSC.NAVY.MIL> To: info-performer@sgi.com, info-vega@paradigmsim.com Subject: glReadPixels Status: O I'm posting this to both groups because it's a vega app but seems applicable to both in the context of a post draw callback. Opinions about using glReadPixels to approximte the distance an object is away from the eyepoint (simulate a laser range finder)? I use glReadPixels(640,512,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,f); ^^^^^^^ ^^^ ^^^^^^^^^^^^^^^^^^ middle 1 z buffer value of pixel screen then try to scale it appropriately with the near and far clip planes. f returns with a float value between 0 and one. I suppose that the Ifinite Reality Floating point z buffer has been accounted for when this float is spit out. At this point the returned depth buffer value is scaled quite large; ie, you pitch down to the ground and the returned value is still quite high (.4). ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 10:39:41 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA10262; Mon, 13 Jan 1997 10:38:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA10246; Mon, 13 Jan 1997 10:38:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA17513; Mon, 13 Jan 1997 10:39:21 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07043 for ; Mon, 13 Jan 1997 10:38:03 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Mon, 13 Jan 1997 13:26:09 Eastern Standard Time Received: by gateway.ivex3d.com from STCROIX (192.168.1.17::mail daemon; unverified,SLMAIL95 V2.2); Mon, 13 Jan 1997 13:26:08 Eastern Standard Time Received: by STCROIX with Microsoft Mail id <01BC0158.B3C456B0@STCROIX>; Mon, 13 Jan 1997 13:50:14 -0500 Message-ID: <01BC0158.B3C456B0@STCROIX> From: "Hudson Holmes" To: "'info-performer'" Cc: "'Martin, Bill'" Subject: Performer Pro needed Date: Mon, 13 Jan 1997 13:50:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: O IVEX Corporation was founded in 1983 by a group of Georgia Tech Scientists to commercialize a unique, patented 3D graphics technology. Since that time, IVEX has evolved into a leading provider of Image Generators for use on commercial and military flight simulators. IVEX holds the distinction of being one of only five companies worldwide that have visual systems on simulators qualified to FAA Level C. Currently, IVEX is embarking on several projects to develop cutting-edge technologies, to further push the boundaries of real-time simulation. To meet these objectives, IVEX has identified the need for the following additional personnel for full-time employment. SENIOR SOFTWARE ENGINEER This position is responsible for all stages of product design from specification, through design, code and integration. The ideal candidate will have a minimum: BS (MS preferred) in CS or EE; 5 years graphics programming experience, 3 years experience developing real-time 3D graphics; C/C++; proficient with IRIS Performer and OpenGL; UNIX or IRIS OS experience. In addition, commercial/military flight simulation experience a plus. We offer a competitive salary and an attractive compensation package including full medical and dental coverage and 401(k) plan. Please contact: Hudson Holmes, Software Engineering Manager IVEX Inc. 4355 International Blvd. Norcross, GA 30093 voice 770-564-1148 fax 770-381-0622 e-mail holmes@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 12:26:38 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA11125; Mon, 13 Jan 1997 12:24:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA11109; Mon, 13 Jan 1997 12:24:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA28094; Mon, 13 Jan 1997 12:25:59 -0800 Received: from crdems.ge.com (crdems.GE.COM [192.35.44.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA04416 for ; Mon, 13 Jan 1997 12:24:31 -0800 Received: from bart.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA16989; Mon, 13 Jan 97 15:18:02 -0500 Received: from bart by bart.crd.ge.com (SMI-8.6/GE-CRD Standard Sendmail Version S1.5)id PAA06391; Mon, 13 Jan 1997 15:18:09 -0500 Sender: volpe@ash.crd.ge.com Message-Id: <32DA9881.58E4@ash.crd.ge.com> Date: Mon, 13 Jan 1997 15:18:09 -0500 From: Christopher R Volpe Organization: GE Corporate Research & Development, Schenectady, NY X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: Sharon Clay Cc: Fred Clyne , Christopher R Volpe , info-performer@sgi.com Subject: Re: Sudden X/Performer problem References: <32D2D4D4.1296@ash.crd.ge.com> <9701081304.ZM13842@octave> <9701081058.ZM28017@rose.asd.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Sharon Clay wrote: > Regarding my following error at startup: > ->> > ->> PF Warning/Internal(12): pfWindow::openNewNoPort() - null visual. > ->> X Error: 0 > ->> Request Major code 0 () > ->> Error Serial #33 > ->> Current Serial #15 > ->> Exit 1 Fred Clyne notes: > > -> > ->>From the Performer 2.2 Beta Release Notes: > -> > ->o 6.2 OS bug with shared arena placement > -> > -> An obscure bug in IRIX 65.2 with default placement of the shared arena > -> can cause programs to die due to lack of heap space for malloc. > -> Typcially the program will die during X or GL initialization with > -> a message like [what you stated above]. > And Sharon points out: > It is easy enough to see if you are being bit by this. Run your program through > par: par -s -i -SS prog [options] > and see if you get messages in the output about brk failing due to lack of space. > If you do, then this is your beast. Yup. That's my beast. I get lots o' them. However, if I compile the entire application with -mips4 (I'm on an R10000), the problem disappears. However, I suspect that's only because -mips4 allows the use of certain instructions which cause the resulting code size to shrink, therefore leaving more room between the shared arena and the brk point. Therefore, the problem is likely to bite me again. > > -> > ->WAR: through the environment variable PFSHAREDBASE or in with > -> pfSharedArenaBase() before pfInit(), explicitly set the address of the > -> arena so that it is not too close to the heap and does not collide > -> with other DSOs. An address that has worked with programs exhibiting > -> the problem that are very close to perfly is: 0x18000000. > > FYI, I added the PFSHAREDBASE when I ran into this problem so it isn't in > currently released versions of Performer -- you have to use the API, Ok, I'll use the API. However, my application is not derived from perfly, so the magic number 0x18000000 is not necessarily correct. Is there an algorithmic run-time way to determine a value that will make brk() happy? > or else > a tricky rld WAR from Don Hatch - contact us for more info. Fire away :). Fred adds: > > -> > -> ex: pfSharedArenaBase(0x18000000); or > -> setenv PFSHAREDBASE 0x18000000 > -> > -> If this address is not sufficient, run again with par [they had an > -> example earlier: par -s -i -SS prog options] and the following > -> environment variables set: > -> setenv _RLD_PATH /usr/lib/rld.debug; setenv _RLD_ARGS -v > -> and redirect all output to a file. Look for the addresses of the > -> mmap() calls and of address of DSO load actions to find a free > -> address range in which to place the arena. Compiling with some > -> libraries statically can make this operation easier. > -> > ->Whew! I hope I don't run into this bug. Hope this helps. Thanks for the info, Fred. Is this the "tricky rld WAR" that Sharon refers to? -- Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr@crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 15:45:22 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA13495; Mon, 13 Jan 1997 15:43:46 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA13479; Mon, 13 Jan 1997 15:43:45 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA17566; Mon, 13 Jan 1997 15:44:49 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA24081 for ; Mon, 13 Jan 1997 15:43:30 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Mon, 13 Jan 1997 17:09:16 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Mon, 13 Jan 1997 17:09:15 Eastern Standard Time Message-ID: <32DAB754.212D@ivex3d.com> Date: Mon, 13 Jan 1997 17:29:40 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Dual Updates frequencies ?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi : Is it possible to have different update frequencies for different objects in a scene ? For example, I have cloud models or other static objects on the terrain that don't change much between frames so I just want to update the rest of the scene every frame and these objects every two frames ? Thanks Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 13 17:14:47 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA13825; Mon, 13 Jan 1997 17:13:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA13809; Mon, 13 Jan 1997 17:13:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA25694; Mon, 13 Jan 1997 17:14:12 -0800 Received: from sable.nus.sg (sable.nus.sg [137.132.1.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA12978 for ; Mon, 13 Jan 1997 17:12:52 -0800 Received: from leonis.nus.sg (eng30228@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.8.4/8.6.9) with ESMTP id JAA14588 for ; Tue, 14 Jan 1997 09:12:43 +0800 (SST) Received: from localhost (eng30228@localhost) by leonis.nus.sg (8.6.10/8.6.9/CNS-3.5) with SMTP id JAA04869 for ; Tue, 14 Jan 1997 09:12:37 +0800 Date: Tue, 14 Jan 1997 09:12:36 +0800 (SST) From: Ming Wah To: info-performer@sgi.com Subject: POinter to coordinate list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi all, Does anyone know how to query a GEoSet and put a pointer to the list of coordinates? Can these coordinates be changed during simulation (update of position)? THanks!!!! Jon ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 00:32:51 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id AAA15536; Tue, 14 Jan 1997 00:28:49 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id AAA15520; Tue, 14 Jan 1997 00:28:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA13356; Tue, 14 Jan 1997 00:29:51 -0800 Received: from rtset.co.il (oren.rtset.co.il [194.90.96.233]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA15798 for ; Tue, 14 Jan 1997 00:28:26 -0800 Received: (from rany@localhost) by rtset.co.il (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA02424; Tue, 14 Jan 1997 10:27:16 +0200 Date: Tue, 14 Jan 1997 10:27:16 +0200 From: rany@rtset.co.il (Ran Yakir) Message-Id: <9701141027.ZM2422@oren.rtset.co.il> In-Reply-To: ulf.yngwe@mandator.se "Performer with dm pbuffers" (Jan 13, 5:01pm) References: X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ulf.yngwe@mandator.se Subject: Re: Performer with dm pbuffers Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 13, 5:01pm, ulf.yngwe@mandator.se wrote: > Subject: Performer with dm pbuffers > > Is there anybody who has used the digital media pbuffers with performer. I am > trying > to create a pbuffer to use performer to draw in, but i can't find out how to > create one. > If anyone has some piece of code it would be greatly apreciated. > The proper way to set up Performer with dmedia pbuffers, is through the calls pfPWinWSDrawable() and pfPWinGLCxt(). The drawable is the pbuffer and the context can be created with glXCreateContextWithConfigSGIX(). The problem is that only Performer 2.2 can get a pbuffer as a drawable. Performer 2.1 will crash on that. The way to work around this is creating a plain old pfPipeWindow, but call glXMakeCurrent with your pbuffer and context at the beginning of the drawing frame. Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | RT-SET Ltd. / )_ (_(_) ) \/ (_(_/<_(_)( | _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@rtset.co.il Work : 972-9-9552236 | rany@netvision.net.il Res. : 972-9-7489974 | Fax : 972-9-9552239 | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 01:10:51 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA15655; Tue, 14 Jan 1997 01:07:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA15639; Tue, 14 Jan 1997 01:07:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA14550; Tue, 14 Jan 1997 01:08:22 -0800 Received: from sable.nus.sg (sable.nus.sg [137.132.1.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA19943 for ; Tue, 14 Jan 1997 01:05:23 -0800 Received: from leonis.nus.sg (eng30228@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.8.4/8.6.9) with ESMTP id RAA22810 for ; Tue, 14 Jan 1997 17:04:50 +0800 (SST) Received: from localhost (eng30228@localhost) by leonis.nus.sg (8.6.10/8.6.9/CNS-3.5) with SMTP id RAA04411 for ; Tue, 14 Jan 1997 17:04:47 +0800 Date: Tue, 14 Jan 1997 17:04:46 +0800 (SST) From: Ming Wah To: info-performer@sgi.com Subject: Missing data Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi all, I recently managed to access the geoset of an object that I've loaded and grab a copy of the coordinates. I then have the coordinates updated by using pfXformPt3 and go the result below: PF Notice: Coordinates : 19.14 -72.35 14.10 PF Notice: Coordinates : -8.04 -101.60 16.62 PF Notice: Coordinates : 17.43 -95.93 39.41 PF Notice: Coordinates : 20.86 -127.65 25.90 PF Notice: Coordinates : 22.57 -104.07 0.59 PF Notice: Coordinates : 48.04 -98.40 23.38 PF Notice: Coordinates : 17.43 -95.93 39.41 PF Notice: Coordinates : 48.04 -98.40 23.38 PF Notice: Coordinates : 19.14 -72.35 14.10 PF Notice: Coordinates : 22.57 -104.07 0.59 PF Notice: Coordinates : -8.04 -101.60 16.62 PF Notice: Coordinates : 20.86 -127.65 25.90 PF Notice: Coordinates : 17.43 -95.93 39.41 PF Notice: Coordinates : 48.04 -98.40 23.38 I then used the function pfGsetAttr(geoset, PFGS_COORD3, PFGS_PER_VERTEX, xformedCoordList, CoordIndexList); to put the list back. What happen was that the data was ok except for the 1st x data, as shown below; Coord 0: X: 0.000000 Y: -72.352287 Z: 14.095881 Coord 1: X: -8.036339 Y: -101.596954 Z: 16.621561 Coord 2: X: 17.429119 Y: -95.934677 Z: 39.412964 Normal 0: NX: -0.707107 NY: 0.000000 NZ: 0.707107 Coord 3: X: 20.863346 Y: -127.647713 Z: 25.904119 Coord 4: X: 22.570877 Y: -104.065331 Z: 0.587032 Coord 5: X: 48.036331 Y: -98.403046 Z: 23.378439 Normal 1: NX: 0.707107 NY: 0.000000 NZ: -0.707107 Coord 6: X: 17.429119 Y: -95.934677 Z: 39.412964 Coord 7: X: 48.036331 Y: -98.403046 Z: 23.378439 Coord 8: X: 19.136639 Y: -72.352287 Z: 14.095881 Normal 2: NX: 0.000000 NY: 0.707107 NZ: 0.707107 Coord 9: X: 22.570877 Y: -104.065331 Z: 0.587032 Normal 3: NX: 0.000000 NY: 0.707107 NZ: -0.707107 Coord 10: X: -8.036339 Y: -101.596954 Z: 16.621561 Normal 4: NX: -0.707107 NY: 0.000000 NZ: -0.707107 Coord 11: X: 20.863346 Y: -127.647713 Z: 25.904119 Normal 5: NX: 0.000000 NY: -0.707107 NZ: -0.707107 Coord 12: X: 17.429119 Y: -95.934677 Z: 39.412964 Normal 6: NX: 0.000000 NY: -0.707107 NZ: 0.707107 Coord 13: X: 48.036331 Y: -98.403046 Z: 23.378439 Normal 7: NX: 0.707107 NY: 0.000000 NZ: 0.707107 The x component of Coord 0 is 0.0 instead of 19.4, can anybody tell me what's wrong? Thanks in advance! ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 01:32:23 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA15779; Tue, 14 Jan 1997 01:28:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA15763; Tue, 14 Jan 1997 01:28:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA15089; Tue, 14 Jan 1997 01:29:54 -0800 Received: from systech.hinet.net (systech.hinet.net [168.95.200.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id BAA22796 for ; Tue, 14 Jan 1997 01:28:22 -0800 Received: by systech.hinet.net (931110.SGI/930416.SGI.AUTO) for info-performer@sgi.com id AA01293; Tue, 14 Jan 97 17:29:55 -0800 Date: Tue, 14 Jan 97 17:29:55 -0800 From: terence@systech.hinet.net (Terence Ker) Message-Id: <9701150129.AA01293@systech.hinet.net> To: info-performer@sgi.com Subject: CAD model to OpenFlight format Status: O Hi, Performer; I am looking for a software tool for converting common CAD model format ( e.g. IGES, DXF) into Openflight format to be used for visual simulations. Does anyone know of a solution of this kind? -= Terence Ke =- Systems & Technology Taipei, Taiwan e-mail: terence@systech.hinet.net ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 02:00:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA15895; Tue, 14 Jan 1997 01:57:07 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA15879; Tue, 14 Jan 1997 01:57:06 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA15732; Tue, 14 Jan 1997 01:58:11 -0800 Received: from xr1.atlas.fr (xr1.atlas.fr [194.51.9.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA26267 for ; Tue, 14 Jan 1997 01:56:51 -0800 Message-Id: <199701140956.BAA26267@sgi.sgi.com> X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 14 Jan 1997 10:53:57 +0100 X400-Received: by mta xr1.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 14 Jan 1997 10:53:57 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; converted (ia5-text,iso (1) (0) (10021) (7) (1) (0) (1),iso (1) (0) (10021) (7) (1) (0) (6),iso (1) (0) (10021) (7) (1) (0) (100)); Relayed; Tue, 14 Jan 1997 10:03:37 +0100 X400-Received: by /PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/; Relayed; Tue, 14 Jan 1997 10:18:32 +0100 Date: Tue, 14 Jan 1997 10:18:32 +0100 X400-Originator: MICHAEL.BOCCARA@siege.aerospatiale.fr X400-Recipients: info-performer@sgi.com, guest@holodeck.csd.sgi.com X400-MTS-Identifier: [/PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/;970114091832] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: CSI NC V3.0 From: BOCCARA Michael To: "(Questions Performer)" (Receipt Notification Requested) (Non Receipt Notification Requested), Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: Question about pfTraverser MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Status: O =0C Hi members, I want to link my eyepoint with a DCS position. Let's call this DCS "trajDCS". My technique is to recuperate the acc= umulated matrix in trajDCS's app-callback, to invert it and to apply it in a = sceneDCS placed on top of my scene. The result is that in the next frame traversal, the accumulated matr= ix at trajDCS's level is identity. In fact the real accumulated matrix is identity, because ve= ry big coordinates are invoked and the invert pocedure faces problems of fl= oat precision. My aim is to "force" the accumulated matrix to be identity= when trajDCS is traversed, as if trajDCS was on top of the scene tree. Bu= t I refuse to break my scene hierarchy to force trajDCS to be on top of = it. A pfTraverser is passed as argument is the APP-callback function, th= at contains the accumulation matrix. I would like to be able to make th= e following call in my callback-function : trav->setMat(pfIdentMat); // where trav is the current pfTraverser But "setMat" is not a member function of the pfTraverser class. My question is : What can I do to reset the accumulation matrix to identity when traj= DCS is app-traversed ??? This operation is a part of Michael Jones' technique to trick with t= he problems of single/double precision. Indeed his advice was to set th= e origin to a point of a chunk of my scene, specified in double precision, an= d to refer all other DCS position relatively to this new origin. The trou= ble was that I didn't know how to set a new origin. The answer to my questio= n could be the solution I'm looking for. I hope my question was clear for anybody helpful, Thanks in advance Regards, Mike ______________________________________________ Micha=EBl Boccara ----------= ----- Software Engineer / "hang up the m= oon, Virtual Reality & Simulation Dpt. / switch on the sun, Aerospatiale, France / fill up the oceans= , ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''= '''''''''/ and dress up the trees." email : michael.boccara(a)siege.aerospatiale.fr Tel: (+33) 01 46 97 32 40 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 02:13:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA15976; Tue, 14 Jan 1997 02:09:59 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA15960; Tue, 14 Jan 1997 02:09:58 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA16216; Tue, 14 Jan 1997 02:11:03 -0800 Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA27850 for ; Tue, 14 Jan 1997 02:09:42 -0800 Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.8.3) for id LAA04052 (ESMTP). Tue, 14 Jan 1997 11:09:38 +0100 (MET) Received: from rcion@localhost by asterix.urc.tue.nl (8.8.4) for info-performer@sgi.com id LAA18481. Tue, 14 Jan 1997 11:09:36 +0100 (MET) From: Ion Barosan Message-Id: <199701141009.LAA18481@asterix.urc.tue.nl> Subject: Stereo display To: info-performer@sgi.com Date: Tue, 14 Jan 1997 11:09:36 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: O HI Performers, I would like to get some reaction from you about this : A friend of mine has a small theater and she is fascinated by the stereo projections mixted with life acting. I made some animations using Performer, recorded them and the I projected them on a large screen, but not stereo. My question is, is it possible to develop and record the animation stereo on an Onyx (I meen the stereo output of the animation) and then later display that animation stereo on a large screen ? What kind of extra hardware (projectors I need to display the recorded stereo animation on the large screen) I have to use ? I have seen something about the Stereo Projection Sceens using spatial multiplexing. Does some one has used one of this ? Another approach could be this : - I will generate the stereo images and store then on the Onyx - Then using an O2 (I don't know if he has an stereo option) of Indigo2 with stereo option I can play back the stereo animation and project that on the large screen. Using the infra-red sensors and the stereo glasses I can view the animation in 3D . Could be that a solution ? Any help will be appreciated, - Ion Barosan ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 02:15:26 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA15997; Tue, 14 Jan 1997 02:12:15 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA15981; Tue, 14 Jan 1997 02:12:14 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA16261; Tue, 14 Jan 1997 02:13:19 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA28253 for ; Tue, 14 Jan 1997 02:11:55 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.com id KAA08075; Tue, 14 Jan 1997 10:11:46 GMT From: "Angus Dorbie" Message-Id: <9701141011.ZM8073@bitch.reading.sgi.com> Date: Tue, 14 Jan 1997 10:11:46 +0000 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com Subject: Thought for the day. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I have a niggling doubt that the position print routine I emailed the other day called pfXformVec3 to transform the origin of a DCS to world space, I should have used pfXformPt3, incase anyone was watching. Sorry if you tried to use the code, I did warn it was untested. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 04:07:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA16379; Tue, 14 Jan 1997 04:04:07 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA16363; Tue, 14 Jan 1997 04:04:05 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA20155; Tue, 14 Jan 1997 04:05:10 -0800 Received: from mailgw1.fhg.de (mailgw1.fhg.de [153.96.1.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA12471 for ; Tue, 14 Jan 1997 04:03:48 -0800 From: scheff@iff.fhg.de Received: by mailgw1.fhg.de (fhg.de); Tue, 14 Jan 1997 13:02:52 +0100 (MET) X-ENV: (mailgw1.fhg.de) scheff@iff.fhg.de -> info-performer@sgi.com.VIA-SMTP Received: by mailgw1.fhg.de (fhg.de) with SMTP; Tue, 14 Jan 1997 13:02:46 +0100 (MET) from iff.fhg.de Received: by iff.fhg.de; Tue, 14 Jan 97 13:02:50 +0100 from sgi08.iff.fhg.de Date: Tue, 14 Jan 1997 13:03:06 +0100 Received: by sgi08.iff.fhg.de; Tue, 14 Jan 1997 13:03:06 +0100 Message-Id: <9701141303.ZM10223@sgi08> In-Reply-To: terence@systech.hinet.net (Terence Ker) "CAD model to OpenFlight format" (Jan 14, 17:29) References: <9701150129.AA01293@systech.hinet.net> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: terence@systech.hinet.net (Terence Ker) Subject: Re: CAD model to OpenFlight format Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Terence, there are some software products shipped with converters: - ProENGINEER contains (perhaps optional) an export filter for iv, - MultiGen is shipped with a lot of converters (for example iv->flt but also dxf->flt->dxf) - Clarus sells a software - CAD-Realtime-Link - to convert CAD models to VR models. (The advance: You can influence the triangulation process of freeform faces.) Hope this helps. Greetings, Dirk. -- ---------------------------------------------------- Dipl.-Inf. Dirk Scheffter scheff@iff.fhg.de Fraunhofer IFF Steinfeldstr. 3 fon: +49-39203/81591 D-39179 Barleben fax: +49-39203/81619 Germany ---------------------------------------------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 06:31:59 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA16705; Tue, 14 Jan 1997 06:28:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA16689; Tue, 14 Jan 1997 06:28:24 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA25097; Tue, 14 Jan 1997 06:29:29 -0800 Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id GAA01929 for ; Tue, 14 Jan 1997 06:28:11 -0800 Received: from taz by acusoft.com (5.x/SMI-SVR4) id AA20667; Tue, 14 Jan 1997 09:28:08 -0500 Received: by taz (950413.SGI.8.6.12) id JAA10327; Tue, 14 Jan 1997 09:19:06 -0500 Date: Tue, 14 Jan 1997 09:19:06 -0500 (EST) From: "Thomas M. Miller" X-Sender: miller@taz To: Terence Ker Cc: info-performer@sgi.com Subject: Re: CAD model to OpenFlight format In-Reply-To: <9701150129.AA01293@systech.hinet.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I have written a DSO for saving performer trees to Multigen Openflight 14.2. This would alow you to save anything that performer can load to FLT. If you want I can ask my boss what I can give it to you. --TMIV On Tue, 14 Jan 1997, Terence Ker wrote: > > Hi, Performer; > > I am looking for a software tool for converting common > CAD model format ( e.g. IGES, DXF) into Openflight format > to be used for visual simulations. Does anyone know of a solution > of this kind? ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 07:38:25 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA16917; Tue, 14 Jan 1997 07:33:53 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA16901; Tue, 14 Jan 1997 07:33:52 -0800 Received: from odin.corp.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA28685; Tue, 14 Jan 1997 07:35:07 -0800 Received: from hotsauce.clubfed.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id HAA26055; Tue, 14 Jan 1997 07:33:49 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA25042; Tue, 14 Jan 1997 10:32:46 -0500 Date: Tue, 14 Jan 1997 10:32:46 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701141032.ZM25041@hotsauce.clubfed.sgi.com> In-Reply-To: Ming Wah "POinter to coordinate list" (Jan 14, 9:12am) References: Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Ming Wah Subject: Re: POinter to coordinate list Cc: info-performer@fddi-odin.corp.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O You can use the getAttrLists method of pfGeoSet which gives you a pointer to the desired data if you change the information the pointer is pointing to it will cahnge in the scene. If you are using a multiprocess model for performer (APP_CULL_DRAW) you will want to use pfCycleBuffer's for the data you are going to update in the pfGeoSet. Here is some sample code I put into my updateSim() routine to generate a dynamic surface. ... static pfGeoSet *ocean; if(doOnce) { doOnce = False; pfGeode *temp = (pfGeode *) ViewState->scene->find("virtOcean", pfGeode::getClassType()); ocean = temp->getGSet(0); ... } ... #ifdef CYCLEBUFFERS pfCycleBuffer *coords; #else pfVec3 *coords; #endif pfVec3 *norms; ushort *n_ilist; ushort *vertexlist; ocean->getAttrLists(PFGS_COORD3, (void **)&coords, &vertexlist); ocean->getAttrLists(PFGS_NORMAL3, (void **)&norms, &n_ilist); Brian On Jan 14, 9:12am, Ming Wah wrote: > Subject: POinter to coordinate list > > Hi all, > Does anyone know how to query a GEoSet and put a pointer to the > list of coordinates? Can these coordinates be changed during simulation > (update of position)? > > > THanks!!!! > > Jon > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Ming Wah -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 08:12:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA17069; Tue, 14 Jan 1997 08:08:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA17053; Tue, 14 Jan 1997 08:08:50 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA01451; Tue, 14 Jan 1997 08:09:28 -0800 Received: from ecrc.ecrc.de (ecrc.de [141.1.1.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA19555 for ; Tue, 14 Jan 1997 08:08:10 -0800 Received: from scorpio.ecrc.de (scorpio.ecrc.de [141.1.4.100]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with ESMTP id RAA16323 for ; Tue, 14 Jan 1997 17:08:09 +0100 (MET) Received: from euclid.ecrc.de (euclid.ecrc.de [141.1.3.41]) by scorpio.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with ESMTP id RAA15984 for ; Tue, 14 Jan 1997 17:08:08 +0100 (MET) Received: (from erose@localhost) by euclid.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id RAA14646; Tue, 14 Jan 1997 17:10:53 +0100 (MET) Date: Tue, 14 Jan 1997 17:10:53 +0100 (MET) Message-Id: <199701141610.RAA14646@euclid.ecrc.de> From: Eric Rose To: info-performer@sgi.com Subject: job offer: augmented reality/Munich, Germany X-Face: 8?Ma>}.Duia{Pb\%\b9LnIkA3?,o=Xxb_U9x\(6C_vB6"-,&p9\1%[~FdT#C[8=f|8sEo48"w~Yv|,~%c/)r>Cdfq:(.O[=H3T)rG[;o+4H1_4H)H}+XA['sDM}N3)fjO%Jl&Aqi8>W0@%:2x;xlA]Pv)>#$h:(@fXmj|v~C|Z'[<7h5`0(^T5'Uu"s=3YA.n[~XD9K)#2kptJid Status: O 1.5-Year Research Position (Computer Graphics): Augmented Reality for Exterior Construction Applications ======================================================== The Fraunhofer Projectgroup "Augmented Reality" at ZGDV seeks a talented computer scientist to participate in a major European Commission-funded research project, CICC (Collaborative Integrated Communications for Construction). The position is available immediately and limited to the duration of the project (Aug. 98). Yet, the successful candidate will be strongly encouraged to continue research towards a Doctorate degree on followup projects. Job Description --------------- The candidate will be a member of a multinational research group developing augmented reality (AR) technology primarily for pilot-applications in the construction industry. Job activites include development, implementation, testing, and evaluation of novel AR visualization techniques, working with other members of the group to integrate computer-vision results into the AR visualization environment, and developing test scenarios for the construction industry. Some system support and administration within the group is also necessary. The position stresses technical knowledge, creativity, and self-sufficiency, as well as a desire to investigate new technologies and problem solutions. Education --------- Masters degree or Diplom in Computer Science or a related field. Experience ---------- A strong programming backround in C++/Unix is required, as well as knowledge of high-end Silicon Graphics machines and programming libraries. Experience in software engineering for real-time and interactive systems is also desirable. In addition, a good candidate should also have knowledge of some of the following: + Computer graphics, including - OpenGL - CAD systems and 3D file formats + X/Motif + Software engineering + Virtual Reality (VR), including - input devices: magnetic trackers, etc - head-mounted displays + Video - video on Silicon Graphics - video hardware + Multiprocessing and shared-memory + System administration and support + Silicon Graphics hardware - Reality Engine or Infinite Reality graphics hardware + IRIX software libraries, such as - ViewKit - ImageVision - RapidApp - Digial Media (Video Library) - Open Inventor - IRIS Performer - Cosmo 3D + The C++ Standard Template Library Our Affiliation --------------- The Fraunhofer Projectgroup Augmented Reality at ZGDV belongs to the House of Computer Graphics in Darmstadt which consists of the Fraunhofer Institut for Computer Graphics (FhG-IGD), the Computer Graphics Center e.V. (ZGDV), and the Interactive Graphic Systems Group at the University of Darmstadt. For operational reasons, the Projectgroup Augmented Reality is currently located in Munich, Germany. Munich and its surroundings is one of Europe's high-tech centers, with numerous computer and manufacturing companies, and a major technical university located in the area. Munich is also a great place to live. It is home to the world famous Oktoberfest and other festivals, close to the Alps and surrounded by numerous lakes. Culturally, Munich offers a variety of museums, art galleries, and concert venues. Munich is also centrally located for travel to other parts of Europe. How to Apply ------------ To apply, send a resume, the names and addresses of at least three references, your telephone number and e-mail address to the address listed below. Only written applications will be considered. Write to -------- Gudrun Klinker Fraunhofer Projektgruppe fuer Augmented Reality im ZGDV Arabellastrasse 17 (ECRC) D-81925 Munich Germany More information ---------------- http://www.igd.fhg.de/~klinker -- Eric Rose http://www.ecrc.de/staff/erose/ Fraunhofer Projektgruppe fuer Augmented Reality im Zentrum fuer Grafische Datenverarbeitung (ZGDv) eV Email: erose@ecrc.de European Computer-Industry Research Centre (ECRC) GmbH Phone: +49-89-92699-201 Arabellastrasse 17, D-81925 Munich FAX: +49-89-92699-170 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 08:38:30 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA17214; Tue, 14 Jan 1997 08:34:46 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA17198; Tue, 14 Jan 1997 08:34:44 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA03973; Tue, 14 Jan 1997 08:35:49 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA24942 for ; Tue, 14 Jan 1997 08:34:31 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA25251; Tue, 14 Jan 1997 11:33:34 -0500 Date: Tue, 14 Jan 1997 11:33:34 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701141133.ZM25250@hotsauce.clubfed.sgi.com> In-Reply-To: terence@systech.hinet.net (Terence Ker) "CAD model to OpenFlight format" (Jan 14, 5:29pm) References: <9701150129.AA01293@systech.hinet.net> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: terence@systech.hinet.net (Terence Ker), info-performer@sgi.com Subject: Re: CAD model to OpenFlight format Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O THe Multigen toolkit provides a dxftoflt utility, call Multigen. Brian On Jan 14, 5:29pm, Terence Ker wrote: > Subject: CAD model to OpenFlight format > > Hi, Performer; > > I am looking for a software tool for converting common > CAD model format ( e.g. IGES, DXF) into Openflight format > to be used for visual simulations. Does anyone know of a solution > of this kind? > > > > > -= Terence Ke =- > > Systems & Technology > Taipei, Taiwan > e-mail: terence@systech.hinet.net > > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Terence Ker -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 10:15:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA17584; Tue, 14 Jan 1997 10:12:06 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA17568; Tue, 14 Jan 1997 10:12:05 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA12807; Tue, 14 Jan 1997 10:13:10 -0800 Received: from newton.ncsa.uiuc.edu (newton.ncsa.uiuc.edu [141.142.2.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA19789 for ; Tue, 14 Jan 1997 10:11:53 -0800 Received: from eads.ncsa.uiuc.edu (eads.ncsa.uiuc.edu [141.142.4.3]) by newton.ncsa.uiuc.edu (8.8.4/8.8.4) with SMTP id MAA03872; Tue, 14 Jan 1997 12:11:52 -0600 (CST) Date: Tue, 14 Jan 1997 12:08:55 -0600 (CST) From: "Dee A. Chapman" To: info-performer@sgi.com cc: "Dee A. Chapman" Subject: pfuAddDelay - object disappears Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hello, I would like to use "pfuAddDelay()" function in the middle of a path. However, when the object following the path encounters the "pfuAddDelay" function, it disappears from view for the length of time of the delay. After the delay, it reappears and continues following the path. Has anyone else had this experience? If so, is there a work around? Thanks! Dee ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 12:05:36 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA18318; Tue, 14 Jan 1997 12:00:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA18302; Tue, 14 Jan 1997 12:00:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA23816; Tue, 14 Jan 1997 12:01:59 -0800 Received: from nvsgi1.netvision.net.il (nvsgi1.NetVision.net.il [194.90.1.31]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA16900 for ; Tue, 14 Jan 1997 12:00:39 -0800 Received: from streptacocus (ts007p15.pop9a.netvision.net.il [194.90.11.143]) by nvsgi1.netvision.net.il (8.7.5/8.7.3) with SMTP id WAA10261 for ; Tue, 14 Jan 1997 22:01:20 +0200 (IST) Sender: internet@nvsgi1.netvision.net.il Message-ID: <32DBDF55.41C6@netvision.net.il> Date: Tue, 14 Jan 1997 21:32:37 +0200 From: Orad Hi-Tec Systems X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: info-performer@sgi.com Subject: NOT synchronizing to vertical retrace Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O I want to synchronize my Performer app to an event different from a vertical retrace of the framebuffer (i.e., NOT to glXSwapBuffers(), glXWaitVideoSyncSGI(), etc.). If I refrain from calling pfSync() directly, it gets called internally by pfFrame(). How can I do this? For simplicity, lets assume that we are running single-process. Moshe Nissim Orad Hi-Tec Systems ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 12:40:33 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA18528; Tue, 14 Jan 1997 12:37:21 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA18512; Tue, 14 Jan 1997 12:37:20 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA27479; Tue, 14 Jan 1997 12:38:25 -0800 Received: from crdems.ge.com (crdems.GE.COM [192.35.44.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA25441 for ; Tue, 14 Jan 1997 12:37:04 -0800 Received: from bart.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA23481; Tue, 14 Jan 97 15:29:30 -0500 Received: from bart by bart.crd.ge.com (SMI-8.6/GE-CRD Standard Sendmail Version S1.5)id PAA01064; Tue, 14 Jan 1997 15:29:37 -0500 Sender: volpe@ash.crd.ge.com Message-Id: <32DBECB0.21AD@ash.crd.ge.com> Date: Tue, 14 Jan 1997 15:29:36 -0500 From: Christopher R Volpe Organization: GE Corporate Research & Development, Schenectady, NY X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: Christopher R Volpe Cc: Sharon Clay , Fred Clyne , Christopher R Volpe , info-performer@sgi.com Subject: Solution: Re: Sudden X/Performer problem References: <32D2D4D4.1296@ash.crd.ge.com> <9701081304.ZM13842@octave> <9701081058.ZM28017@rose.asd.sgi.com> <32DA9881.58E4@ash.crd.ge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Christopher R Volpe (that's me) wrote: > > [Sharon describes how to tell if I'm a victim of this strange shared arena bug] > Yup. That's my beast. I get lots o' them. However, if I compile the > entire application with -mips4 (I'm on an R10000), the problem > disappears. However, I suspect that's only because -mips4 allows the use > of certain instructions which cause the resulting code size to shrink, > therefore leaving more room between the shared arena and the brk point. Bogus explanation on my part. For some reason I thought the heap was at the top of the virtual address space, and the brk value was trying to grow down into the shared arena, which was being placed too close below the heap. Don't know why I thought that. I compared the brk value to the pfGetSharedArenaBase() value after doing an explicit pfInitArenas(). They are equal when compiled with the default -mips3 (thereby preventing the brk value from being increased by subsequent calls to malloc -- this is the bug), but when compiled with -mips4, there's a 128Mb gap between the brk value and the shared arena base, thereby allowing the brk value to grow by a nice hefty amount if it needs to during the course of the execution. So, I decided to ensure that I had enough mallocable space by malloccing and freeing some memory prior to initializing the shared arena. I mallocced and freed 16MB, under the assumption that this would be enough to shift the brk point a little, leaving enough room for whatever pfInit needed. But I noticed that the arena base was now placed 128Mb beyond the brk point, no longer right at the brk point. So, maybe just moving the brk point at all causes the bug to disappear and allows the shared arena base to be placed where it should, 128MB beyond the brk point. I tested this by scrapping the malloc/free of 16MB and replaced it with sbrk(1), i.e. move the brk point by one byte. Sure enough, this did the trick. So, if anyone else runs into this problem, before hardcoding virtual addresses for the shared arena with pfSharedArenaBase(), try putting a sbrk(1) before your pfInit() call. Now, the question on my mind is: What on earth would tell Irix to allocate shared arena right at the brk point, and why does it only do this under certain circumstances? -Chris -- Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr@crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 12:54:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA18616; Tue, 14 Jan 1997 12:51:46 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA18600; Tue, 14 Jan 1997 12:51:44 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id MAA15488; Tue, 14 Jan 1997 12:51:33 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id MAA12780; Tue, 14 Jan 1997 12:51:31 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701142051.MAA12780@remi.asd.sgi.com> Subject: Re: NOT synchronizing to vertical retrace To: orad_u@netvision.net.il (Orad Hi-Tec Systems) Date: Tue, 14 Jan 1997 12:51:31 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: <32DBDF55.41C6@netvision.net.il> from "Orad Hi-Tec Systems" at Jan 14, 97 09:32:37 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 826 Status: O Orad Hi-Tec Systems wrote: > > I want to synchronize my Performer app to an event different > from a vertical retrace of the framebuffer (i.e., NOT to > glXSwapBuffers(), glXWaitVideoSyncSGI(), etc.). If I refrain > from calling pfSync() directly, it gets called internally by > pfFrame(). > How can I do this? > For simplicity, lets assume that we are running single-process. A swap buffer is always on a vertial retrace. This is because you want to avoid switching from two different images in a middle of a retrace. But, you can synchronize (genlock) the vertical retrace to an external source using ircombine if it's what you want to do Best Regards _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 14:34:06 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA19077; Tue, 14 Jan 1997 14:30:43 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA19061; Tue, 14 Jan 1997 14:30:41 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA07789; Tue, 14 Jan 1997 14:31:46 -0800 Received: from gdi4.gdi.net (gdi4.gdi.net [205.160.184.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA21695 for ; Tue, 14 Jan 1997 14:30:26 -0800 Received: by gdi4.gdi.net (5.65/1.2-eef) id AA06749; Tue, 14 Jan 97 17:31:14 -0500 Message-Id: <9701142231.AA06749@gdi4.gdi.net> From: pratts@gdi4.gdi.net (Shirley Pratt) X-Mailer: SCO System V Mail (version 3.2) To: info-performer@sgi.com Subject: 2.1 vs 2.0 for Max Impacts Cc: pratts@gdi4.gdi.net Date: Tue, 14 Jan 97 17:31:13 EST Status: O Help needed please! The group I work with just recently got about a DOZEN fully loaded Indigo 2 Max Impacts. They bought Performer as well but got a dozen CDs with Performer 2.1 was shipped to them, not Performer 2.0. Everything I have read on the web page, seen in this mail group, read in the release notes indicates that Performer 2.0 should be used with these Max Impacts. HOWEVER, when they have tried to inquire about getting the correct version, at least 2 sales people don't seem to know anything about the difference between Performer 2.0 and Performer 2.1. Specifically, they've been told that the latest one we should get is Performer 2.1. So we've read them what is on the Performer web page about the issue. One was in Dallas, and the other is in Mtn View (Keith Duncan, 415-933-2542) who is supposed to be checking up on this but has not yet responded back. Could someone with some technical clout PLEASE tell me for sure if Performer 2.0 is still indeed the right one for the Max Impacts? And if so, somehow pass the message on to the people selling the product. Our group has invested alot of $$ in these machines and software and are very frustrated by the inconsistent advice we've been getting. Thanks for any help, Shirley ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Shirley Pratt TRADOC Analysis Center - WSMR Operations Research Analyst ATTN: ATRC-WAA Soldier Station Simulation & Analysis White Sands Missile Range New Mexico 88002-5502 Stationed in Orlando, FL until 1/98 :D Email: pratts@gdi.net or pratts@dis.trac.wsmr.army.mil Phone: (407) 673-3610 FAX: (407) 679-3220* * Pls notify me by e-mail if you send me a FAX. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 15:16:30 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA19384; Tue, 14 Jan 1997 15:13:22 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA19368; Tue, 14 Jan 1997 15:13:21 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA11672; Tue, 14 Jan 1997 15:14:26 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA02935 for ; Tue, 14 Jan 1997 15:13:09 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id PAA11668; Tue, 14 Jan 1997 15:14:25 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id PAA15577; Tue, 14 Jan 1997 15:13:19 -0800 From: "Rob Jenkins" Message-Id: <9701141513.ZM15575@quid.csd.sgi.com> Date: Tue, 14 Jan 1997 15:13:18 -0800 In-Reply-To: pratts@gdi4.gdi.net (Shirley Pratt) "2.1 vs 2.0 for Max Impacts" (Jan 14, 5:31pm) References: <9701142231.AA06749@gdi4.gdi.net> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: pratts@gdi4.gdi.net (Shirley Pratt), info-performer@sgi.com Subject: Re: 2.1 vs 2.0 for Max Impacts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Shirley The relnotes for Performer 2.1 do say that officially it's only tested on Infinite Reality but that it should be OK on other platforms. We've actually found more and more people running pf 2.1 on other platforms such as Impact with no problems ( at least not associated with pf 2.1 specifically ). I'd say go with pf 2.1 - we certianly don't turn support calls away because a customer is running 2.1 on a non-iR machine. I suppose you could say that now 2.1 has been pretty well tested on other platforms since those relnotes were written. A couple of things to note: Most of the benefits of 2.1 will only be seen by iR. The differences between 2.1 and 2.0 are pretty techy - if you need info like this in the future then by all means use sales as one channel but don't hestitate to speak to tech. support as well. Obviously Performer specific queries like this one are ideal for this forum too. Hope this clears things up - let me know if you have anymore questions. Cheers Rob -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 15:37:15 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA19509; Tue, 14 Jan 1997 15:34:09 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA19493; Tue, 14 Jan 1997 15:34:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA14130; Tue, 14 Jan 1997 15:35:12 -0800 Received: from splinters.paradigmsim.com (splinters.paradigmsim.com [206.7.114.140]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08183 for ; Tue, 14 Jan 1997 15:33:49 -0800 Received: from splinters (localhost [127.0.0.1]) by splinters.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA24463; Tue, 14 Jan 1997 17:32:46 -0600 Sender: mew@paradigmsim.com Message-ID: <32DC179E.4287@paradigmsim.com> Date: Tue, 14 Jan 1997 17:32:46 -0600 From: Mike Weiblen Organization: Paradigm Simulation, Inc. X-Mailer: Mozilla 3.0 (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Ion Barosan CC: info-performer@sgi.com Subject: Re: Stereo display References: <199701141009.LAA18481@asterix.urc.tue.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Ion, I did something similar several years ago, on a much smaller scale, using an Amiga. For ~US$10, I build a box that detected the sync from a video signal and reconstructed the control signal for some LCD shutter goggles. (See http://www.access.digex.net/~mew/syncbox.html for details) I don't know of a commercial solution, but the proof-of-concept worked. Cheers -- mew Ion Barosan wrote: > A friend of mine has a small theater and she is fascinated by the > stereo projections mixted with life acting. > I made some animations using Performer, recorded them and the I projected > them on a large screen, but not stereo. > > My question is, is it possible to develop and record the animation stereo on > an Onyx (I meen the stereo output of the animation) and then later display > that animation stereo on a large screen ? -- Mike Weiblen talkto:972-960-2301 x292 PARADIGM Simulation, Inc. faxto:972-960-2303 14900 Landmark, Suite 400 mailto:mew@paradigmsim.com Dallas TX 75240 http://www.paradigmsim.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 16:24:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id QAA19797; Tue, 14 Jan 1997 16:21:38 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA19781; Tue, 14 Jan 1997 16:21:36 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id QAA25854; Tue, 14 Jan 1997 16:21:28 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id QAA13632; Tue, 14 Jan 1997 16:21:27 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701150021.QAA13632@remi.asd.sgi.com> Subject: Re: glReadPixels To: WILLIAM_MARINELLI@ntsc.navy.mil Date: Tue, 14 Jan 1997 16:21:27 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: <9700138531.AA853187997@CCMAIL.NTSC.NAVY.MIL> from "WILLIAM_MARINELLI@ntsc.navy.mil" at Jan 13, 97 12:35:29 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1474 Status: O WILLIAM_MARINELLI@ntsc.navy.mil wrote: > > I'm posting this to both groups because it's a vega app but seems > applicable to both in the context of a post draw callback. > > Opinions about using glReadPixels to approximte the distance an object > is away from the eyepoint (simulate a laser range finder)? > > I use > > glReadPixels(640,512,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,f); should be ................................................&f > > ^^^^^^^ ^^^ ^^^^^^^^^^^^^^^^^^ > middle 1 z buffer value > of pixel > screen > > > then try to scale it appropriately with the near and far clip planes. > > f returns with a float value between 0 and one. I suppose that the > Ifinite Reality Floating point z buffer has been accounted for when > this float is spit out. > > At this point the returned depth buffer value is scaled quite large; > ie, you pitch down to the ground and the returned value is still quite > high (.4). If you use a perspective matrix, you have to apply the inverse of the matrix tu find z (a simple scale is not enough ) z = 2*far*near / (far+near - (far - near) * (2. * f -1.)); _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 16:35:14 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id QAA19843; Tue, 14 Jan 1997 16:32:07 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA19827; Tue, 14 Jan 1997 16:32:06 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id QAA26647; Tue, 14 Jan 1997 16:31:51 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id QAA13674; Tue, 14 Jan 1997 16:31:49 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701150031.QAA13674@remi.asd.sgi.com> Subject: Re: Custom texture filtering To: reymond@corysmailserv.corys.fr (Gilles Reymond) Date: Tue, 14 Jan 1997 16:31:48 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: <9701131529.AA00483@cos2.4s205.corys> from "Gilles Reymond" at Jan 13, 97 04:29:51 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1382 Status: O Gilles Reymond wrote: > > Hi, > > Has anyone some experience with gltexfilterfuncsgis - or its IrisGl counterpart > texdef2d(TX_MIPMAP_FILTER_KERNEL) ? Warning: this filter option has a cost of 2X in fill. > > My particular problem is to deal with a repeated RGBA texture mapped onto a > polygon strip going away to the horizon. Using mipmapping > GL_LINEAR_MIPMAP_LINEAR causes some artifacts in the rendering of the farthest > side of the object, where the min_filter supposedly becomes active. I guess this > is due to the particular structure of the texture. > This effect was experienced both on iR and RE2 systems, though with slight > rendering aspect differences. > > Hence, my questions are : > > - was is the weighting policy used by standard trilinear mipmapping on > those systems ? > - would a custom-designed set of weights help solve my problem ? > - what is the recommended method for chosing these weights (through > Performer calls, maybe)? > The first thing you should do is to provide your own texture LOD, instead of using the default ones. So you could remove some high frequency you have in the smallest LODs. Unfortunately for you, this is available only with OpenGL. _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 16:45:50 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id QAA19927; Tue, 14 Jan 1997 16:42:34 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA19911; Tue, 14 Jan 1997 16:42:33 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id QAA20008; Tue, 14 Jan 1997 16:43:38 -0800 Received: from daisy.paradigmsim.com (daisy.paradigmsim.com [206.7.114.129]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA26016 for ; Tue, 14 Jan 1997 16:42:20 -0800 Received: (from eliza@localhost) by daisy.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA03333; Tue, 14 Jan 1997 18:38:14 -0600 From: "Elizabeth Smith" Message-Id: <9701141838.ZM3332@daisy.paradigmsim.com> Date: Tue, 14 Jan 1997 18:38:14 -0600 In-Reply-To: "Rob Jenkins" "Re: 2.1 vs 2.0 for Max Impacts" (Jan 14, 3:13pm) References: <9701142231.AA06749@gdi4.gdi.net> <9701141513.ZM15575@quid.csd.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Rob Jenkins" Subject: Re: 2.1 vs 2.0 for Max Impacts Cc: info-performer@sgi.com, pratts@gdi4.gdi.net (Shirley Pratt) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 14, 3:13pm, Rob Jenkins wrote: > Subject: Re: 2.1 vs 2.0 for Max Impacts > Shirley > > The relnotes for Performer 2.1 do say that officially it's only tested on > Infinite Reality but that it should be OK on other platforms. We've actually > found more and more people running pf 2.1 on other platforms such as Impact > with no problems ( at least not associated with pf 2.1 specifically ). > > I'd say go with pf 2.1 - we certianly don't turn support calls away because a > customer is running 2.1 on a non-iR machine. I suppose you could say that now > 2.1 has been pretty well tested on other platforms since those relnotes were > written. Other issues to consider: Isn't Performer 2.1 released only for IRIX6.2? It is OpenGL only (okay, of course, for Impacts, O2s, iRs). There are several bugs in 2.1 and 2.0 which have been fixed in the 2.0.2 patches (1347 and 1392 for IRIX6.2). These patches repair libraries from Performer 2.0 and 2.0.1 only, but these patches do not apply to the Performer 2.1 libraries (the ones tagged sgi3.0). We've also had difficulty linking statically with Performer 2.1 libraries, but not with 2.0.2. For these reasons, we've avoided using Performer 2.1 on anything but the iR, but are interested in hearing more about 2.1 on non-iR systems. We would like to use it for all platforms if we can get around the above problems. Are there any long term "success" stories out there? > A couple of things to note: > > Most of the benefits of 2.1 will only be seen by iR. > The differences between 2.1 and 2.0 are pretty techy - if you need info like > this in the future then by all means use sales as one channel but don't > hestitate to speak to tech. support as well. Obviously Performer specific > queries like this one are ideal for this forum too. > > Hope this clears things up - let me know if you have anymore questions. > > Cheers > Rob > > -- > ________________________________________________________________ > Rob Jenkins mailto:robj@csd.sgi.com > Silicon Graphics, Mtn View, California, USA > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Rob Jenkins -- |---- Elizabeth Smith ---- | | 972-960-2301 (voice) Paradigm Simulation, Inc. | | 972-960-9049 (FAX) 14900 Landmark, Suite 400 | | eliza@paradigmsim.com Dallas, Texas 75240 USA | | http://www.paradigmsim.com | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 20:33:12 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id UAA20901; Tue, 14 Jan 1997 20:29:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id UAA20885; Tue, 14 Jan 1997 20:29:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id UAA02745; Tue, 14 Jan 1997 20:30:54 -0800 Received: from gdi4.gdi.net (gdi4.gdi.net [205.160.184.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA03690 for ; Tue, 14 Jan 1997 20:29:35 -0800 Received: by gdi4.gdi.net (5.65/1.2-eef) id AA25478; Tue, 14 Jan 97 23:30:22 -0500 Message-Id: <9701150430.AA25478@gdi4.gdi.net> From: pratts@gdi4.gdi.net (Shirley Pratt) X-Mailer: SCO System V Mail (version 3.2) To: info-performer@sgi.com Subject: Re: 2.1 vs 2.0 for Max Impacts Date: Tue, 14 Jan 97 23:30:21 EST Status: O >From: "Howard Larson" >Date: Tue, 14 Jan 1997 19:28:41 -0800 >To: pratts@gdi4.gdi.net (Shirley Pratt) >Subject: Re: 2.1 vs 2.0 for Max Impacts > > What does "recently got" mean... IRIX 6.4 with R10000 cpus ? ^^^ ??? This bunch we got are all Indigo 2 Max Impacts with R10000 CPU, IRIX 6.2 > >Performer 2.0 came out Dec 95, > >you should use Performer 2.1 > if you do NOT have a R4400 in your Indigo 2 Max Impacts OK, BUT a couple other ones we already have are Indigo 2 Max Impacts with R4400 CPUs. We'll need to install what works on all our Max Impacts to remain sane so I'll recommend upgrades to R10000 for those ;) Thanks for your input, Shirley ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *********************** Note new job info ************************* Shirley Pratt TRADOC Analysis Center - WSMR Operations Research Analyst ATTN: ATRC-WAA Soldier Station Simulation & Analysis White Sands Missile Range New Mexico 88002-5502 Stationed in Orlando, FL until 1/98 :D Email: pratts@gdi.net or pratts@dis.trac.wsmr.army.mil Phone: (407) 673-3610 FAX: (407) 679-3220* * Pls notify me by e-mail if you send me a FAX. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 14 22:46:53 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id WAA21436; Tue, 14 Jan 1997 22:43:52 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id WAA21420; Tue, 14 Jan 1997 22:43:50 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for <@giraffe.asd.sgi.com:info-performer@holodeck.csd.sgi.com> id WAA06845; Tue, 14 Jan 1997 22:43:37 -0800 Received: from giraffe.asd.sgi.com by remi.asd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) id WAA15090; Tue, 14 Jan 1997 22:43:27 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id WAA06835; Tue, 14 Jan 1997 22:43:27 -0800 Received: from nvsgi1.netvision.net.il (nvsgi1.NetVision.net.il [194.90.1.31]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA24721; Tue, 14 Jan 1997 22:43:22 -0800 Received: from streptacocus (ts008p13.pop9a.netvision.net.il [194.90.11.159]) by nvsgi1.netvision.net.il (8.7.5/8.7.3) with SMTP id IAA09583; Wed, 15 Jan 1997 08:44:14 +0200 (IST) Sender: internet@nvsgi1.netvision.net.il Message-ID: <32DC75C5.41C6@netvision.net.il> Date: Wed, 15 Jan 1997 08:14:29 +0200 From: Orad Hi-Tec Systems X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: "Rémi Arnaud" CC: info-performer@remi.asd.sgi.com Subject: Re: NOT synchronizing to vertical retrace References: <199701142051.MAA12780@remi.asd.sgi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Status: O R=E9mi Arnaud wrote: > A swap buffer is always on a vertial retrace. This is because > you want to avoid switching from two different images in > a middle of a retrace. >=20 > But, you can synchronize (genlock) the vertical retrace to an > external source using ircombine if it's what you want to do >=20 Maybe I didn't make myself clear enough. I *dont* want to swap buffers: > > an event different > > from a vertical retrace of the framebuffer (i.e., NOT to > > glXSwapBuffers(), glXWaitVideoSyncSGI(), etc.). Of course, a buffer swap has to synchronize (or at least pend rasterization of the following GL tokens) to a vertical retrace. Moshe Nissim Orad Hi-Tec Systems ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 01:22:49 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA21945; Wed, 15 Jan 1997 01:19:03 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA21929; Wed, 15 Jan 1997 01:19:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA13098; Wed, 15 Jan 1997 01:20:09 -0800 Received: from MOEsun.edu.tw (moesun.edu.tw [140.111.1.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA13902 for ; Wed, 15 Jan 1997 01:17:48 -0800 Received: from nchc.gov.tw (dns.nchc.gov.tw [140.110.192.11]) by MOEsun.edu.tw (8.6.13/8.6.13) with SMTP id RAA23543 for ; Wed, 15 Jan 1997 17:19:33 +0800 Received: by nchc.gov.tw (th3.8s.nchc.gov) from ceres.nchc.gov.tw id AA04172; Wed, 15 Jan 97 17:02:10 CST Received: by ceres.nchc.gov.tw (station v4.0) from elc044.dt1.nchc id AA21185; Wed, 15 Jan 97 17:16:59 CST From: c00chu00@nchc.gov.tw (Sam Chu) Message-Id: <9701150916.AA21185@ceres.nchc.gov.tw> Subject: Infrared Mode To: info-performer@sgi.com Date: Wed, 15 Jan 1997 17:17:01 +0800 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 814 Status: O Hi Performers: Would anyone give me some advise to implement the infrared mode in SGI Performer(I use MultiGenII to create models)? In MultiGen II, I can assign Infrared Color and IR Material to face (polygon), but how can I use these attributes in Performer to implement the infrared mode? Also how can I decide the value of infrared color for different objects(how much for trees or how much for the tank?)? From the doc of "OpenFlight loader R15.2 for IRIS Performer 2.x",this Loader will ignore infrared (color). Can I still use this loader to implement the infrared mode? Thank you for your assistance in advance. Regards, Sam Chu National Center for High-Performance Computing Scientific Visualization Lab Email: c00chu00@nchc.gov.tw Tel: (886)35-776085 Ext 248 Fax : (886)35-773538 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 02:00:31 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA22192; Wed, 15 Jan 1997 01:57:07 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA22176; Wed, 15 Jan 1997 01:57:05 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA14331; Wed, 15 Jan 1997 01:58:14 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA18825; Wed, 15 Jan 1997 01:56:48 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA09532; Wed, 15 Jan 1997 09:56:43 GMT From: "Angus Dorbie" Message-Id: <9701150956.ZM9530@bitch.reading.sgi.com> Date: Wed, 15 Jan 1997 09:56:43 +0000 In-Reply-To: Orad Hi-Tec Systems "NOT synchronizing to vertical retrace" (Jan 14, 9:32pm) References: <32DBDF55.41C6@netvision.net.il> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Orad Hi-Tec Systems , info-performer@sgi.com Subject: Re: NOT synchronizing to vertical retrace Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 14, 9:32pm, Orad Hi-Tec Systems wrote: > Subject: NOT synchronizing to vertical retrace > I want to synchronize my Performer app to an event different > from a vertical retrace of the framebuffer (i.e., NOT to > glXSwapBuffers(), glXWaitVideoSyncSGI(), etc.). If I refrain > from calling pfSync() directly, it gets called internally by > pfFrame(). > How can I do this? > For simplicity, lets assume that we are running single-process. > The video rate is king. Even if you lock the app to a different rate you'll still experience problems because your draw will still render to a multiple of the video. You either have to genlock the video to bring the I.G. into line or use the vertical sync to lock your i/o. You could also try resampling the data to match your video rate and don't bother with the lock. Usually this is less than an optimal solution. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 03:23:12 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA22468; Wed, 15 Jan 1997 03:19:50 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA22452; Wed, 15 Jan 1997 03:19:48 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA16976; Wed, 15 Jan 1997 03:20:57 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id DAA01042 for ; Wed, 15 Jan 1997 03:19:34 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-10.mail.demon.net id aa1025965; 15 Jan 97 11:03 GMT From: Mark Baranowski To: info-performer@sgi.com Subject: Q: How to find current Xform for a given node? Date: Wed, 15 Jan 1997 11:03:49 GMT Organization: Pera Message-ID: <32dcb493.8331420@post.demon.co.uk> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O Hi, I have a requirement to determine the current transformation matrix applicable to specific nodes in my Scene graph. Specifically I need this information for use in the Intersection process. My current approach uses an intersection traversal callback on the specified nodes which calls pfGetTravMat to store the matrix. The intersection process makes calls to pfNodeIsectSegs and/or pfChanNodeIsectSegs several times as part of it's processing before I do the processing which makes use of the stored transformation matrices. The problem I have is that the intersection traversal triggered by the calls to pfNodeIsectSegs etc may not reach the nodes with my callback attached. Can anyone suggest a way of getting the current transformation matrix for a specific node which doesn't have this problem? TIA. Mark. --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leicestershire. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 04:15:49 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA22618; Wed, 15 Jan 1997 04:12:25 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA22602; Wed, 15 Jan 1997 04:12:24 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA18866; Wed, 15 Jan 1997 04:13:32 -0800 Received: from triveni.newdelhi.sgi.com ([155.11.203.42]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA07398 for ; Wed, 15 Jan 1997 04:12:02 -0800 Received: by triveni.newdelhi.sgi.com (940816.SGI.8.6.9/930416.SGI) for info-performer@sgi.com id QAA01850; Wed, 15 Jan 1997 16:58:45 -0800 From: "Siva Sankaran" Message-Id: <9701151658.ZM1848@triveni.newdelhi.sgi.com> Date: Wed, 15 Jan 1997 16:58:44 -0800 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com Subject: My MultiGen model developed on RE2 and MultiGenII 1.0 does not work on IR! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, I have develoeped a walkthrough model on RE2, using MultiGenII 1.0. When I load the model using perfly on IR machine the model gets loaded with no textures at all. Even while loading the textures at the strart up of the Perfly it just shows white rectangles being loaded. Then I try loading same data base using MultiGenII 1.0 on IR, even MultiGen also has a problem with it. The textures are loaded in texture pallet and if I select any texture from the pallete, suddenly it becomes visible on wrongly applied polygone. Other polygones continue to be white. I use Performer 2.0 with OpenFlight 14.x Performer loader. Is there any changes in MultiGen and it's loader for IR. Is it available online as patches so that I can download. Sunil Hadap ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 04:55:58 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA22738; Wed, 15 Jan 1997 04:52:36 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA22722; Wed, 15 Jan 1997 04:52:35 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA20146; Wed, 15 Jan 1997 04:53:43 -0800 Received: from philos.philosys.de (philos.philosys.de [193.100.254.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id EAA12135 for ; Wed, 15 Jan 1997 04:52:06 -0800 Received: from indy.philosys.de by philos.philosys.de (4.1/SMI-4.1) id AA06038; Wed, 15 Jan 97 13:48:48 +0100 Received: by indy.philosys.de (950511.SGI.8.6.12.PATCH526/940406.SGI) id NAA12451; Wed, 15 Jan 1997 13:47:12 +0100 From: Thomas.Steudten@philosys.de (Thomas Steudten) Message-Id: <199701151247.NAA12451@indy.philosys.de> Subject: Q: No picking of pfbillboards? To: info-performer@sgi.com, thomas@philosys.de (Thomas Steudten) Date: Wed, 15 Jan 1997 13:47:12 +0100 (MET) Organisation: Philosys Software GmbH, Unterschleissheim, Germany Reply-To: Thomas.Steudten@philosys.de X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 873 Status: O Hi, i've tried to pick some billboards in a scene graph by the call NrHits = pfChanPick( Channel, PFPK_M_NEAREST|PFTRAV_IS_PRIM, ChannelX, ChannelY, 0.0f, PickList ). But i got always NrHits = 0 for billboards. Other objects are ok for picking. Isn't it possible to pick billboards? Our equipment: Performer 2.0, OpenGL, Irix 5.3, 6.3, indy and some O2's. Regards, Thomas ================= KERNEL PANIC: /dev/null full ============================ | | | PHILOSYS Software GmbH | Phone: (+49) 89 321407-31 Dipl.-Ing. | Carl von Linde Str. 30a | Fax: (+49) 89 321407-36/12 Thomas Steudten | D-85716 Unterschleissheim | Url: http://www.philosys.de | Germany | Email: thomas@philosys.de ============================================================================ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 05:16:09 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA22799; Wed, 15 Jan 1997 05:12:49 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA22783; Wed, 15 Jan 1997 05:12:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA21184; Wed, 15 Jan 1997 05:13:56 -0800 Received: from systech.hinet.net (systech.hinet.net [168.95.200.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id FAA14467 for ; Wed, 15 Jan 1997 05:12:13 -0800 Received: by systech.hinet.net (931110.SGI/930416.SGI.AUTO) for info-performer@sgi.com id AA05546; Wed, 15 Jan 97 21:13:49 -0800 From: "Jim" Message-Id: <9701152113.ZM5544@systech.hinet.net> Date: Wed, 15 Jan 1997 21:13:18 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.com Subject: one of polygons disappear Cc: jim@systech.hinet.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi Performer: I construct a cone which composed of ten-triangles. The pfGSet vertices coord.s of triagles like [ x+R*sin(n*pi/5) ,y+R*cos(n*pi/5) , z] [ x ,y , z-length] [ x+R*sin((n+1)*pi/5), y+R*cos((n+1)*pi/5), z] n ----- 0 Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA22821; Wed, 15 Jan 1997 05:16:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA21403; Wed, 15 Jan 1997 05:17:24 -0800 Received: from hil-img-3.compuserve.com (hil-img-3.compuserve.com [149.174.177.133]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA14696 for ; Wed, 15 Jan 1997 05:16:01 -0800 Received: by hil-img-3.compuserve.com (8.6.10/5.950515) id IAA07154; Wed, 15 Jan 1997 08:15:53 -0500 Date: 15 Jan 97 08:14:32 EST From: Jean BENOIT <101372.3460@CompuServe.COM> To: info_performer Subject: Texture detail and zbuffer on Impact Message-ID: <970115131432_101372.3460_JHP77-1@CompuServe.COM> Status: O I work on Impact 5.3 with patch 1414 or 6.2 with patch 1392, 1347. With these patches have have always the same problem : - Bad texture detail on terrain - zbuffer problems ( face behind another has drawn), it's good when I put the near at 40m. I load a MultiGen file, may be is a loader problem ? Yoel. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 06:07:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA23100; Wed, 15 Jan 1997 06:03:34 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA23084; Wed, 15 Jan 1997 06:03:33 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA23229; Wed, 15 Jan 1997 06:04:42 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA21083 for ; Wed, 15 Jan 1997 06:03:14 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id JAA00085; Wed, 15 Jan 1997 09:03:07 -0500 (EST) Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 15 Jan 97 08:59:38 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 15 Jan 97 08:59:27 EST From: "Jude Anthony" Organization: Enzian Technology, Inc. To: info-performer@sgi.com Date: Wed, 15 Jan 1997 08:59:19 EST Subject: Re: Scene Density Requirements X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: <137F0E13C1B@P3.ENZIAN.COM> Status: O I'm getting some conflicting answers on this problem, so I'm asking for more opinions. (Majority rules? On a technical question? Hmmm...) In general, this is a question concerning draw speed, fill rate, and depth complexity. The machine is an RE2 with 2RM4s. The application runs in a 1024x768 screen. From all calculations I've seen so far, the test scene I'm trying to render should go at 30Hz; yet it has a draw time of 33.1ms, and runs no faster than 20Hz. (Statistics from perfly or vega application.) The scene consists of strips of tris, overlapped so that none are completely obscured, sometimes up to six deep. The scene was created with MultiGen, and I arranged the objects so that they are sorted back-to-front, since they all have the same Z. The strips are meshed for their entire length. In short, it looks something like this: +----------------+ | +----------------+ | | +----------------+ + | | | + | | +----------------+ The strips are placed at a distance from the observer such that one database unit is one pixel. The strips constitute the following numbers and sizes of triangles: 150 tris, 101x101 1350 tris, 51x51 1500 tris, 10x10 None of the above is negotiable; it's all set out in the test document. Our average depth complexity for the scene is somewhere between 3.31 and 3.33. (Perfly/Vega statistics again.) The rated pixel fill rate for 2 RM4s is 110Mpix/sec. Our scene contains: 150 x 101 x 101 / 2 = 765,075 + 1350 x 51 x 51 / 2 = 1,755,675 + 1500 x 10 x 10 / 2 = 75,000 -------------------------------- 2,595,750 pixels. At 30Hz, that makes 2,595,750 * 30 = 77,872,500pix/sec, which is below the rated fill rate, so shouldn't be causing a problem. Question 1: Am I missing some important calculation here? From this calculation, this app should run 30Hz without even breathing hard. I must be missing something. Maybe I need to add the screen clearing and Z-buffer clearing pixels in here? Question 2: Is there any way to increase the speed of this app to 30Hz? I found that by eliminating multisampling, turning off the Z-buffer altogether, or not clearing the Z-buffer, I can increase the iteration rate. Unfortunately, I'm not allowed to change those things, since the test app conditions are supposed to match the simulation conditions. I also find that moving the observer back just a little speeds things up. Question 3: In what way does depth complexity directly affect render speed? If every pixel of every polygon is compared against the Z-buffer before it is drawn, then it should make no difference to speed if I overlap several polygon strips or spread them out over the screen (as long as the number of pixels remains constant). In each case, every pixel gets compared against the Z-buffer once before it is drawn, resulting in the same number of comparisons ever time. Is there some other way that depth complexity affects render speed, or am I misiniformed with respect to the Z-buffer algorythm? Any help would be greatly appreciated. Thanks, Jude Anthony jude@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 06:13:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA23129; Wed, 15 Jan 1997 06:09:53 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA23113; Wed, 15 Jan 1997 06:09:51 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA23382; Wed, 15 Jan 1997 06:11:00 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id GAA21876 for ; Wed, 15 Jan 1997 06:09:38 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-10.mail.demon.net id aa1010204; 15 Jan 97 13:40 GMT From: Mark Baranowski To: Siva Sankaran , info-performer@sgi.com Subject: Re: My MultiGen model developed on RE2 and MultiGenII 1.0 does not work on IR! Date: Wed, 15 Jan 1997 13:40:35 GMT Organization: Pera Message-ID: <32dcddf0.18914439@post.demon.co.uk> References: <9701151658.ZM1848@triveni.newdelhi.sgi.com> In-Reply-To: <9701151658.ZM1848@triveni.newdelhi.sgi.com> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O On Wed, 15 Jan 1997 16:58:44 -0800, Sunil wrote: >Hi, > >I have develoeped a walkthrough model on RE2, using MultiGenII 1.0. When= I load >the model using perfly on IR machine the model gets loaded with no = textures at >all. Even while loading the textures at the strart up of the Perfly it = just >shows white rectangles being loaded. > >Then I try loading same data base using MultiGenII 1.0 on IR, even = MultiGen >also has a problem with it. The textures are loaded in texture pallet = and if I >select any texture from the pallete, suddenly it becomes visible on = wrongly >applied polygone. Other polygones continue to be white. > >I use Performer 2.0 with OpenFlight 14.x Performer loader. > >Is there any changes in MultiGen and it's loader for IR. Is it available= online >as patches so that I can download. Are the dimensions of your textures powers of two (e.g. 64x128, 256x256, 512x32 etc)? Mark. --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leicestershire. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 06:35:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA23238; Wed, 15 Jan 1997 06:31:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA23222; Wed, 15 Jan 1997 06:31:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA24145; Wed, 15 Jan 1997 06:33:03 -0800 Received: from relay.interserv.com (relay.interserv.com [165.121.2.67]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id GAA24900 for ; Wed, 15 Jan 1997 06:31:31 -0800 From: inca@public.bta.net.cn Received: from 202.96.62.2 ([202.96.62.2]) by relay.interserv.com with SMTP id AA17604 (5.67b/IDA-1.5 for info-performer@sgi.com); Wed, 15 Jan 1997 06:31:25 -0800 Date: Wed, 15 Jan 1997 06:31:25 -0800 Message-Id: <199701151431.AA17604@relay.interserv.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Texture & multi-pfPipeWindows on iR To: info-performer@sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Hi, ---- on Aug 16, 1996, Sharon Clay wrote: >This is because each pfPipeWindow has a separate graphics context so >when you have to change pfPipeWindows, a graphics context switch occurs. >One additional issue is the management of textures and display lists >between graphics contexts. By default separate graphics >contexts do _not_ share textures which means that you might be >running out of texture memory from duplicated textures. >You can verify if this is the case with performer graphics stats - they >will show texture downloads happening. >If this is your trouble, you can attach multiple pfPipeWindows (the >default Performer share mask specifies to share GL objects, PFWIN_SHARE_GL_OBJS). it's only available in PFMP_APPCULLDRAW. this is result of test: APPCULLDRAW APP_CULLDRAW APPCULL_DRAW 1 pfPipeWindows 100% 100% 100% 2 shared 100% 50% 50% 2 not shared 50% 50% 50% 3 shared 100% 33% 33% 3 not shared 33% 33% 33% the number in table is boundary, speed down if go beyond the limit. test on iR/2xR4400, 2xRM6, IRIX6.2, PF2.1, patch 1355(Aug,96 second release). Question: is it a normal behaviour, known bug, or my mistake ? I'm able to supply source code if necessary. Thanks for any help! liubin ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 08:15:52 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA23750; Wed, 15 Jan 1997 08:12:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA23734; Wed, 15 Jan 1997 08:12:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA00964; Wed, 15 Jan 1997 08:13:34 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13938 for ; Wed, 15 Jan 1997 08:12:08 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id LAA04930; Wed, 15 Jan 1997 11:11:59 -0500 (EST) Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 15 Jan 97 11:08:30 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 15 Jan 97 11:08:11 EST From: "Jude Anthony" Organization: Enzian Technology, Inc. To: info-performer@sgi.com Date: Wed, 15 Jan 1997 11:08:02 EST Subject: Re: Scene Density Requirements X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: <13A163802E3@P3.ENZIAN.COM> Status: O I'm getting some conflicting answers on this problem, so I'm asking for more opinions. (Majority rules? On a technical question? Hmmm...) In general, this is a question concerning draw speed, fill rate, and depth complexity. I've been asked to repost this question, including whether or not I'm using a pfESky, and how the screen is cleared. When this thing actually runs, it's a Vega app; I'm not certain how they use pfESky. I've got a sky color, and my envrionment is enabled; I believe it's PFES_FAST. Lynx doesn't mention an option for screen clearing; the closest I've seen is "Buffer Clearing" which is set with the Z-Buffer and Frame Buffer buttons checked, but not the Stencil or MS Buffer buttons. I've sent this to the Vega group as well, to get answers for these questions (I hope). The machine is an RE2 with 2RM4s. The application runs in a 1024x768 screen. From all calculations I've seen so far, the test scene I'm trying to render should go at 30Hz; yet it has a draw time of 33.1ms, and runs no faster than 20Hz. (Statistics from perfly or vega application.) The scene consists of strips of tris, overlapped so that none are completely obscured, sometimes up to six deep. The scene was created with MultiGen, and I arranged the objects so that they are sorted back-to-front, since they all have the same Z. The strips are meshed for their entire length. In short, it looks something like this: +----------------+ | +----------------+ | | +----------------+ + | | | + | | +----------------+ The strips are placed at a distance from the observer such that one database unit is one pixel. The strips constitute the following numbers and sizes of triangles: 150 tris, 101x101 1350 tris, 51x51 1500 tris, 10x10 None of the above is negotiable; it's all set out in the test document. Our average depth complexity for the scene is somewhere between 3.31 and 3.33. (Perfly/Vega statistics again.) The rated pixel fill rate for 2 RM4s is 110Mpix/sec. Our scene contains: 150 x 101 x 101 / 2 = 765,075 + 1350 x 51 x 51 / 2 = 1,755,675 + 1500 x 10 x 10 / 2 = 75,000 -------------------------------- 2,595,750 pixels. At 30Hz, that makes 2,595,750 * 30 = 77,872,500pix/sec, which is below the rated fill rate, so shouldn't be causing a problem. Question 1: Am I missing some important calculation here? From this calculation, this app should run 30Hz without even breathing hard. I must be missing something. Maybe I need to add the screen clearing and Z-buffer clearing pixels in here? Question 2: Is there any way to increase the speed of this app to 30Hz? I found that by eliminating multisampling, turning off the Z-buffer altogether, or not clearing the Z-buffer, I can increase the iteration rate. Unfortunately, I'm not allowed to change those things, since the test app conditions are supposed to match the simulation conditions. I also find that moving the observer back just a little speeds things up. Question 3: In what way does depth complexity directly affect render speed? If every pixel of every polygon is compared against the Z-buffer before it is drawn, then it should make no difference to speed if I overlap several polygon strips or spread them out over the screen (as long as the number of pixels remains constant). In each case, every pixel gets compared against the Z-buffer once before it is drawn, resulting in the same number of comparisons ever time. Is there some other way that depth complexity affects render speed, or am I misiniformed with respect to the Z-buffer algorythm? Any help would be greatly appreciated. Thanks, Jude Anthony jude@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 08:19:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA23772; Wed, 15 Jan 1997 08:15:50 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA23756; Wed, 15 Jan 1997 08:15:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA01192; Wed, 15 Jan 1997 08:16:58 -0800 Received: from python.tamu.edu (python.tamu.edu [128.194.11.99]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA14480 for ; Wed, 15 Jan 1997 08:15:31 -0800 Received: (from renjye@localhost) by python.tamu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA22769 for info-performer@sgi.com; Wed, 15 Jan 1997 08:16:40 -0800 From: "Ren-Jye Yu" Message-Id: <9701150816.ZM22768@python.tamu.edu> Date: Wed, 15 Jan 1997 08:16:39 -0800 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: pfDrawChanStats() Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi everybody, I used pfDrawChanStats to show the statistics diagram. I have three channels in one pipeline. At first, I used third channel to show the diagram. But after I used the draw_callback, this statistics diagram disappear. I tried all the channels. It still not work. I used draw_callback to draw HUD. I like to know how does the HUD affect the frame rate. If anybody know how to bring the statistics diagram back? Thanks. -- _______________________________________________________________________________ ("`-''-/").___..--''"`-._ Ren-Jye Yu `6_ 6 ) `-. ( ).`-.__.`) Email :renjye@python.tamu.edu (_Y_.)' ._ ) `._ `. ``-..-' Phone(O) :(409) 845-0729 _..`--'_..-_/ /--'_.' ,' (H) :(409) 691-8570 (il),-'' (li),' ((!.-' Address :Aerospace Engineering Department H.R. Bright Building Texas A&M University College Station 77840-3141 _______________________________________________________________________________ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 08:33:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA23831; Wed, 15 Jan 1997 08:29:44 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA23815; Wed, 15 Jan 1997 08:29:42 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA02573; Wed, 15 Jan 1997 08:30:51 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17544 for ; Wed, 15 Jan 1997 08:29:29 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA28373; Wed, 15 Jan 1997 11:28:33 -0500 Date: Wed, 15 Jan 1997 11:28:33 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701151128.ZM28372@hotsauce.clubfed.sgi.com> In-Reply-To: Jean BENOIT <101372.3460@compuserve.com> "Texture detail and zbuffer on Impact" (Jan 15, 8:14am) References: <970115131432_101372.3460_JHP77-1@CompuServe.COM> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Jean BENOIT <101372.3460@compuserve.com>, info_performer Subject: Re: Texture detail and zbuffer on Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 15, 8:14am, Jean BENOIT wrote: > Subject: Texture detail and zbuffer on Impact > I work on Impact 5.3 with patch 1414 or 6.2 with patch 1392, 1347. > With these patches have have always the same problem : > - Bad texture detail on terrain Do the textures look dithered? Do you have 1 meg TRAMs or 4 meg TRAMs on this IMPACT? You will see dithering with 1 meg TRAMs. > - zbuffer problems ( face behind another has drawn), it's good when I put the > near at 40m. This is a zbuffer resolution problem you have to move the objects further apart, use the pfLayer facility ,not sure how this is done in MultiGen, or shorten the distance between the near and far clipping plane. You have already done the thrid solution this increases the resolution of the zbuffer allowing your objects to be properly sorted. Probably the most universal solution would be to implement pfLayers through MultiGen. Brian > > I load a MultiGen file, may be is a loader problem ? > Yoel. > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Jean BENOIT -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 09:09:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA24104; Wed, 15 Jan 1997 09:06:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA24088; Wed, 15 Jan 1997 09:06:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA06017; Wed, 15 Jan 1997 09:07:15 -0800 Received: from nvsgi1.netvision.net.il (nvsgi1.NetVision.net.il [194.90.1.31]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA25573; Wed, 15 Jan 1997 09:05:46 -0800 Received: from streptacocus (ts003p13.pop9a.netvision.net.il [194.90.11.69]) by nvsgi1.netvision.net.il (8.7.5/8.7.3) with SMTP id TAA27199; Wed, 15 Jan 1997 19:05:18 +0200 (IST) Sender: internet@nvsgi1.netvision.net.il Message-ID: <32DD070D.41C6@netvision.net.il> Date: Wed, 15 Jan 1997 18:34:21 +0200 From: Orad Hi-Tec Systems X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Angus Dorbie CC: info-performer@sgi.com Subject: Re: NOT synchronizing to vertical retrace References: <32DBDF55.41C6@netvision.net.il> <9701150956.ZM9530@bitch.reading.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Angus Dorbie wrote: > > On Jan 14, 9:32pm, Orad Hi-Tec Systems wrote: > > Subject: NOT synchronizing to vertical retrace > > I want to synchronize my Performer app to an event different > > from a vertical retrace of the framebuffer (i.e., NOT to > > glXSwapBuffers(), glXWaitVideoSyncSGI(), etc.). If I refrain > > from calling pfSync() directly, it gets called internally by > > pfFrame(). > > How can I do this? > > For simplicity, lets assume that we are running single-process. > > > > The video rate is king. Even if you lock the app to a different rate > you'll still experience problems because your draw will still render > to a multiple of the video. You either have to genlock the video to > bring the I.G. into line or use the vertical sync to lock your i/o. > > You could also try resampling the data to match your video rate and > don't bother with the lock. Usually this is less than an optimal > solution. > > Cheers, > Angus. The video rate is king only if I am rendering into the framebuffer. (And even then, only if the drawable is double-buffered and I am trying to swap the buffers). But here I am rendering to an off-screen PBuffer! (which of course doesn't need "swapbuffers") Moshe Nissim Orad Hi-Tec Systems ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 09:22:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA24194; Wed, 15 Jan 1997 09:19:01 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA24178; Wed, 15 Jan 1997 09:19:00 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA07717; Wed, 15 Jan 1997 09:20:09 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA28887; Wed, 15 Jan 1997 09:18:34 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA10077; Wed, 15 Jan 1997 17:17:28 GMT From: "Angus Dorbie" Message-Id: <9701151717.ZM10075@bitch.reading.sgi.com> Date: Wed, 15 Jan 1997 17:17:27 +0000 In-Reply-To: "Jude Anthony" "Re: Scene Density Requirements" (Jan 15, 8:59am) References: <137F0E13C1B@P3.ENZIAN.COM> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Jude Anthony" , info-performer@sgi.com Subject: Re: Scene Density Requirements Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 15, 8:59am, Jude Anthony wrote: > Subject: Re: Scene Density Requirements > I'm getting some conflicting answers on this problem, so I'm asking for more > opinions. (Majority rules? On a technical question? Hmmm...) > > In general, this is a question concerning draw speed, fill rate, and depth > complexity. > > The machine is an RE2 with 2RM4s. The application runs in a 1024x768 screen. > From all calculations I've seen so far, the test scene I'm trying to render > should go at 30Hz; yet it has a draw time of 33.1ms, and runs no faster than > 20Hz. (Statistics from perfly or vega application.) > > The scene consists of strips of tris, overlapped so that none are completely > obscured, sometimes up to six deep. The scene was created with MultiGen, > and I arranged the objects so that they are sorted back-to-front, since they > all have the same Z. The strips are meshed for their entire length. In > short, it looks something like this: > > +----------------+ > | +----------------+ > | | +----------------+ > + | | | > + | | > +----------------+ > > The strips are placed at a distance from the observer such that one database > unit is one pixel. The strips constitute the following numbers and sizes of > triangles: > 150 tris, 101x101 > 1350 tris, 51x51 > 1500 tris, 10x10 > > None of the above is negotiable; it's all set out in the test document. > > Our average depth complexity for the scene is somewhere between 3.31 and > 3.33. (Perfly/Vega statistics again.) > > The rated pixel fill rate for 2 RM4s is 110Mpix/sec. Our scene contains: > 150 x 101 x 101 / 2 = 765,075 > + 1350 x 51 x 51 / 2 = 1,755,675 > + 1500 x 10 x 10 / 2 = 75,000 > -------------------------------- > 2,595,750 pixels. > At 30Hz, that makes 2,595,750 * 30 = 77,872,500pix/sec, which is below the > rated fill rate, so shouldn't be causing a problem. > > Question 1: Am I missing some important calculation here? > > From this calculation, this app should run 30Hz without even breathing > hard. I must be missing something. Maybe I need to add the screen clearing > and Z-buffer clearing pixels in here? You should certainly factor in the time taken to clear the screen. I've seen 1ms measured for 1280x1024 on iR. > > Question 2: Is there any way to increase the speed of this app to 30Hz? > > I found that by eliminating multisampling, turning off the Z-buffer > altogether, or not clearing the Z-buffer, I can increase the iteration rate. > Unfortunately, I'm not allowed to change those things, since the test app > conditions are supposed to match the simulation conditions. > I also find that moving the observer back just a little speeds things up. Have you display listed the geometry which you draw? Have you installed patch 1355? Draw your larger polygons first if allowed and mix large and small if you are able. If texturing then use simpler internal formats like RGB 555. Try flat shading if you can get away with it. Make sure modes like blending are disabled. > > Question 3: In what way does depth complexity directly affect render speed? > > If every pixel of every polygon is compared against the Z-buffer before it > is drawn, then it should make no difference to speed if I overlap several > polygon strips or spread them out over the screen (as long as the number of > pixels remains constant). In each case, every pixel gets compared against > the Z-buffer once before it is drawn, resulting in the same number of > comparisons ever time. Is there some other way that depth complexity affects > render speed, or am I misiniformed with respect to the Z-buffer algorythm? This is correct, z buffering isn't the only issue but on our systems your reasoning is fine for a lot of cases. It may help to use simpler texture filters, and does help to use smaller texture formats, blending & shading. Small polygons will will not give good fill performance. Cheers, Angus ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 09:29:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA24270; Wed, 15 Jan 1997 09:25:41 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA24254; Wed, 15 Jan 1997 09:25:40 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA08527; Wed, 15 Jan 1997 09:26:49 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00571; Wed, 15 Jan 1997 09:25:21 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA10101; Wed, 15 Jan 1997 17:25:15 GMT From: "Angus Dorbie" Message-Id: <9701151725.ZM10099@bitch.reading.sgi.com> Date: Wed, 15 Jan 1997 17:25:15 +0000 In-Reply-To: brian@sgi.com (Brian Furtaw) "Re: Texture detail and zbuffer on Impact" (Jan 15, 11:28am) References: <970115131432_101372.3460_JHP77-1@CompuServe.COM> <9701151128.ZM28372@hotsauce.clubfed.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: brian@sgi.com, Jean BENOIT <101372.3460@compuserve.com>, info_performer Subject: Re: Texture detail and zbuffer on Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 15, 11:28am, Brian Furtaw wrote: > > This is a zbuffer resolution problem you have to move the objects further > apart, use the pfLayer facility ,not sure how this is done in MultiGen, You use subfaces; select a polygon as parent instead of an object and then create polygons. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 09:51:19 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA24607; Wed, 15 Jan 1997 09:47:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA24591; Wed, 15 Jan 1997 09:47:56 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA11083; Wed, 15 Jan 1997 09:49:05 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06368; Wed, 15 Jan 1997 09:47:37 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA10133; Wed, 15 Jan 1997 17:47:29 GMT From: "Angus Dorbie" Message-Id: <9701151747.ZM10131@bitch.reading.sgi.com> Date: Wed, 15 Jan 1997 17:47:28 +0000 In-Reply-To: "Angus Dorbie" "Re: Scene Density Requirements" (Jan 15, 5:17pm) References: <137F0E13C1B@P3.ENZIAN.COM> <9701151717.ZM10075@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Jude Anthony" , info-performer@sgi.com Subject: Re: Scene Density Requirements Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 15, 5:17pm, Angus Dorbie wrote: > This is correct, z buffering isn't the only issue but on our systems your > reasoning is fine for a lot of cases. It may help to use simpler texture > filters, and does help to use smaller texture formats, blending & shading. ^ | Should read "less blending & simpler shading"--------------------/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 09:46:30 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA24488; Wed, 15 Jan 1997 09:42:52 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA24472; Wed, 15 Jan 1997 09:42:51 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA10381; Wed, 15 Jan 1997 09:44:00 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA05064 for ; Wed, 15 Jan 1997 09:42:39 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id JAA10371; Wed, 15 Jan 1997 09:43:58 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id JAA16905; Wed, 15 Jan 1997 09:42:48 -0800 From: "Rob Jenkins" Message-Id: <9701150942.ZM16903@quid.csd.sgi.com> Date: Wed, 15 Jan 1997 09:42:48 -0800 In-Reply-To: Jean BENOIT <101372.3460@CompuServe.COM> "Texture detail and zbuffer on Impact" (Jan 15, 8:14am) References: <970115131432_101372.3460_JHP77-1@CompuServe.COM> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Jean BENOIT <101372.3460@CompuServe.COM>, info_performer Subject: Re: Texture detail and zbuffer on Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 15, 8:14am, Jean BENOIT wrote: > Subject: Texture detail and zbuffer on Impact > I work on Impact 5.3 with patch 1414 or 6.2 with patch 1392, 1347. > With these patches have have always the same problem : > - Bad texture detail on terrain > - zbuffer problems ( face behind another has drawn), it's good when I put the > near at 40m. > > I load a MultiGen file, may be is a loader problem ? > Yoel. > ****** All Impacts should have at least the latest Impact gfx patches on ****** Irix 5.3: 1332 - Impact Graphics bug fixes for 5.3 1543 - X server fixes for Impact graphics Irix 6.2: 1422 - IGLOO (IrisGL On OpenGL) patch for O2, Impact and InfiniteReality 1447 - Bug fix patch for Indigo2 Impact and Impact 10000 1574 - X server patch for Irix 6.2, all platforms except Infinite Reality I'm not saying thet'll fix all gfx problems but they fix an awful lot - it's pointless trying to diagnose gfx problems without them installed. Note: the above are only the recommended gfx patches, not the whole recommended patch list for Impact. If you use Impacts at all please read this again :-) Cheers Rob -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 10:35:34 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA24970; Wed, 15 Jan 1997 10:31:34 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA24954; Wed, 15 Jan 1997 10:31:33 -0800 Received: from roll.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA16651; Wed, 15 Jan 1997 10:32:42 -0800 Received: from odin.corp.sgi.com by roll.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA25650; Wed, 15 Jan 1997 10:22:40 -0800 Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id KAA07531; Wed, 15 Jan 1997 10:22:39 -0800 Received: from wolfe.net (mail1.wolfe.net [204.157.98.11]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15741; Wed, 15 Jan 1997 10:22:35 -0800 Received: from gonzo.wolfenet.com (moore@gonzo.wolfenet.com [204.157.98.2]) by wolfe.net (8.8.0/8.8.0) with ESMTP id KAA20732; Wed, 15 Jan 1997 10:24:07 -0800 (PST) From: Timothy Moore Received: (from moore@localhost) by gonzo.wolfenet.com (8.8.3/8.7) id KAA22052; Wed, 15 Jan 1997 10:22:27 -0800 (PST) Date: Wed, 15 Jan 1997 10:22:27 -0800 (PST) Message-Id: <199701151822.KAA22052@gonzo.wolfenet.com> To: dorbie@bitch.reading.sgi.com CC: jude@p3.enzian.com, info-performer@sgi.com In-reply-to: "Angus Dorbie"'s message of Wed, 15 Jan 1997 17:17:27 +0000 <9701151717.ZM10075@bitch.reading.sgi.com> Subject: Re: Scene Density Requirements Status: O From: "Angus Dorbie" Date: Wed, 15 Jan 1997 17:17:27 +0000 References: <137F0E13C1B@P3.ENZIAN.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jan 15, 8:59am, Jude Anthony wrote: > > Question 1: Am I missing some important calculation here? > > From this calculation, this app should run 30Hz without even breathing > hard. I must be missing something. Maybe I need to add the screen clearing > and Z-buffer clearing pixels in here? You should certainly factor in the time taken to clear the screen. I've seen 1ms measured for 1280x1024 on iR. It's quite a bit more than that on an RE2 (the machine in question), no? I recall a number of 12ms for a screen and Z-buffer clear, though this can be overlapped with other graphics operations. The pfEskyMode may be an important factor in this test. If you can use PFES_SKY_GND or PFES_SKY instead of PFES_SKY_CLEAR you'll get better performance (but I don't know how that translates into Vega). > > Question 2: Is there any way to increase the speed of this app to 30Hz? > > I found that by eliminating multisampling, turning off the Z-buffer > altogether, or not clearing the Z-buffer, I can increase the iteration rate. > Unfortunately, I'm not allowed to change those things, since the test app > conditions are supposed to match the simulation conditions. > I also find that moving the observer back just a little speeds things up. Have you display listed the geometry which you draw? Seems like that would reduce this usefulness of this test as a simulation benchmark. Have you installed patch 1355? This is an RE2... > > Question 3: In what way does depth complexity directly affect render speed? > > If every pixel of every polygon is compared against the Z-buffer before it > is drawn, then it should make no difference to speed if I overlap several > polygon strips or spread them out over the screen (as long as the number of > pixels remains constant). In each case, every pixel gets compared against > the Z-buffer once before it is drawn, resulting in the same number of > comparisons ever time. Is there some other way that depth complexity affects > render speed, or am I misiniformed with respect to the Z-buffer algorythm? This is correct, z buffering isn't the only issue but on our systems your reasoning is fine for a lot of cases. It may help to use simpler texture filters, and does help to use smaller texture formats, blending & shading. Small polygons will will not give good fill performance. The test has a depth complexity greater than 1, so you're going to overlap polygons. Also, Z-buffer comparison is not the only cost associated with pixel fill. In addition to the texturing, blending and shading costs mentioned by Angus, There is the cost of updating the color and Z buffers if the depth test succeeds. So, you may get a measurably better fill rate if you render polygons front to back, especially if the near polygons are large and occlude much of the geometry behind them. This may violate the conditions of your test, but on the other hand it is realistic for many simulation applications (e.g., rendering own vehicle geometry). Tim ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 10:35:33 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA24952; Wed, 15 Jan 1997 10:31:30 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA24936; Wed, 15 Jan 1997 10:31:28 -0800 Received: from roll.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA16624; Wed, 15 Jan 1997 10:32:36 -0800 Received: from odin.corp.sgi.com by roll.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA25759; Wed, 15 Jan 1997 10:25:06 -0800 Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id KAA08307; Wed, 15 Jan 1997 10:25:05 -0800 Received: from amelnx.advmar.com (amelnx.advmar.com [152.136.205.23]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA16296 for ; Wed, 15 Jan 1997 10:24:58 -0800 From: Hill_Brian@amelnx.advmar.com Received: from cc:Mail by amelnx.advmar.com id AA853363575; Wed, 15 Jan 97 13:25:29 EST Date: Wed, 15 Jan 97 13:25:29 EST Encoding: 13 Text Message-Id: <9700158533.AA853363575@amelnx.advmar.com> To: info-performer@sgi.com, info-vega@paradigmsim.com Subject: Looking for underwater visual effects Status: O Performers, Can someone point me towards existing programs or demos that illustrate underwater visual effects? I am referring to range of visibility, murkiness, shimmering, light dispersal/propagation, bubbles, what the water surface looks like from under water, and anything else that can be thought of. Thanks, Brian Hill hill_brian@advmar.com 703 413 9200 ext 4035 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 10:49:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA25052; Wed, 15 Jan 1997 10:46:24 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA25036; Wed, 15 Jan 1997 10:46:23 -0800 Received: from roll.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA18485; Wed, 15 Jan 1997 10:47:31 -0800 Received: from odin.corp.sgi.com by roll.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA26068; Wed, 15 Jan 1997 10:32:03 -0800 Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id KAA10297; Wed, 15 Jan 1997 10:32:03 -0800 Received: from server.rtset.co.il ([194.90.96.254]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18051 for ; Wed, 15 Jan 1997 10:31:27 -0800 Received: from rtset.co.il (amit.rtset.co.il [194.90.96.238]) by server.rtset.co.il (8.6.12/8.6.9) with ESMTP id UAA18833; Tue, 16 Jan 1996 20:50:21 +0200 Received: (from rany@localhost) by rtset.co.il (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA10813; Wed, 15 Jan 1997 19:50:39 +0200 From: "Ran Yakir" Message-Id: <9701151950.ZM10811@amit> Date: Wed, 15 Jan 1997 19:50:38 +0000 In-Reply-To: "Jude Anthony" "Re: Scene Density Requirements" (Jan 15, 11:08am) References: <13A163802E3@P3.ENZIAN.COM> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Jude Anthony" Subject: Re: Scene Density Requirements Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19701151950.ZM10811.amit" Status: O -- --PART-BOUNDARY=.19701151950.ZM10811.amit Content-Type: text/plain; charset=us-ascii On Jan 15, 11:08am, Jude Anthony wrote: > Subject: Re: Scene Density Requirements > > The machine is an RE2 with 2RM4s. The application runs in a 1024x768 screen. > From all calculations I've seen so far, the test scene I'm trying to render > should go at 30Hz; yet it has a draw time of 33.1ms, and runs no faster than > 20Hz. (Statistics from perfly or vega application.) > > The scene consists of strips of tris, overlapped so that none are completely > obscured, sometimes up to six deep. The scene was created with MultiGen, > and I arranged the objects so that they are sorted back-to-front, since they > all have the same Z. The strips are meshed for their entire length. In > short, it looks something like this: > > +----------------+ > | +----------------+ > | | +----------------+ > + | | | > + | | > +----------------+ > > The strips are placed at a distance from the observer such that one database > unit is one pixel. The strips constitute the following numbers and sizes of > triangles: > 150 tris, 101x101 > 1350 tris, 51x51 > 1500 tris, 10x10 > > None of the above is negotiable; it's all set out in the test document. > > Our average depth complexity for the scene is somewhere between 3.31 and > 3.33. (Perfly/Vega statistics again.) > > The rated pixel fill rate for 2 RM4s is 110Mpix/sec. Our scene contains: > 150 x 101 x 101 / 2 = 765,075 > + 1350 x 51 x 51 / 2 = 1,755,675 > + 1500 x 10 x 10 / 2 = 75,000 > -------------------------------- > 2,595,750 pixels. > At 30Hz, that makes 2,595,750 * 30 = 77,872,500pix/sec, which is below the > rated fill rate, so shouldn't be causing a problem. Jude, I've written a small GL benchmark (not using Performer), for testing your scene. It allows you to set some options and see how they affect graphics. >From what I see on a 2RM RE, you should be OK if you are using 16 bit textures. You can either include the clear time in your measurements or not. Including the clear, I get about 25 milisec, when using 16 bit textures. Using this program you can see how to tune your Performer app, in terms of graphics states. I've written the program in haste, so I must appologize for the unfriendly interface. you run the program as follows : ./fill options texture_name options : -z : turns zbuffer on -m : turns multisampling on -t : draws textured geometry -l : uses display lists (less CPU work) -c : includes the clear in measurements -b : enables backface culling -f : enables flat shading -5 : defines 16 bit texture The defaults are : zbuffer off multisampling off texture off immediate mode (no display lists) no clear no backface culling gouraud shading 32 bit texture Good luck Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | RT-SET Ltd. / )_ (_(_) ) \/ (_(_/<_(_)( | _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@rtset.co.il Work : 972-9-9552236 | rany@netvision.net.il Res. : 972-9-7489974 | Fax : 972-9-9552239 | --PART-BOUNDARY=.19701151950.ZM10811.amit X-Zm-Content-Name: fill.c Content-Description: Text Content-Type: text/plain ; name="fill.c" ; charset=us-ascii /********************************************************************** * Compile with : * cc fill.c -o fill -limage -lGLU -lGL -lX11 ********************************************************************/ #include #include #include #include #include #include #include #include #include #include Display *xdisp; Window win; int done = 0; float azimuth = 0, elevation = 0, distance = 100.0; char *tex_name = NULL; int tex = 1; int is_dlist = 0, is_zbuffer = 0; int is_texture = 0, is_multisample = 0; int is_clear = 0, is_cullface = 0, is_flat = 0; int is_rgb5 = 0; double total_time = 0.0; int count = 0; uint tex_geom, geom; /*** WM hints for noborder GLX windows ***/ /* ** The following structure is actually defined in MOTIF's Xm/MwmUtils.h, but ** we don't want to require header file. */ typedef struct MWMHints { long flags; long functions; long decorations; long input_mode; } MWMHints; #define MWM_HINTS_FUNCTIONS 1 #define MWM_HINTS_DECORATIONS 2 #define MWM_HINTS_INPUT_MODE 4 static Atom mwm_hints_atom = 0; static void getMWMHints(Display *dsp, Window w, MWMHints *pHints) { MWMHints *hp; int type, fmt; unsigned long nitems, bytes_after; /* get special atom for 4DWM motif window manager */ if (!mwm_hints_atom) mwm_hints_atom = XInternAtom(dsp, "_MOTIF_WM_HINTS", 0); XGetWindowProperty(dsp, w, mwm_hints_atom, 0, 4, False, mwm_hints_atom, (unsigned long *)&type, &fmt, &nitems, &bytes_after, (unsigned char**)&hp); if (hp) { *pHints = *hp; XFree((void *)hp); } else bzero(pHints, sizeof *pHints); } static void noXWindowDecoration(Display *dsp, Window w) { MWMHints hints; /* get special atom for 4DWM motif window manager */ if (!mwm_hints_atom) mwm_hints_atom = XInternAtom(dsp, "_MOTIF_WM_HINTS", 0); getMWMHints(dsp, w, &hints); hints.decorations = 0x0; hints.flags |= MWM_HINTS_DECORATIONS; XChangeProperty(dsp, w, mwm_hints_atom, mwm_hints_atom, 32, PropModeReplace, (unsigned char *)&hints, 4); } open_window (char *name, int visual_id) { int nred, ngreen, nblue, nalpha, nsamples, ndepth; int vinfo_ms[] = { GLX_RGBA, GLX_DOUBLEBUFFER, GLX_RED_SIZE, 1, GLX_GREEN_SIZE, 1, GLX_BLUE_SIZE, 1, GLX_ALPHA_SIZE, 0, GLX_SAMPLES_SGIS, 8, GLX_DEPTH_SIZE, 1, None }; int vinfo_noms[] = { GLX_RGBA, GLX_DOUBLEBUFFER, GLX_RED_SIZE, 1, GLX_GREEN_SIZE, 1, GLX_BLUE_SIZE, 1, GLX_ALPHA_SIZE, 0, GLX_DEPTH_SIZE, 1, None }; XVisualInfo vtemplate; XVisualInfo *v; GLXContext c; XSetWindowAttributes wa; Colormap cmap; XEvent event; float j; int fmt; int n; unsigned long nitems, byaf; XSizeHints sh; struct hints_struct { long flags,functions,decorations,input_mode; } *hints; Atom type, mwmhints; int multibuffer; xdisp = XOpenDisplay (0); if (visual_id < 0) { v = glXChooseVisual(xdisp, DefaultScreen(xdisp), vinfo_ms); if (v == 0) v = glXChooseVisual(xdisp, DefaultScreen(xdisp), vinfo_noms); if (v == 0) { fprintf(stderr, "glXChooseVisual failed\n"); exit(8); } } else { vtemplate.visualid = visual_id; vtemplate.screen = DefaultScreen(xdisp); v = XGetVisualInfo (xdisp, VisualIDMask | VisualScreenMask, &vtemplate, &n); if (n == 0) { fprintf(stderr, "XGetVisualInfo failed on VisualID %d\n", visual_id); exit (8); } } if ((c = glXCreateContext(xdisp, v, 0, GL_TRUE)) == 0) { fprintf(stderr, "glXCreateContext failed\n"); exit(3); } wa.colormap = XCreateColormap (xdisp, RootWindow(xdisp,v->screen), v->visual, AllocNone); wa.border_pixel = 0; wa.event_mask = StructureNotifyMask | KeyPressMask | ButtonReleaseMask | KeyReleaseMask | ButtonPressMask; win = XCreateWindow(xdisp, RootWindow(xdisp, v->screen), 0, 0, 1280, 1024, 0, v->depth, InputOutput, v->visual, CWBorderPixel|CWEventMask|CWColormap, &wa); noXWindowDecoration (xdisp, win); sh.flags = USPosition | USSize; XmbSetWMProperties(xdisp, win, &name[0],0,0,0,&sh, 0, 0); XMapWindow(xdisp, win); if(! glXMakeCurrent(xdisp, win, c)) { printf ("error: gfxMakeCurrent failed\n"); exit(1); } glMatrixMode(GL_PROJECTION); glLoadIdentity(); glMatrixMode(GL_MODELVIEW); glLoadIdentity(); XFlush (xdisp); glGetIntegerv (GL_RED_BITS, &nred); glGetIntegerv (GL_GREEN_BITS, &ngreen); glGetIntegerv (GL_BLUE_BITS, &nblue); glGetIntegerv (GL_ALPHA_BITS, &nalpha); glGetIntegerv (GL_SAMPLES_SGIS, &nsamples); glGetIntegerv (GL_DEPTH_BITS, &ndepth); printf ("rgba size : %d %d %d %d\n", nred, ngreen, nblue, nalpha); printf ("samples : %d\n", nsamples); printf ("depth : %d\n", ndepth); return win; } main (int argc, char *argv[]) { char *sw; int visual_id = -1; int i; double frame_time; while (*++argv) { if (**argv == '-') { sw = *argv; while (*++sw) { switch (*sw) { case 'v' : argv ++; if (strncmp (*argv, "0x", 2) == 0) sscanf (*argv, "%x", &visual_id); else sscanf (*argv, "%d", &visual_id); break; case 'z' : is_zbuffer = 1; break; case 'm' : is_multisample = 1; break; case 't' : is_texture = 1; break; case 'l' : is_dlist = 1; break; case 'c' : is_clear = 1; break; case 'b' : is_cullface = 1; break; case 'f' : is_flat = 1; break; case '5' : is_rgb5 = 1; break; } } } else { if (!tex_name) tex_name = strdup (*argv); } } open_window ("fill rate", visual_id); make_textures(); make_lists(); for (i = 0; i < 1000; i ++) { redraw(); glXSwapBuffers (xdisp, win); glFlush(); } frame_time = total_time / (double) count; printf ("texture : %s\n", is_texture ? "on" : "off"); printf ("multisample : %s\n", is_multisample ? "on" : "off"); printf ("display lists : %s\n", is_dlist ? "on" : "off"); printf ("zbuffer : %s\n", is_zbuffer ? "on" : "off"); printf ("clear : %s\n", is_clear ? "on" : "off"); printf ("flat shading : %s\n", is_flat ? "on" : "off"); printf ("backface culling : %s\n", is_cullface ? "on" : "off"); printf ("16 bit texture : %s\n", is_rgb5 ? "on" : "off"); printf ("frame time : %.3f milisec\n", (float) frame_time); printf ("fill rate : %.3f Mpixels/sec\n", 2595750.0 / frame_time * 1000.0 / 1024.0 / 1024.0); } static void read_image (char *name, unsigned int **image, int *xsize, int *ysize) { IMAGE *image_fp; int x, y; unsigned short *rbuf, *gbuf, *bbuf, *abuf; unsigned char *cp; int i, size; if ((image_fp = iopen (name, "r")) == NULL) { perror (name); exit (1); } *xsize = image_fp->xsize; *ysize = image_fp->ysize; rbuf = malloc (image_fp->xsize * sizeof (short)); gbuf = malloc (image_fp->xsize * sizeof (short)); bbuf = malloc (image_fp->xsize * sizeof (short)); abuf = malloc (image_fp->xsize * sizeof (short)); size = image_fp->xsize * image_fp->ysize * sizeof (int); *image = malloc (size); cp = *image; for (y = 0; y < image_fp->ysize; y ++) { getrow (image_fp, rbuf, y, 0); getrow (image_fp, gbuf, y, 1); getrow (image_fp, bbuf, y, 2); for (x = 0; x < image_fp->xsize; x ++) { *cp ++ = rbuf[x]; *cp ++ = gbuf[x]; *cp ++ = bbuf[x]; *cp ++ = 0xff; } } } make_textures() { unsigned int *image, *p; int xsize, ysize; int i, j; glEnable (GL_TEXTURE_2D); glBindTextureEXT (GL_TEXTURE_2D, tex); if (tex_name) read_image (tex_name, &image, &xsize, &ysize); else { xsize = 128; ysize = 128; p = image = malloc (xsize * ysize * sizeof (int)); for (i = 0; i Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA25133; Wed, 15 Jan 1997 10:55:24 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA19450; Wed, 15 Jan 1997 10:56:33 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24237; Wed, 15 Jan 1997 10:54:58 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA10255; Wed, 15 Jan 1997 18:54:35 GMT From: "Angus Dorbie" Message-Id: <9701151854.ZM10253@bitch.reading.sgi.com> Date: Wed, 15 Jan 1997 18:54:35 +0000 In-Reply-To: Timothy Moore "Re: Scene Density Requirements" (Jan 15, 10:22am) References: <199701151822.KAA22052@gonzo.wolfenet.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Timothy Moore Subject: Re: Scene Density Requirements Cc: jude@p3.enzian.com, info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 15, 10:22am, Timothy Moore wrote: > Subject: Re: Scene Density Requirements > From: "Angus Dorbie" > Date: Wed, 15 Jan 1997 17:17:27 +0000 > References: <137F0E13C1B@P3.ENZIAN.COM> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > > On Jan 15, 8:59am, Jude Anthony wrote: > > > > Question 1: Am I missing some important calculation here? > > > > From this calculation, this app should run 30Hz without even breathing > > hard. I must be missing something. Maybe I need to add the screen clearing > > and Z-buffer clearing pixels in here? > > You should certainly factor in the time taken to clear the screen. > I've seen 1ms measured for 1280x1024 on iR. > > It's quite a bit more than that on an RE2 (the machine in question), > no? I recall a number of 12ms for a screen and Z-buffer clear, though > this can be overlapped with other graphics operations. > Ahh, I assumed the question was iR. RE2 is different. > The pfEskyMode may be an important factor in this test. If you can > use PFES_SKY_GND or PFES_SKY instead of PFES_SKY_CLEAR you'll get > better performance (but I don't know how that translates into Vega). You won't get better performance on iR, it doesn't support the TAG clear which RE2 does so by drawing the sky or ground you add graphics load on iR. > > > > Question 2: Is there any way to increase the speed of this app to 30Hz? > > > > I found that by eliminating multisampling, turning off the Z-buffer > > altogether, or not clearing the Z-buffer, I can increase the iteration rate. > > Unfortunately, I'm not allowed to change those things, since the test app > > conditions are supposed to match the simulation conditions. > > I also find that moving the observer back just a little speeds things up. > > Have you display listed the geometry which you draw? > > Seems like that would reduce this usefulness of this test as a > simulation benchmark. > Well I had assumed this was iR so it's was very significant, and it's realistic for real applications to display list the database for two reasons 1) on iR you have a huge <16Mb display list on the GE board. This goes a long way in a vis sim database, it's also good for storing reusable objects like a vehicle, and rendering something like a vehicle is probably your worst case graphics host limit in Vis Sim scenario and potentially where display lists could buy you back some fill. 2) display lists when not on the graphics board are held optimised on the host and may draw faster. The iR can also DMA the display list from the host so for reasonably sized lists it's a win, especially if you have R4400 processors. In anycase this test is clearly trying to isolate and measure pixel fill, the way to this is to eliminate other factors. If you want a simulation benchmark you should run a simulation. > color and Z buffers if the depth test succeeds. So, you may get a > measurably better fill rate if you render polygons front to back, I very much doubt this would be worthwhile on RE2 or iR systems unless you manage to occlude some transparency, but anything is worth a try I suppose. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 11:01:27 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA25172; Wed, 15 Jan 1997 10:57:22 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA25156; Wed, 15 Jan 1997 10:57:20 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA22845; Wed, 15 Jan 1997 10:56:58 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA16459; Wed, 15 Jan 1997 10:56:51 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701151856.KAA16459@remi.asd.sgi.com> Subject: Re: NOT synchronizing to vertical retrace To: orad_u@netvision.net.il (Orad Hi-Tec Systems) Date: Wed, 15 Jan 1997 10:56:51 -0800 (PST) Cc: info-performer@remi.asd.sgi.com In-Reply-To: <32DD070D.41C6@netvision.net.il> from "Orad Hi-Tec Systems" at Jan 15, 97 06:34:21 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1848 Status: O Orad Hi-Tec Systems wrote: > > Angus Dorbie wrote: > > > > On Jan 14, 9:32pm, Orad Hi-Tec Systems wrote: > > > Subject: NOT synchronizing to vertical retrace > > > I want to synchronize my Performer app to an event different > > > from a vertical retrace of the framebuffer (i.e., NOT to > > > glXSwapBuffers(), glXWaitVideoSyncSGI(), etc.). If I refrain > > > from calling pfSync() directly, it gets called internally by > > > pfFrame(). > > > How can I do this? > > > For simplicity, lets assume that we are running single-process. > > > > > > > The video rate is king. Even if you lock the app to a different rate > > you'll still experience problems because your draw will still render > > to a multiple of the video. You either have to genlock the video to > > bring the I.G. into line or use the vertical sync to lock your i/o. > > > > You could also try resampling the data to match your video rate and > > don't bother with the lock. Usually this is less than an optimal > > solution. > > > > Cheers, > > Angus. > > > The video rate is king only if I am rendering into the framebuffer. > (And even then, only if the drawable is double-buffered and I am trying > to swap the buffers). > But here I am rendering to an off-screen PBuffer! > (which of course doesn't need "swapbuffers") Did you try to use a separate pfPipeWindow and set the pfPipe::setSwapFunc() function ? > > Moshe Nissim > Orad Hi-Tec Systems > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 15 15:04:35 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA26871; Wed, 15 Jan 1997 15:01:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA26855; Wed, 15 Jan 1997 15:01:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA22447; Wed, 15 Jan 1997 15:01:06 -0800 Received: from wolfe.net (mail1.wolfe.net [204.157.98.11]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA01247; Wed, 15 Jan 1997 15:01:04 -0800 Received: from gonzo.wolfenet.com (moore@gonzo.wolfenet.com [204.157.98.2]) by wolfe.net (8.8.0/8.8.0) with ESMTP id PAA05920; Wed, 15 Jan 1997 15:02:30 -0800 (PST) From: Timothy Moore Received: (from moore@localhost) by gonzo.wolfenet.com (8.8.3/8.7) id PAA15394; Wed, 15 Jan 1997 15:00:51 -0800 (PST) Date: Wed, 15 Jan 1997 15:00:51 -0800 (PST) Message-Id: <199701152300.PAA15394@gonzo.wolfenet.com> To: dorbie@bitch.reading.sgi.com CC: jude@p3.enzian.com, info-performer@sgi.com In-reply-to: "Angus Dorbie"'s message of Wed, 15 Jan 1997 18:54:35 +0000 <9701151854.ZM10253@bitch.reading.sgi.com> Subject: Re: Scene Density Requirements Status: O From: "Angus Dorbie" Date: Wed, 15 Jan 1997 18:54:35 +0000 On Jan 15, 10:22am, Timothy Moore wrote: > The pfEskyMode may be an important factor in this test. If you can > use PFES_SKY_GND or PFES_SKY instead of PFES_SKY_CLEAR you'll get > better performance (but I don't know how that translates into Vega). You won't get better performance on iR, it doesn't support the TAG clear which RE2 does so by drawing the sky or ground you add graphics load on iR. If the simulation requires sky and ground, though, it would seem that they need to be included in the pixel fill benchmark. > Have you display listed the geometry which you draw? > > Seems like that would reduce this usefulness of this test as a > simulation benchmark. > Well I had assumed this was iR so it's was very significant, and it's realistic for real applications to display list the database for two reasons 1) on iR you have a huge <16Mb display list on the GE board. This goes a long way in a vis sim database, it's also good for storing reusable objects like a vehicle, and rendering something like a vehicle is probably your worst case graphics host limit in Vis Sim scenario and potentially where display lists could buy you back some fill. 2) display lists when not on the graphics board are held optimised on the host and may draw faster. The iR can also DMA the display list from the host so for reasonably sized lists it's a win, especially if you have R4400 processors. Interesting! What implications does using display lists have for database paging? 16Mb of geometry information is a tiny database in my neck of the woods. Is it possible to do display list compilation in the DBASE process? Seems like it would be with some shared graphics context hackery. What performance cost does display list compilation have at simulation time? Can you compile up an essentially unlimited amount of geometry into display lists and rely on OpenGL to page the list into display list cache at the appropriate time? In anycase this test is clearly trying to isolate and measure pixel fill, the way to this is to eliminate other factors. If you want a simulation benchmark you should run a simulation. Yeah, but if you can only meet your fill rate target by doing things that aren't practical in the simulation, your fill benchmark is telling that you can't meet your fill target. Seems like the SGI folks would be interested in giving Jude some other answer :-) > color and Z buffers if the depth test succeeds. So, you may get a > measurably better fill rate if you render polygons front to back, I very much doubt this would be worthwhile on RE2 or iR systems unless you manage to occlude some transparency, but anything is worth a try I suppose. Yeah. Angus, the information you provide on iR is very useful. I'll gently remind you, though, that the RE2 is still a relevant target to many on this list and its performance characteristics and quirks are germaine here. Tim ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 00:21:48 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id AAA28151; Thu, 16 Jan 1997 00:17:45 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id AAA28135; Thu, 16 Jan 1997 00:17:43 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA21485; Thu, 16 Jan 1997 00:17:32 -0800 Received: from mailsvr.mumbai.tcs.co.in ([202.54.5.70]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id AAA04343 for ; Thu, 16 Jan 1997 00:16:32 -0800 Received: from [145.17.41.63] by mailsvr.mumbai.tcs.co.in (NTMail 3.02.07) with ESMTP id va009641 for ; Thu, 16 Jan 1997 13:47:24 +0530 Received: by Behram with Microsoft Mail id <01BC03B3.212A9780@Behram>; Thu, 16 Jan 1997 13:42:35 +-5-30 Message-ID: <01BC03B3.212A9780@Behram> From: Behram To: "'info-performer@sgi.com'" Subject: RAID Problem with Irix 6.2 Date: Thu, 16 Jan 1997 13:42:33 +-5-30 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Status: O Hi Performers: We are an outfit with a 8 CPU RE2 ONYX and a 50GB RAID 3 Vault supplied = by SGI (probably from CIPRICO cannot be certain as there are no = manufacturer markings) around two years ago.=20 Our problem is that when we upgraded from 5.3 to Irix 6.2 the OS does = not seem to recognize the RAID Vault. Our local SGI support informs = that only RAID supported by SGI is that from DG-Clarion and no drivers = available for our RAID box. Can someone out there tell us if this problem is unique to us or there = are more fellow sufferers? Would appreciate any solution/help. Behram Sethna Tata Consultancy services Mumbai, India ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 02:13:09 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA28373; Thu, 16 Jan 1997 02:10:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA28357; Thu, 16 Jan 1997 02:10:24 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA25182; Thu, 16 Jan 1997 02:10:13 -0800 Received: from rainich.dcs.ed.ac.uk (rainich.dcs.ed.ac.uk [129.215.160.105]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA20339 for ; Thu, 16 Jan 1997 02:09:52 -0800 Received: from jura.dcs.ed.ac.uk by rainich.dcs.ed.ac.uk with SMTP (PP); Thu, 16 Jan 1997 10:09:30 +0000 Received: from localhost by jura.dcs.ed.ac.uk; Thu, 16 Jan 1997 10:09:19 GMT Date: Thu, 16 Jan 1997 10:09:17 +0000 (GMT) From: Martin Reddy Reply-To: Martin Reddy To: Performer List Subject: Re: Underwater effects Message-ID: Organisation: Department of Computer Science - University of Edinburgh MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O You may have already seen this one, but there is the Atlantis simulation which the guys at the RealityCentre did (N.B. this is different from the Atlantis demo that comes with the graphics demos bundle on most machines). They used effects such a fogging into a blue background to give a nice murky effect, detail textures for shimmering reflection effects on objects, shoals of fish, etc. You can pick up the binary and source code (pf1.2 I think) from: ftp://sgigate.sgi.com/pub/Performer/RealityCentre/atlantis.tar.Z Martin. +============================================================================+ | Martin Reddy Dept. of Computer Science | | University of Edinburgh | | e-mail : M.Reddy@ed.ac.uk Mayfield Road, EH9 3JZ | | http://www.dcs.ed.ac.uk/~mxr/ Tel : +44 131 650 5164 | +============================================================================+ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 04:57:31 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA01028; Thu, 16 Jan 1997 04:56:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA01012; Thu, 16 Jan 1997 04:56:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA01130; Thu, 16 Jan 1997 04:56:14 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA13139; Thu, 16 Jan 1997 04:56:12 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id MAA11109; Thu, 16 Jan 1997 12:56:09 GMT From: "Angus Dorbie" Message-Id: <9701161256.ZM11107@bitch.reading.sgi.com> Date: Thu, 16 Jan 1997 12:56:09 +0000 In-Reply-To: Timothy Moore "Re: Scene Density Requirements" (Jan 15, 3:00pm) References: <199701152300.PAA15394@gonzo.wolfenet.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Timothy Moore Subject: Re: Scene Density Requirements Cc: jude@p3.enzian.com, info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 15, 3:00pm, Timothy Moore wrote: > You won't get better performance on iR, it doesn't support the TAG clear > which RE2 does so by drawing the sky or ground you add graphics load on iR. > > If the simulation requires sky and ground, though, it would seem that > they need to be included in the pixel fill benchmark. A pixel fill benchmark measures pixel fill. A rendered sky needs to be included when you count the depth complexity of the scene. My approach on RE2 with this benchmark would be to TAG clear. This would give a number I can spend on scene depth complexity (including sky) for the given shading modes (in the absence of other bottlenecks). > > Interesting! What implications does using display lists have for > database paging? 16Mb of geometry information is a tiny database in > my neck of the woods. Is it possible to do display list compilation > in the DBASE process? Seems like it would be with some shared > graphics context hackery. What performance cost does display list > compilation have at simulation time? You would have to display list in the draw process the first time you draw paged geometry and you can expect some overhead for this in the draw time which you'd have to measure. You'd only be display listing a little at a time so it's probably managable. > > Can you compile up an essentially unlimited amount of geometry into > display lists and rely on OpenGL to page the list into display list > cache at the appropriate time? On iR it'd either cache on the GE board or DMA from memory both are potential wins. You also have control over which display lists reside on the GE board and which reside in memory using display list priority control. > > In anycase this test is clearly trying to isolate and measure pixel > fill, the way to this is to eliminate other factors. > If you want a simulation benchmark you should run a simulation. > > Yeah, but if you can only meet your fill rate target by doing things > that aren't practical in the simulation, your fill benchmark is > telling that you can't meet your fill target. Seems like the SGI folks > would be interested in giving Jude some other answer :-) I don't agree that any of my suggestions were impractical in a simulation. The key point is to measure all relevant metrics and apply the numbers with a little common sense. If you introduce host or geometry limits while measuring pixel fill you won't be well informed after the exercise. That doesn't mean that when you bring your measured fill statistic to the table you ignore host, geometry or other overheads, you consider those capabilities in context. If your approach is to introduce other limits then you should measure a scene representative of your application once you've done everything practical in simulation to optimise the test. > > Angus, the information you provide on iR is very useful. I'll gently > remind you, though, that the RE2 is still a relevant target to many on > this list and its performance characteristics and quirks are germaine > here. I agree, but I'm surprised you get the impression I would think otherwise. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 08:31:02 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA01462; Thu, 16 Jan 1997 08:29:52 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA01446; Thu, 16 Jan 1997 08:29:52 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA13572; Thu, 16 Jan 1997 08:29:41 -0800 Received: from atlantic.merl.com (atlantic.merl.com [140.237.7.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA20272 for ; Thu, 16 Jan 1997 08:29:36 -0800 Received: from neptune.merl.com (neptune.merl.com [140.237.1.38]) by atlantic.merl.com (8.8.4/8.8.3) with ESMTP id LAA05363 for ; Thu, 16 Jan 1997 11:29:02 -0500 (EST) Received: from mayflower.merl.com (mayflower.merl.com [140.237.1.1]) by neptune.merl.com (8.8.4/8.8.3) with ESMTP id LAA02179 for ; Thu, 16 Jan 1997 11:29:01 -0500 (EST) Received: from barruspc.svl.meitca.com (barruspc.ca.merl.com [140.237.10.159]) by mayflower.merl.com (8.8.3/8.8.3) with SMTP id LAA14845 for ; Thu, 16 Jan 1997 11:25:25 -0500 (EST) Message-Id: <2.2.32.19970116164701.0071eae4@mail.merl.com> X-Sender: barrus@mail.merl.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jan 1997 08:47:01 -0800 To: info-performer@sgi.com From: "John W. Barrus" Subject: Clockwise/Counterclockwise triangles in tri-strips Status: O I found an interesting thing happening with geometry imported into Performer. Although technically, it isn't a bug, there might be a better way of handling the data. When Performer creates tri-strips from imported polygons, it looks at the face or vertex normals to determine which direction the first triangle in the new tri-strip should be facing (instead of looking at the cross product of the first two eges of the polygon). We had a few models created in a modeler that is not very careful about making sure the normals and edge cross-products correspond ((V1-V0)X(V2-V1) * N should not be negative where N is the polygon or vertex normal, V0, V1 and V2 are vertices describing the triangle when using counter-clockwise faces.) Since our normals were accidently reversed in one part of the model, some of the faces seemed to be missing when perfly read in the model. What happened was that faces with bad normals were getting reversed when they were converted to tri-strips. Of course, using the normal is faster than calculating the cross-product of two vectors, but it would be nice if Performer provided an option to it's tri-strip builder that checked the cross-product instead of the normal at the expense of slightly slower load rate (or even a utility that checked it and pointed out potential problems). Any thoughts or suggestions? John B. Note new address and phone number: John W. Barrus Research Scientist Mitsubishi Electric Information Technology Center America 1060 Arques Avenue Sunnyvale, CA 94086 phone: (408) 523-6806 fax: (408) 524-0613 e-mail: barrus@merl.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 09:02:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA01569; Thu, 16 Jan 1997 09:01:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA01553; Thu, 16 Jan 1997 09:01:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA16185; Thu, 16 Jan 1997 09:00:56 -0800 Received: from wolfe.net (mail1.wolfe.net [204.157.98.11]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00034; Thu, 16 Jan 1997 09:00:54 -0800 Received: from gonzo.wolfenet.com (moore@gonzo.wolfenet.com [204.157.98.2]) by wolfe.net (8.8.0/8.8.0) with ESMTP id JAA07906; Thu, 16 Jan 1997 09:02:22 -0800 (PST) From: Timothy Moore Received: (from moore@localhost) by gonzo.wolfenet.com (8.8.3/8.7) id JAA24804; Thu, 16 Jan 1997 09:00:42 -0800 (PST) Date: Thu, 16 Jan 1997 09:00:42 -0800 (PST) Message-Id: <199701161700.JAA24804@gonzo.wolfenet.com> To: dorbie@bitch.reading.sgi.com CC: jude@p3.enzian.com, info-performer@sgi.com In-reply-to: "Angus Dorbie"'s message of Thu, 16 Jan 1997 12:56:09 +0000 <9701161256.ZM11107@bitch.reading.sgi.com> Subject: Re: Scene Density Requirements Status: O From: "Angus Dorbie" Date: Thu, 16 Jan 1997 12:56:09 +0000 On Jan 15, 3:00pm, Timothy Moore wrote: > > Can you compile up an essentially unlimited amount of geometry into > display lists and rely on OpenGL to page the list into display list > cache at the appropriate time? On iR it'd either cache on the GE board or DMA from memory both are potential wins. You also have control over which display lists reside on the GE board and which reside in memory using display list priority control. How about on RE2? :-) :-) :-) Tim ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 10:46:42 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA01842; Thu, 16 Jan 1997 10:45:11 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA01826; Thu, 16 Jan 1997 10:45:10 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA26086; Thu, 16 Jan 1997 10:44:59 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA29838; Thu, 16 Jan 1997 10:44:26 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA11463; Thu, 16 Jan 1997 18:43:43 GMT From: "Angus Dorbie" Message-Id: <9701161843.ZM11461@bitch.reading.sgi.com> Date: Thu, 16 Jan 1997 18:43:42 +0000 In-Reply-To: Timothy Moore "Re: Scene Density Requirements" (Jan 16, 9:00am) References: <199701161700.JAA24804@gonzo.wolfenet.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Timothy Moore Subject: Re: Scene Density Requirements Cc: jude@p3.enzian.com, info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 16, 9:00am, Timothy Moore wrote: > Subject: Re: Scene Density Requirements > From: "Angus Dorbie" > Date: Thu, 16 Jan 1997 12:56:09 +0000 > > On Jan 15, 3:00pm, Timothy Moore wrote: > > > > > Can you compile up an essentially unlimited amount of geometry into > > display lists and rely on OpenGL to page the list into display list > > cache at the appropriate time? > > On iR it'd either cache on the GE board or DMA from memory both are > potential wins. > You also have control over which display lists reside on the GE board > and which reside in memory using display list priority control. > > How about on RE2? :-) :-) :-) If you are using display lists with RE2 then the difference is more marginal unless you have a bad immediate mode drawing code in which case display lists are an easy method of optimisation. Performer has good drawing code so compiling lists on RE2 don't help much on this mailing list. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 12:37:05 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA02127; Thu, 16 Jan 1997 12:16:20 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA02111; Thu, 16 Jan 1997 12:16:19 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA05734; Thu, 16 Jan 1997 12:16:08 -0800 Received: from despair.paradigmsim.com (despair.paradigmsim.com [206.7.114.164]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA23377 for ; Thu, 16 Jan 1997 12:16:05 -0800 Received: (from angus@localhost) by despair.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01825 for info-performer@sgi.com; Thu, 16 Jan 1997 14:15:37 -0600 From: "Angus W.S. Henderson" Message-Id: <9701161415.ZM1823@despair.paradigmsim.com> Date: Thu, 16 Jan 1997 14:15:35 -0600 In-Reply-To: Martin Reddy "Re: Underwater effects" (Jan 16, 10:09am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Performer List Subject: Re: Underwater effects Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > You may have already seen this one, but there is the Atlantis simulation > which the guys at the RealityCentre did ... then go and buy Waveracer or rider whatever-it-is for your Nintendo 64 for clever/fast reflective water surfaces. ANgus ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 13:47:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA02512; Thu, 16 Jan 1997 13:45:57 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA02496; Thu, 16 Jan 1997 13:45:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA14029; Thu, 16 Jan 1997 13:45:46 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA14416 for ; Thu, 16 Jan 1997 13:45:37 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id QAA13706; Thu, 16 Jan 1997 16:45:31 -0500 (EST) Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 16 Jan 97 16:41:48 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 16 Jan 97 16:41:19 EST From: "Jude Anthony" Organization: Enzian Technology, Inc. To: info-performer@sgi.com Date: Thu, 16 Jan 1997 16:41:15 EST Subject: Re: Scene Density Requirements X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: <157A47040C9@P3.ENZIAN.COM> Status: O This has been helpful. My draw is at 33.1, with app at 0.6, and cull at 1.2. I see from the statistics that there are 20 fifowaits. I tried turning off the statistic gathering in hardware, but without noticeable results. I've also started using osview to determine the swapbuf rate. (I was hoping all these things would take me down the extra two or three milliseconds I need). Perhaps there's something I can do to the geometry to make it render faster? It's presently a .flt file, with triangles in meshed strips. The tris have no color, no texture, no material, and no transparency. The vertices have no color. The file is saved without normals. I can't use a tag background; in the actual marine simulation, the background smears around whenever I move. Any other ideas on how to speed this up? Thanks, Jude Anthony jude@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 14:24:40 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA02774; Thu, 16 Jan 1997 14:23:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA02758; Thu, 16 Jan 1997 14:23:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA17814; Thu, 16 Jan 1997 14:23:06 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA23957 for ; Thu, 16 Jan 1997 14:23:04 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA20838; Thu, 16 Jan 97 16:19:54 -0500 Date: Thu, 16 Jan 97 16:19:54 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701162119.AA20838@mred.bgm.link.com> To: info-performer@sgi.com Subject: AN interesting comment. Status: O I found this interesting comment in a document in Jim Blinn's home page out there on the web:- > A common cheat in animation is to do double framing, that > is, to only render every other frame and to record each rendered frame > twice. We all expect that single framing is preferable to double framing, > its only disadvantage is that single framing takes longer to render. > There is another effect of double framing however. A motion that is > double framed seems to move faster than one that is single framed, > even if they take an identical amount of wall-clock time to take place. > Double framing is therefore sometimes used by conventional animators > to add liveliness to scene. This seems very suprising - if it's true then it would appear to have rather severe implications for simulations running at 30Hz. If time somehow seems distorted in this way then vehicle operators (pilots especially) might get false speed cues with 30Hz simulations! Has anyone else out there heard this? Are there studies to show any kind of effect like that? Mr Blinn is presumably too busy to answer his email - I didn't get a reply when I asked him for backup info. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 14:53:46 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA02970; Thu, 16 Jan 1997 14:52:24 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA02954; Thu, 16 Jan 1997 14:52:23 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA21114; Thu, 16 Jan 1997 14:52:13 -0800 Received: from zippo.paradigmsim.com (impact.paradigmsim.com [206.7.114.202]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01932 for ; Thu, 16 Jan 1997 14:52:10 -0800 Received: from zippo.paradigmsim.com (localhost [127.0.0.1]) by zippo.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA04346; Thu, 16 Jan 1997 16:51:36 -0600 Sender: mew@paradigmsim.com Message-ID: <32DEB0F7.2781@paradigmsim.com> Date: Thu, 16 Jan 1997 16:51:35 -0600 From: Mike Weiblen Organization: Paradigm Simulation, Inc. X-Mailer: Mozilla 3.0 (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Steve Baker CC: info-performer@sgi.com Subject: Re: AN interesting comment. References: <9701162119.AA20838@mred.bgm.link.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O The double framing would seem to invite temporal aliasing, which is perhaps perceived as a motion blur?? -- mew Steve Baker wrote: > > I found this interesting comment in a document in Jim Blinn's home page > out there on the web:- > > > A common cheat in animation is to do double framing, that > > is, to only render every other frame and to record each rendered frame > > twice. We all expect that single framing is preferable to double framing, > > its only disadvantage is that single framing takes longer to render. > > There is another effect of double framing however. A motion that is > > double framed seems to move faster than one that is single framed, > > even if they take an identical amount of wall-clock time to take place. > > Double framing is therefore sometimes used by conventional animators > > to add liveliness to scene. > > This seems very suprising - if it's true then it would appear to have > rather severe implications for simulations running at 30Hz. If time > somehow seems distorted in this way then vehicle operators (pilots > especially) might get false speed cues with 30Hz simulations! > > Has anyone else out there heard this? Are there studies to show any > kind of effect like that? > > Mr Blinn is presumably too busy to answer his email - I didn't get a > reply when I asked him for backup info. > > Steve Baker 817-619-1361 (Vox-Lab) > Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) > 2200 Arlington Downs Road 817-619-4028 (Fax) > Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) > http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) > http://web2.airmail.net/sjbaker1 (external) > > "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. -- Mike Weiblen talkto:972-960-2301 x292 PARADIGM Simulation, Inc. faxto:972-960-2303 14900 Landmark, Suite 400 mailto:mew@paradigmsim.com Dallas TX 75240 http://www.paradigmsim.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 15:45:37 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA03451; Thu, 16 Jan 1997 15:44:13 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA03435; Thu, 16 Jan 1997 15:44:12 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA25830; Thu, 16 Jan 1997 15:44:01 -0800 Received: from amelnx.advmar.com (amelnx.advmar.com [152.136.205.23]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA14056 for ; Thu, 16 Jan 1997 15:43:58 -0800 From: Hill_Brian@amelnx.advmar.com Received: from cc:Mail by amelnx.advmar.com id AA853469125; Thu, 16 Jan 97 18:25:42 EST Date: Thu, 16 Jan 97 18:25:42 EST Encoding: 30 Text Message-Id: <9700168534.AA853469125@amelnx.advmar.com> To: info-performer@sgi.com, "Angus W.S. Henderson" Subject: Re[2]: Underwater effects Status: O ANgus (Neptune), Thanks for the info. I was also hoping there was some report or code that I could get to learn how they create the effect. By the way was your Atlantis ever converted to OGL/pf2.x? Brian Hill hill_brian@advmar.com ______________________________ Reply Separator _________________________________ Subject: Re: Underwater effects Author: "Angus W.S. Henderson" at Internet Date: 1/16/97 03:46 PM > You may have already seen this one, but there is the Atlantis simulation > which the guys at the RealityCentre did ... then go and buy Waveracer or rider whatever-it-is for your Nintendo 64 for clever/fast reflective water surfaces. ANgus ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 15:54:47 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA03517; Thu, 16 Jan 1997 15:53:48 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA03501; Thu, 16 Jan 1997 15:53:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA26879; Thu, 16 Jan 1997 15:53:36 -0800 Received: from od.sri.com (od.sri.com [128.18.53.220]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA16438 for ; Thu, 16 Jan 1997 15:53:31 -0800 Received: by od.sri.com (940816.SGI.8.6.9/940406.SGI) id PAA21040; Thu, 16 Jan 1997 15:53:07 -0800 From: "Nathaniel Bletter" Message-Id: <9701161553.ZM21038@od.sri.com> Date: Thu, 16 Jan 1997 15:53:06 -0800 In-Reply-To: Mike Weiblen "Re: AN interesting comment." (Jan 16, 4:51pm) References: <9701162119.AA20838@mred.bgm.link.com> <32DEB0F7.2781@paradigmsim.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Mike Weiblen , Steve Baker Subject: Re: AN interesting comment. Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O In studies we've done with simple images, double or triple framing causes multiple images of the moving object to appear as your eye is moving at a constant rate but the object is flashing twice in one spot, then twice in the next spot. You will get (refresh rate)/(update rate) images of the object, so for a 15 Hz update on a 60 Hz screen, you'll get 4 images. These images can be very close together and low contrast so they're not always visible, but it is a real effect we have observed. On Jan 16, 4:51pm, Mike Weiblen wrote: > Subject: Re: AN interesting comment. > The double framing would seem to invite temporal aliasing, > which is perhaps perceived as a motion blur?? > > -- mew > > > Steve Baker wrote: > > > > I found this interesting comment in a document in Jim Blinn's home page > > out there on the web:- > > > > > A common cheat in animation is to do double framing, that > > > is, to only render every other frame and to record each rendered frame > > > twice. We all expect that single framing is preferable to double framing, > > > its only disadvantage is that single framing takes longer to render. > > > There is another effect of double framing however. A motion that is > > > double framed seems to move faster than one that is single framed, > > > even if they take an identical amount of wall-clock time to take place. > > > Double framing is therefore sometimes used by conventional animators > > > to add liveliness to scene. > > > > This seems very suprising - if it's true then it would appear to have > > rather severe implications for simulations running at 30Hz. If time > > somehow seems distorted in this way then vehicle operators (pilots > > especially) might get false speed cues with 30Hz simulations! > > > > Has anyone else out there heard this? Are there studies to show any > > kind of effect like that? > > > > Mr Blinn is presumably too busy to answer his email - I didn't get a > > reply when I asked him for backup info. > > > > Steve Baker 817-619-1361 (Vox-Lab) > > Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) > > 2200 Arlington Downs Road 817-619-4028 (Fax) > > Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) > > http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) > > http://web2.airmail.net/sjbaker1 (external) > > > > "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. > > -- > Mike Weiblen talkto:972-960-2301 x292 > PARADIGM Simulation, Inc. faxto:972-960-2303 > 14900 Landmark, Suite 400 mailto:mew@paradigmsim.com > Dallas TX 75240 http://www.paradigmsim.com > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Mike Weiblen -- Nat Bletter SRI International nat@od.sri.com http://os.sri.com/people/nat/ (415) 859-4358 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 16:34:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id QAA03787; Thu, 16 Jan 1997 16:33:00 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA03771; Thu, 16 Jan 1997 16:33:00 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id QAA00438; Thu, 16 Jan 1997 16:32:49 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA25009 for ; Thu, 16 Jan 1997 16:32:48 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id TAA15633; Thu, 16 Jan 1997 19:32:43 -0500 (EST) Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 16 Jan 97 19:29:01 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 16 Jan 97 19:28:45 EST From: "Jude Anthony" Organization: Enzian Technology, Inc. To: info-performer@sgi.com Date: Thu, 16 Jan 1997 19:28:44 EST Subject: Re: AN interesting comment. X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: <15A6EE323AF@P3.ENZIAN.COM> Status: O Don't worry. > I found this interesting comment in a document in Jim Blinn's home page > out there on the web:- [bogus double buffering explanation scrubbed] > This seems very suprising - if it's true then it would appear to have > rather severe implications for simulations running at 30Hz. If time > somehow seems distorted in this way then vehicle operators (pilots > especially) might get false speed cues with 30Hz simulations! > > Has anyone else out there heard this? Are there studies to show any > kind of effect like that? Mr. Blinn is incorrect. Double bufferring is the process of drawing to an off-screen buffer while a different buffer is displayed. The whole thing still goes fine at 30Hz, showing 30 frames every second. It's done to prevent flickering; if you're drawing on a screen you're still showing, the viewer could see pieces of what you're doing. For completeness, consider two buffers, each with identical characteristics, buffer1 and buffer2. Draw a scene a buffer1. Display buffer1. Change the scene slightly, and draw it on buffer2 (which is not being displayed). Display buffer2. Change the scene again, and draw it on buffer1 (which is not being displayed). Display buffer1. Ad infinitum; you're double bufferring. 30 potentially different, completely redrawn frames every second. Mr. Blinn's explanation is perhaps more along the lines of an animation technique used for hand-drawn animation. To save animator time in many movies and TV shows, some frames are displayed twice. You can get away with some of that without the avaerage man seeing the slowdown. It's also used when converting movies to TV; since TV is 30Hz, and movies 24Hz, one of every four frames is displayed twice. > Mr Blinn is presumably too busy to answer his email - I didn't get a > reply when I asked him for backup info. No wonder. Later, Jude Anthony jude@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 16:41:35 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id QAA03847; Thu, 16 Jan 1997 16:40:33 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA03831; Thu, 16 Jan 1997 16:40:32 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id QAA00969; Thu, 16 Jan 1997 16:40:21 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA26558 for ; Thu, 16 Jan 1997 16:40:19 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id TAA16335; Thu, 16 Jan 1997 19:40:14 -0500 (EST) Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 16 Jan 97 19:36:29 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 16 Jan 97 19:36:10 EST From: "Jude Anthony" Organization: Enzian Technology, Inc. To: info-performer@sgi.com Date: Thu, 16 Jan 1997 19:36:02 EST Subject: Re: AN interesting comment. X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: <15A8E8716BD@P3.ENZIAN.COM> Status: O Oooops. Ever wish you could cancel your mail? I do, right now. I read Mr. Blinn's stuff and saw "double buffer" instead of "double frame." I apologize to everyone. Sorry, Jude Anthony jude@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 16:57:14 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id QAA04015; Thu, 16 Jan 1997 16:55:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA03999; Thu, 16 Jan 1997 16:55:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id QAA02227; Thu, 16 Jan 1997 16:55:43 -0800 Received: from nvg.aircrew.asu.edu (nvg.aircrew.asu.edu [198.60.190.110]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA29966 for ; Thu, 16 Jan 1997 16:55:40 -0800 Received: (from craig@localhost) by nvg.aircrew.asu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA02215 for info-performer@sgi.com; Thu, 16 Jan 1997 17:58:56 -0700 From: "Craig A. Vrana" Message-Id: <9701161758.ZM2213@nvg.aircrew.asu.edu> Date: Thu, 16 Jan 1997 17:58:56 -0700 In-Reply-To: "Nathaniel Bletter" "Re: AN interesting comment." (Jan 16, 3:53pm) References: <9701162119.AA20838@mred.bgm.link.com> <32DEB0F7.2781@paradigmsim.com> <9701161553.ZM21038@od.sri.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Re: AN interesting comment. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 16, 3:53pm, Nathaniel Bletter wrote: > Subject: Re: AN interesting comment. > In studies we've done with simple images, double or triple framing causes > multiple images of the moving object to appear as your eye is moving at a > constant rate but the object is flashing twice in one spot, then twice in the > next spot. You will get (refresh rate)/(update rate) images of the object, so > for a 15 Hz update on a 60 Hz screen, you'll get 4 images. These images can be > very close together and low contrast so they're not always visible, but it is > a real effect we have observed. > > -- > > Nat Bletter > SRI International > nat@od.sri.com > http://os.sri.com/people/nat/ > (415) 859-4358 > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Nathaniel Bletter I beleive an Air Force TR was written about this effect by Dr. Julie Lindholm last year. I'll post the reference tomorrow. -- Craig A. Vrana Project Engineer Night Vision Device Simulation craig@nvg.aircrew.asu.edu Hughes Training, Inc. - Armstrong Laboratory 6001 S. Power Rd., Building 560 Mesa, Arizona 85206 Tel: 602-988-9773 x-410 DSN: 474-6410 Fax: 602-988-3556 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 16 17:18:35 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA04318; Thu, 16 Jan 1997 17:17:01 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA04298; Thu, 16 Jan 1997 17:17:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA04019; Thu, 16 Jan 1997 17:16:50 -0800 Received: from s1000e.cs.tsinghua.edu.cn (s1000e.cs.tsinghua.edu.cn [166.111.89.241]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04747; Thu, 16 Jan 1997 17:16:44 -0800 Received: (from yl@localhost) by s1000e.cs.tsinghua.edu.cn (8.6.11/8.6.9) id JAA00552; Fri, 17 Jan 1997 09:27:03 +0800 Date: Fri, 17 Jan 1997 09:27:02 +0800 (HKT) From: Yang Lei To: info-performer-request@sgi.com cc: info-performer@sgi.com Subject: unscribe yang lei In-Reply-To: <9701131529.AA00483@cos2.4s205.corys> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 00:46:51 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id AAA05618; Fri, 17 Jan 1997 00:45:44 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id AAA05602; Fri, 17 Jan 1997 00:45:44 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA23447; Fri, 17 Jan 1997 00:45:33 -0800 Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA10179 for ; Fri, 17 Jan 1997 00:43:23 -0800 Received: from mailer1.mpib-tuebingen.mpg.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <14.FA299F84@listserv.gmd.de>; Fri, 17 Jan 1997 8:29:10 +0100 Received: from spinach.mpik-tueb.mpg.de by mailer1.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0912AM) id AA02330; Fri, 17 Jan 1997 08:29:09 +0100 Received: from [192.124.28.138] by mpik-tueb.mpg.de via SMTP (940816.SGI.8.6.9/940406.SGI) for id IAA26062; Fri, 17 Jan 1997 08:28:13 +0100 X-Sender: chris@spinach.mpik-tueb.mpg.de Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Jan 1997 08:29:17 +0200 To: info-performer@sgi.com From: chris@mpik-tueb.mpg.de (chris@mpik-tueb.mpg.de) Subject: Edge-detection on results of pfDraw Status: O Does anyone have experience of carrying out simple image processing on the results of pfDraw. In particular i'd like to perform thresholding, convolution and edge detection on what's being sent to the framebuffer by a given channel. Thanks Chris ______________________________________________________________________ Chris Christou Tel.: +49 (0)7071 601-631 Max-Planck Intitute for Fax.: +49 (0)7071 601-616 Biological Cybernetics E-mail.: chris@mpik-tueb.mpg.de Spemannstr. 38 URL. http://www.mpik-tueb.mpg.de 72076 Tuebingen Germany ______________________________________________________________________ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 00:56:06 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id AAA05680; Fri, 17 Jan 1997 00:55:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id AAA05664; Fri, 17 Jan 1997 00:55:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA23630; Fri, 17 Jan 1997 00:55:04 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA11509; Fri, 17 Jan 1997 00:55:02 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id IAA12030; Fri, 17 Jan 1997 08:55:00 GMT From: "Angus Dorbie" Message-Id: <9701170855.ZM12028@bitch.reading.sgi.com> Date: Fri, 17 Jan 1997 08:55:00 +0000 In-Reply-To: "Jude Anthony" "Re: Scene Density Requirements" (Jan 16, 4:41pm) References: <157A47040C9@P3.ENZIAN.COM> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Jude Anthony" , info-performer@sgi.com Subject: Re: Scene Density Requirements Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 16, 4:41pm, Jude Anthony wrote: > Subject: Re: Scene Density Requirements > I can't use a tag background; in the actual marine simulation, the background > smears around whenever I move. Well the idea using TAG clear is that you intend to write every pixel on the screen each frame. So you should be drawing a box or something for your water environment. It can be faster if clear isn't a sexy enough background for you and you want to draw an environment anyway or if you are inside an interior or something. If your drawing a water surface and/or sea bed anyway then you should try the TAG clear because it may be faster depending on coverage. This is the sort of setup you'd need for TAG clear. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--sea surface | | | | <--surrounding background wall | (> pfChannel pos | | | | | | | _____________________________________ <--sea bed Happy swimming, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 01:02:14 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA05718; Fri, 17 Jan 1997 01:01:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA05702; Fri, 17 Jan 1997 01:01:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA23827; Fri, 17 Jan 1997 01:00:55 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA12171; Fri, 17 Jan 1997 01:00:52 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA12039; Fri, 17 Jan 1997 09:00:48 GMT From: "Angus Dorbie" Message-Id: <9701170900.ZM12037@bitch.reading.sgi.com> Date: Fri, 17 Jan 1997 09:00:48 +0000 In-Reply-To: steve@mred.bgm.link.com (Steve Baker) "AN interesting comment." (Jan 16, 4:19pm) References: <9701162119.AA20838@mred.bgm.link.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: steve@mred.bgm.link.com (Steve Baker), info-performer@sgi.com Subject: Re: AN interesting comment. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 16, 4:19pm, Steve Baker wrote: > Subject: AN interesting comment. > > We all expect that single framing is preferable to double framing, > > its only disadvantage is that single framing takes longer to render. Jim Blinn is one of my heroes, but this statement suggests he's not really into real-time :-) Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 01:06:56 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA05746; Fri, 17 Jan 1997 01:06:01 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA05730; Fri, 17 Jan 1997 01:06:00 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA24012; Fri, 17 Jan 1997 01:05:48 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA12802; Fri, 17 Jan 1997 01:05:45 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA12043; Fri, 17 Jan 1997 09:05:42 GMT From: "Angus Dorbie" Message-Id: <9701170905.ZM12041@bitch.reading.sgi.com> Date: Fri, 17 Jan 1997 09:05:42 +0000 In-Reply-To: Mike Weiblen "Re: AN interesting comment." (Jan 16, 4:51pm) References: <9701162119.AA20838@mred.bgm.link.com> <32DEB0F7.2781@paradigmsim.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Mike Weiblen , Steve Baker Subject: Re: AN interesting comment. Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O This is a strange statement, motion blur is primarily used to avoid temporal aliasing. Cheers, Angus. On Jan 16, 4:51pm, Mike Weiblen wrote: > Subject: Re: AN interesting comment. > The double framing would seem to invite temporal aliasing, > which is perhaps perceived as a motion blur?? > > -- mew ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 01:10:54 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA05791; Fri, 17 Jan 1997 01:10:04 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA05775; Fri, 17 Jan 1997 01:10:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA24088; Fri, 17 Jan 1997 01:09:52 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA13350; Fri, 17 Jan 1997 01:09:50 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA12076; Fri, 17 Jan 1997 09:09:48 GMT From: "Angus Dorbie" Message-Id: <9701170909.ZM12074@bitch.reading.sgi.com> Date: Fri, 17 Jan 1997 09:09:48 +0000 In-Reply-To: Mike Weiblen "Re: AN interesting comment." (Jan 16, 4:51pm) References: <9701162119.AA20838@mred.bgm.link.com> <32DEB0F7.2781@paradigmsim.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Mike Weiblen , Steve Baker Subject: Re: AN interesting comment. Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 16, 4:51pm, Mike Weiblen wrote: > Subject: Re: AN interesting comment. > The double framing would seem to invite temporal aliasing, > which is perhaps perceived as a motion blur?? > Sorry for replying again but it's important to remember that the original statement didn't suggest this double framing was desirable in any way other than to make things appear livelier for some unexplained psychological reason. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 01:15:29 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA05847; Fri, 17 Jan 1997 01:14:23 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA05831; Fri, 17 Jan 1997 01:14:23 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA24192; Fri, 17 Jan 1997 01:14:12 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA13971; Fri, 17 Jan 1997 01:14:10 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA12093; Fri, 17 Jan 1997 09:14:08 GMT From: "Angus Dorbie" Message-Id: <9701170914.ZM12091@bitch.reading.sgi.com> Date: Fri, 17 Jan 1997 09:14:07 +0000 In-Reply-To: "Jude Anthony" "Re: AN interesting comment." (Jan 16, 7:28pm) References: <15A6EE323AF@P3.ENZIAN.COM> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Jude Anthony" , info-performer@sgi.com Subject: Re: AN interesting comment. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 16, 7:28pm, Jude Anthony wrote: > Subject: Re: AN interesting comment. > [bogus double buffering explanation scrubbed] Blinn wasn't talking about double buffering, he was talking about a conventional animation technique he called double framing. Which you go on to demonstrate you understand. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 04:19:08 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA06407; Fri, 17 Jan 1997 04:17:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA06391; Fri, 17 Jan 1997 04:17:46 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA29954; Fri, 17 Jan 1997 04:17:36 -0800 Received: from xr1.atlas.fr (xr1.atlas.fr [194.51.9.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA09191 for ; Fri, 17 Jan 1997 04:17:25 -0800 Message-Id: <199701171217.EAA09191@sgi.sgi.com> X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 17 Jan 1997 13:16:52 +0100 X400-Received: by mta xr1.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 17 Jan 1997 13:16:52 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; converted (ia5-text,iso (1) (0) (10021) (7) (1) (0) (1),iso (1) (0) (10021) (7) (1) (0) (6),iso (1) (0) (10021) (7) (1) (0) (100)); Relayed; Fri, 17 Jan 1997 13:16:50 +0100 X400-Received: by /PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/; Relayed; Fri, 17 Jan 1997 13:33:12 +0100 Date: Fri, 17 Jan 1997 13:33:12 +0100 X400-Originator: MICHAEL.BOCCARA@siege.aerospatiale.fr X400-Recipients: info-performer@sgi.com X400-MTS-Identifier: [/PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/;970117123312] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: CSI NC V3.0 From: BOCCARA Michael To: Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: _pfDirtCheck : pfWhatsThat ??? MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Status: O =0C Hi, I am loading many model files in pfb format. Her is an error notified by Performer at the first frame, and loopin= g all time since then:` PF Warning/SysErr _pfDirtCheck : bad pfObject index 415106528= The strangest is that this error disappears and my sim works OK when= I replace one of my models from pfb to iv format. Is there a bug in libpfpfb that limits the number of models you can = load in 1 simulation ? I am working on an Onyx RE2, Performer 2.0 and I extracted libpfpfb = from the sgi web site. Please give me some explanation because I am facing a wall in my dev= elopment. Regards, Michael Boccara - DCR/IK ! Aerospatiale Software engineer ! Centre commun = de email : ! recher= che Louis Bleriot michael.boccara(a)siege.aerospatiale.fr ! 12 rue Pasteur Tel : (+33) 1 46 97 32 40 ! 92150 Suresnes Fax : (+33) 1 46 97 32 59 ! France ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 06:14:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA06637; Fri, 17 Jan 1997 06:13:21 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA06621; Fri, 17 Jan 1997 06:13:20 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA04319; Fri, 17 Jan 1997 06:13:09 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id GAA23313 for ; Fri, 17 Jan 1997 06:13:07 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA23441; Fri, 17 Jan 97 08:11:15 -0500 Date: Fri, 17 Jan 97 08:11:15 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701171311.AA23441@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: AN interesting comment. Status: O A few people misinterpreted what I was saying about Jim Blinns seemingly remarkable assertion about double-framed rendering, 1) Blinn wasn't talking about double buffering - he was talking about double *framing* - the process of rendering the scene at (say) 30Hz on a 60Hz display. 2) I know (of course) about the obvious artifacts like fast moving objects appearing as though they are duplicated (or triplicated at 20Hz, etc) - that's due to a simple physiological effect which is easily explained. (If you'd like a simple explanation for this, let me know) What intrigued me was that Blinn seems to be telling us that the brain somehow interprets this update rate/video rate disparity as if the object is moving faster - even though it covers the same distance in the same time. That is a most remarkable claim - which (if true) should cause us all to wonder whether the practice of running simulations at 30Hz is as valid a cost cutting measure as we all currently assume it to be. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 07:16:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA06797; Fri, 17 Jan 1997 07:14:54 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA06781; Fri, 17 Jan 1997 07:14:53 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA07503; Fri, 17 Jan 1997 07:14:42 -0800 Received: from alf.mandator.se (mandator.se [195.84.33.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id HAA03239 for ; Fri, 17 Jan 1997 07:14:35 -0800 From: ulf.yngwe@mandator.se Received: by alf.mandator.se; id AA11603; Fri, 17 Jan 97 16:12:13 +0100 Received: from mail.mandator.se(192.168.140.10) by alf.mandator.se via smap (3.2) id xma011601; Fri, 17 Jan 97 16:12:08 +0100 Received: by mail.mandator.se(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id C1256422.00531225 ; Fri, 17 Jan 1997 16:07:21 +0200 X-Lotus-Fromdomain: MANDATOR To: info-performer@sgi.com Message-Id: Date: Fri, 17 Jan 1997 16:07:27 +0200 Subject: pfPipeWindows and OpenGL Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Status: O Ulf Yngwe 97-01-17 16:07 Hi! Shouldn=B4t this work on an O2 with Performer 2.0 or have I misunderstood something. I always get a BadMatch error on the glXMakeCurrent call. pfInit(); pfConfig(); p =3D pfGetPipe(0); pw =3D pfNewPWin(p); pfPWinType(pw, PFPWIN_TYPE_X); pfPWinName(pw, "IRIS Performer"); pfPWinOriginSize(pw, 0, 0, 500, 500); pfOpenPWin(pw); dpy=3DpfGetCurWSConnection(); win=3DpfGetPWinWSWindow(pw); wincxt=3DpfGetPWinGLCxt(pw); glXMakeCurrent(dpy,win,wincxt); = ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 07:58:25 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA06943; Fri, 17 Jan 1997 07:57:02 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA06927; Fri, 17 Jan 1997 07:57:02 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA10138; Fri, 17 Jan 1997 07:56:50 -0800 Received: from lobster.bu.edu (LOBSTER.BU.EDU [128.197.160.43]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA11297 for ; Fri, 17 Jan 1997 07:56:48 -0800 Received: (from ebrisson@localhost) by lobster.bu.edu (8.8.4/8.7.3) id KAA20683 for info-performer@sgi.com; Fri, 17 Jan 1997 10:56:54 -0500 From: Erik Brisson Message-Id: <199701171556.KAA20683@lobster.bu.edu> Subject: Re: AN interesting comment. To: info-performer@sgi.com Date: Fri, 17 Jan 97 10:56:53 EST In-Reply-To: <9701171311.AA23441@mred.bgm.link.com>; from "Steve Baker" at Jan 17, 97 8:11 am X-Mailer: ELM [version 2.3 PL11] Status: O >What intrigued me was that Blinn seems to be telling us that the brain >somehow interprets this update rate/video rate disparity as if the object >is moving faster - even though it covers the same distance in the same time. Perhaps the visual system does not compute distance as is assumed in this statement (i.e. distance / time over a long enough time to ignore the discrete frame rate). An alternative would be that it is done "instantaneously", i.e., the visual system may identify an object in the two positions before and after a jump, and divide that distance by some fixed time length (determined by neural properties). The obvious next question is then, what about the stationary time periods. You get a sequence of zero motion with high velocity values in between. But it may be that the zero values are simply ignored, and only the high velocity information is passed up to the higher vision levels. From an evolutionary point of view this sort of makes sense. Motion in the real world is smooth, so nothing is lost by this. The processing can be done at a lower level, and quicker. It also requires no division, which is simpler. This is all naive speculation which I can't back up. But an interesting question deserves (or will at least invariably solicit) speculative answers. Erik ------------------------------------------------------------------------------- Erik Brisson Manager of Graphics Programming Scientific Computing and Visualization Group Boston University Office of Information Technology 111 Cummington Street Boston, MA 02215 e-mail: ebrisson@bu.edu ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 07:58:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA06965; Fri, 17 Jan 1997 07:57:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA06949; Fri, 17 Jan 1997 07:57:46 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA10212; Fri, 17 Jan 1997 07:57:34 -0800 Received: from vrserver (vrserver.vr.iao.fhg.de [137.251.55.129]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA11439 for ; Fri, 17 Jan 1997 07:57:28 -0800 Received: from bigbro (bigbro [137.251.55.145]) by vrserver (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA10325 for ; Fri, 17 Jan 1997 16:55:21 +0100 Sender: ans@iao.fhg.de Message-ID: <32DFA0E9.41C6@iao.fhg.de> Date: Fri, 17 Jan 1997 16:55:21 +0100 From: Andreas Simon X-Mailer: Mozilla 2.0S (X11; I; IRIX64 6.2 IP25) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Re: AN interesting comment. References: <9701162119.AA20838@mred.bgm.link.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Steve Baker wrote: > > There is another effect of double framing however. A motion that is > > double framed seems to move faster than one that is single framed, The assertion that sampled aka jerky motion is overestimated is supported by some work on human motion perception (I really wish I would religously archive every single paper I see...). Bad thing seems to be that this may have some effect even at 60Hz. Note that dropping frames also contributes to jerkyness. From experience I'd say overestimation seems to be in the order of 5-10% at 30Hz though I haven't done any kind of formal study. This effect creeps in when doing dynamic stereo (combining stereo with motion parallax to account for a moving observer). Observers tend to reduce the geometric effect of head motion to around 0.9 to perceive a stabilized stereoscopic image in space. -- ----------------------------------------------------------------------- Andreas Simon IAO Fraunhofer Gesellschaft, Stuttgart Germany Phone: ++49 711 970 2153 email: Andreas.Simon@iao.fhg.de ----------------------------------------------------------------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 09:09:53 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA07251; Fri, 17 Jan 1997 09:08:12 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA07235; Fri, 17 Jan 1997 09:08:12 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA16378; Fri, 17 Jan 1997 09:08:00 -0800 Received: from octagon.tacom.army.mil (octagon.tacom.army.mil [147.240.16.254]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27144 for ; Fri, 17 Jan 1997 09:07:53 -0800 From: tidrowd@cc.tacom.army.mil Received: from cc.tacom.army.mil by octagon.tacom.army.mil (8.8.4/8.8.4-kbp) with SMTP id LAA00994; Fri, 17 Jan 1997 11:54:18 -0500 (EST) Received: from ccMail by cc.tacom.army.mil (IMA Internet Exchange 1.04b) id 2dfadea0; Fri, 17 Jan 97 11:50:50 -0500 Mime-Version: 1.0 Date: Fri, 17 Jan 1997 09:55:01 -0500 Message-ID: <2dfadea0@cc.tacom.army.mil> To: info-performer@sgi.com, "Siva Sankaran" Subject: Re: My MultiGen model developed on RE2 and MultiGenII 1.0 do Content-Type: multipart/mixed; boundary="IMA.Boundary.058915358" Status: O This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.058915358 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part There is a new Performer loader that ships with MultiGenII, that I've been told supports new features in the latest version of OpenFlight (comments, Marcus?). We just recently had to install it off the MultiGenII CDROM for a demo that used OpenFlight 15.2 files. Hopefully that will fix your problem. Don Tidrow Visual Simulation Developer US Army TACOM ______________________________ Reply Separator _________________________________ Subject: My MultiGen model developed on RE2 and MultiGenII 1.0 does n Author: "Siva Sankaran" at TWLAN-SMTP Date: 1/15/97 4:58 PM Hi, I have develoeped a walkthrough model on RE2, using MultiGenII 1.0. When I load the model using perfly on IR machine the model gets loaded with no textures at all. Even while loading the textures at the strart up of the Perfly it just shows white rectangles being loaded. Then I try loading same data base using MultiGenII 1.0 on IR, even MultiGen also has a problem with it. The textures are loaded in texture pallet and if I select any texture from the pallete, suddenly it becomes visible on wrongly applied polygone. Other polygones continue to be white. I use Performer 2.0 with OpenFlight 14.x Performer loader. Is there any changes in MultiGen and it's loader for IR. Is it available online as patches so that I can download. Sunil Hadap ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com --IMA.Boundary.058915358-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 09:09:54 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA07233; Fri, 17 Jan 1997 09:08:11 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA07217; Fri, 17 Jan 1997 09:08:10 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA16371; Fri, 17 Jan 1997 09:07:58 -0800 Received: from octagon.tacom.army.mil (octagon.tacom.army.mil [147.240.16.254]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27168 for ; Fri, 17 Jan 1997 09:07:57 -0800 From: tidrowd@cc.tacom.army.mil Received: from cc.tacom.army.mil by octagon.tacom.army.mil (8.8.4/8.8.4-kbp) with SMTP id LAA01014; Fri, 17 Jan 1997 11:54:27 -0500 (EST) Received: from ccMail by cc.tacom.army.mil (IMA Internet Exchange 1.04b) id 2dfadfe0; Fri, 17 Jan 97 11:51:10 -0500 Mime-Version: 1.0 Date: Fri, 17 Jan 1997 10:08:54 -0500 Message-ID: <2dfadfe0@cc.tacom.army.mil> To: Thomas.Steudten@philosys.de (Thomas Steudten), info-performer@sgi.com Subject: Re: Q: No picking of pfbillboards? Content-Type: multipart/mixed; boundary="IMA.Boundary.078915358" Status: O This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.078915358 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Not sure if you have already received a reply, so here goes: >From the pfBillboard man page (under BUGS): "Intersection traversals test only the pfBillboard's bounding volume, not its individual pfGeoSets." If you really need it, you might be able to add intersection traversal callbacks to a pfBillboard node to fix this. Question to Performer team: Will this be fixed in the next release? Or is it something we should do using callbacks? Don Tidrow Visual Simulation Developer US Army TACOM ______________________________ Reply Separator _________________________________ Subject: Q: No picking of pfbillboards? Author: Thomas.Steudten@philosys.de (Thomas Steudten) at TWLAN-SMTP Date: 1/15/97 1:47 PM Hi, i've tried to pick some billboards in a scene graph by the call NrHits = pfChanPick( Channel, PFPK_M_NEAREST|PFTRAV_IS_PRIM, ChannelX, ChannelY, 0.0f, PickList ). But i got always NrHits = 0 for billboards. Other objects are ok for picking. Isn't it possible to pick billboards? Our equipment: Performer 2.0, OpenGL, Irix 5.3, 6.3, indy and some O2's. Regards, Thomas ================= KERNEL PANIC: /dev/null full ============================ | | | PHILOSYS Software GmbH | Phone: (+49) 89 321407-31 Dipl.-Ing. | Carl von Linde Str. 30a | Fax: (+49) 89 321407-36/12 Thomas Steudten | D-85716 Unterschleissheim | Url: http://www.philosys.de | Germany | Email: thomas@philosys.de ============================================================================ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com --IMA.Boundary.078915358-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 09:46:37 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA07426; Fri, 17 Jan 1997 09:45:06 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA07410; Fri, 17 Jan 1997 09:45:05 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA19898; Fri, 17 Jan 1997 09:44:54 -0800 Received: from zippo.paradigmsim.com (impact.paradigmsim.com [206.7.114.202]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06241; Fri, 17 Jan 1997 09:44:50 -0800 Received: from zippo.paradigmsim.com (localhost [127.0.0.1]) by zippo.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA02317; Fri, 17 Jan 1997 11:44:00 -0600 Sender: mew@paradigmsim.com Message-ID: <32DFBA60.446B@paradigmsim.com> Date: Fri, 17 Jan 1997 11:44:00 -0600 From: Mike Weiblen Organization: Paradigm Simulation, Inc. X-Mailer: Mozilla 3.0 (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Angus Dorbie CC: info-performer@sgi.com Subject: Re: AN interesting comment. References: <9701162119.AA20838@mred.bgm.link.com> <32DEB0F7.2781@paradigmsim.com> <9701170905.ZM12041@bitch.reading.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O I've come to realize that using only two question marks was insufficient to indicate the incredulity I attempted to infer in my original comment. :-) I would like to better understand exactly what Blinn is describing. Is the term "conventional animators" (perhaps meaning hand-drawn cel animation) significant to the context of his comment? Steve, could you post the URL to the original document? Cheers -- mew Angus Dorbie wrote: > This is a strange statement, motion blur is primarily used to > avoid temporal aliasing. > > Cheers, > Angus. > > On Jan 16, 4:51pm, Mike Weiblen wrote: > > The double framing would seem to invite temporal aliasing, > > which is perhaps perceived as a motion blur?? -- Mike Weiblen talkto:972-960-2301 x292 PARADIGM Simulation, Inc. faxto:972-960-2303 14900 Landmark, Suite 400 mailto:mew@paradigmsim.com Dallas TX 75240 http://www.paradigmsim.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 09:51:58 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA07462; Fri, 17 Jan 1997 09:51:07 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA07446; Fri, 17 Jan 1997 09:51:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA20602; Fri, 17 Jan 1997 09:50:56 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07574 for ; Fri, 17 Jan 1997 09:50:55 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for <@rock.csd.sgi.com:info-performer@sgi.com> id JAA20599; Fri, 17 Jan 1997 09:50:54 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer@sgi.com id JAA20583; Fri, 17 Jan 1997 09:51:05 -0800 From: "Rob Jenkins" Message-Id: <9701170951.ZM20581@quid.csd.sgi.com> Date: Fri, 17 Jan 1997 09:51:04 -0800 In-Reply-To: Andreas Simon "Re: AN interesting comment." (Jan 17, 4:55pm) References: <9701162119.AA20838@mred.bgm.link.com> <32DFA0E9.41C6@iao.fhg.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Re: AN interesting comment. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Interesting thread this. Not sure this is wholly relevant but human vision does 'overshoot' in preception of color changes leading to the Mach Banding effect. Foley and Van Dam has an explanation as does: http://www.math.gatech.edu/~tpan/rectangles.html This doesn't explain the effect this thread is talking about, just an example of the nuances of human vision. Cheers Rob -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 10:52:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA07755; Fri, 17 Jan 1997 10:51:04 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA07739; Fri, 17 Jan 1997 10:51:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA26692; Fri, 17 Jan 1997 10:50:52 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22510; Fri, 17 Jan 1997 10:50:49 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA13008; Fri, 17 Jan 1997 18:50:40 GMT From: "Angus Dorbie" Message-Id: <9701171850.ZM13006@bitch.reading.sgi.com> Date: Fri, 17 Jan 1997 18:50:39 +0000 In-Reply-To: "Rob Jenkins" "Re: AN interesting comment." (Jan 17, 9:51am) References: <9701162119.AA20838@mred.bgm.link.com> <32DFA0E9.41C6@iao.fhg.de> <9701170951.ZM20581@quid.csd.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Rob Jenkins" , info-performer@sgi.com Subject: Re: AN interesting comment. Cc: tpan@math.gatech.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 17, 9:51am, Rob Jenkins wrote: > http://www.math.gatech.edu/~tpan/rectangles.html > I know this is a Mach effect but is it the proverbial Mach banding? I have heard it called this before but always had an uncomfortable doubt. The images in the URL show this Mach effect: ____________ __________ | / | / | | | | | / ______________| _________/ actual intensity perceived intensity And I thought Mach banding was: __ ____________ / \_________ / / / / / / / / / / / / actual intensity perceived intensity Graph axes guide: (intensity) ^ | | | -------> (space) Hence a percieved intensity band where none exists, often seen in graphics when intensity gets clamped to a maximum value. Any takers for this Fridays pub trivia question? I think Foley van Damn is where I remember these graphs from but my copy is at home. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 11:24:11 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA07889; Fri, 17 Jan 1997 11:22:21 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA07873; Fri, 17 Jan 1997 11:22:20 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA00016; Fri, 17 Jan 1997 11:22:09 -0800 Received: from daisy.paradigmsim.com (daisy.paradigmsim.com [206.7.114.129]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA00640; Fri, 17 Jan 1997 11:21:58 -0800 Received: (from eliza@localhost) by daisy.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA11690; Fri, 17 Jan 1997 13:21:23 -0600 From: "Elizabeth Smith" Message-Id: <9701171321.ZM11689@daisy.paradigmsim.com> Date: Fri, 17 Jan 1997 13:21:23 -0600 In-Reply-To: "Angus Dorbie" "Re: AN interesting comment." (Jan 17, 6:50pm) References: <9701162119.AA20838@mred.bgm.link.com> <32DFA0E9.41C6@iao.fhg.de> <9701170951.ZM20581@quid.csd.sgi.com> <9701171850.ZM13006@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Angus Dorbie" , info-performer@sgi.com Subject: Re: AN interesting comment. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 17, 6:50pm, Angus Dorbie wrote: > Subject: Re: AN interesting comment. > On Jan 17, 9:51am, Rob Jenkins wrote: > > > http://www.math.gatech.edu/~tpan/rectangles.html > > > > I know this is a Mach effect but is it the proverbial Mach banding? > I have heard it called this before but always had an uncomfortable > doubt. > > The images in the URL show this Mach effect: > > ____________ __________ > | / > | / > | | > | | > | / > ______________| _________/ > > actual intensity perceived intensity > > > And I thought Mach banding was: > __ > ____________ / \_________ > / / > / / > / / > / / > / / > / / > actual intensity perceived intensity > > Graph axes guide: > > (intensity) > ^ > | > | > | > -------> (space) > > Hence a percieved intensity band where none exists, often seen in > graphics when intensity gets clamped to a maximum value. > > Any takers for this Fridays pub trivia question? I think Foley van Damn > is where I remember these graphs from but my copy is at home. Figure 16.17 of F&VD c1990 confirms the correctness of your graphs. Also, in the same book, see section 21.5 "Problems Peculiar to Animation" for a discussion of the "double framing", called "animating by twos" on page 1080. It mentions only the jerkiness of animations so generated. > Cheers, > Angus. > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Angus Dorbie -- |---- Elizabeth Smith ---- | | 972-960-2301 (voice) Paradigm Simulation, Inc. | | 972-960-9049 (FAX) 14900 Landmark, Suite 400 | | eliza@paradigmsim.com Dallas, Texas 75240 USA | | http://www.paradigmsim.com | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 11:37:06 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA07950; Fri, 17 Jan 1997 11:35:45 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA07934; Fri, 17 Jan 1997 11:35:45 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA01529; Fri, 17 Jan 1997 11:35:33 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03907 for ; Fri, 17 Jan 1997 11:35:32 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA26902; Fri, 17 Jan 1997 11:35:24 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA22783; Fri, 17 Jan 1997 11:35:07 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701171935.LAA22783@remi.asd.sgi.com> Subject: Re: Edge-detection on results of pfDraw To: chris@mpik-tueb.mpg.de Date: Fri, 17 Jan 1997 11:35:07 -0800 (PST) Cc: info-performer@sgi.com In-Reply-To: from "chris@mpik-tueb.mpg.de" at Jan 17, 97 08:29:17 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 700 Status: O chris@mpik-tueb.mpg.de wrote: > > > Does anyone have experience of carrying out simple image processing > on the results of pfDraw. In particular i'd like to perform thresholding, > convolution and edge detection on what's being sent to the framebuffer > by a given channel. > Thanks > Chris the result of a pfFrame is available in the Frame Buffer. You can, for example, read it back using glReadPixels() right after the call to pfFrame. You can use the localPostDraw(channel, data) function of perfly.c to do this. Best Regards _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 11:44:35 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA08048; Fri, 17 Jan 1997 11:43:43 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA08032; Fri, 17 Jan 1997 11:43:42 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA02210; Fri, 17 Jan 1997 11:43:31 -0800 Received: from daisy.paradigmsim.com (daisy.paradigmsim.com [206.7.114.129]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA06111; Fri, 17 Jan 1997 11:43:22 -0800 Received: (from eliza@localhost) by daisy.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA11727; Fri, 17 Jan 1997 13:42:47 -0600 From: "Elizabeth Smith" Message-Id: <9701171342.ZM11726@daisy.paradigmsim.com> Date: Fri, 17 Jan 1997 13:42:46 -0600 In-Reply-To: "Angus Dorbie" "Re: AN interesting comment." (Jan 17, 6:50pm) References: <9701162119.AA20838@mred.bgm.link.com> <32DFA0E9.41C6@iao.fhg.de> <9701170951.ZM20581@quid.csd.sgi.com> <9701171850.ZM13006@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com, "Angus Dorbie" Subject: Re: AN interesting comment. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O For those who don't have the Foley and Van Dam book handy: the graphs are: |\ ____________ | \__________ | | | | | | | | | | ______________| ____________ | \ | \| actual intensity perceived intensity (intensity) ^ | | | -------> (space) On Jan 17, 6:50pm, Angus Dorbie wrote: > Subject: Re: AN interesting comment. > On Jan 17, 9:51am, Rob Jenkins wrote: > > > http://www.math.gatech.edu/~tpan/rectangles.html > > > > I know this is a Mach effect but is it the proverbial Mach banding? > I have heard it called this before but always had an uncomfortable > doubt. > > The images in the URL show this Mach effect: > > ____________ __________ > | / > | / > | | > | | > | / > ______________| _________/ > > actual intensity perceived intensity > > > And I thought Mach banding was: > __ > ____________ / \_________ > / / > / / > / / > / / > / / > / / > actual intensity perceived intensity > > Graph axes guide: > > (intensity) > ^ > | > | > | > -------> (space) > > Hence a percieved intensity band where none exists, often seen in > graphics when intensity gets clamped to a maximum value. > > Any takers for this Fridays pub trivia question? I think Foley van Damn > is where I remember these graphs from but my copy is at home. > > > Cheers, > Angus. > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Angus Dorbie -- |---- Elizabeth Smith ---- | | 972-960-2301 (voice) Paradigm Simulation, Inc. | | 972-960-9049 (FAX) 14900 Landmark, Suite 400 | | eliza@paradigmsim.com Dallas, Texas 75240 USA | | http://www.paradigmsim.com | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 11:58:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA08162; Fri, 17 Jan 1997 11:56:29 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA08146; Fri, 17 Jan 1997 11:56:28 -0800 Received: from odin.corp.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA03809; Fri, 17 Jan 1997 11:56:17 -0800 Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id LAA23246; Fri, 17 Jan 1997 11:56:16 -0800 Received: from hoback.ncsa.uiuc.edu (hoback.ncsa.uiuc.edu [141.142.221.192]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08696 for ; Fri, 17 Jan 1997 11:53:39 -0800 Received: (from elpeters@localhost) by hoback.ncsa.uiuc.edu (8.7.1/8.7.1) id NAA09458 for info-performer@sgi.com; Fri, 17 Jan 1997 13:52:58 -0600 (CST) From: "Edward Peters" Message-Id: <9701171352.ZM9456@hoback.ncsa.uiuc.edu> Date: Fri, 17 Jan 1997 13:52:58 -0600 In-Reply-To: "Elizabeth Smith" "Re: AN interesting comment." (Jan 17, 1:51pm) References: <9701162119.AA20838@mred.bgm.link.com> <32DFA0E9.41C6@iao.fhg.de> <9701170951.ZM20581@quid.csd.sgi.com> <9701171850.ZM13006@bitch.reading.sgi.com> <9701171342.ZM11726@daisy.paradigmsim.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Re: AN interesting comment. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O There's also a good interactive demo of Mach banding at: http://www.tc.cornell.edu:80/Visualization/contrib/cs490-96to97/anson/MachBandingApplet/index.html (long URL -- whew!) On Jan 17, 1:51pm, Elizabeth Smith wrote: > Subject: Re: AN interesting comment. > For those who don't have the Foley and Van Dam book handy: > the graphs are: > (crunch) ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 12:10:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA08305; Fri, 17 Jan 1997 12:08:59 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA08289; Fri, 17 Jan 1997 12:08:59 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA05033; Fri, 17 Jan 1997 12:08:48 -0800 Received: from mailhost.multigen.com (mailhost.multigen.com [204.119.69.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12253 for ; Fri, 17 Jan 1997 12:08:41 -0800 Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [204.119.70.10]) by mailhost.multigen.com (8.6.11/8.6.12) with ESMTP id MAA29059 for ; Fri, 17 Jan 1997 12:14:02 -0800 Received: from vaisyas.engr.multigen.com (vaisyas.engr.multigen.com [204.119.70.76]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id UAA21653 for ; Fri, 17 Jan 1997 20:05:25 GMT Received: (from marcus@localhost) by vaisyas.engr.multigen.com (950413.SGI.8.6.12/8.6.12) id MAA06728 for info-performer@sgi.com; Fri, 17 Jan 1997 12:12:55 -0800 From: "Marcus Barnes" Message-Id: <9701171212.ZM6727@vaisyas.engr.multigen.com> Date: Fri, 17 Jan 1997 12:12:55 -0800 In-Reply-To: "Siva Sankaran" "My MultiGen model developed on RE2 and MultiGenII 1.0 does not work on IR!" (Jan 15, 4:58pm) References: <9701151658.ZM1848@triveni.newdelhi.sgi.com> Organization: MultiGen Inc. X-Phones: 1-408-556-2654 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Re: My MultiGen model developed on RE2 and MultiGenII 1.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 15, 4:58pm, Siva Sankaran wrote: > I use Performer 2.0 with OpenFlight 14.x Performer loader. > > Is there any changes in MultiGen and it's loader for IR. Is it available > online as patches so that I can download. You should be using R15.2 loader with MultiGen Series II. Current loader binaries are available from our web site at: http://www.multigen.com/FAQ/faq.htm Regards. -- + Marcus Barnes, Technical Staff mailto:marcus@multigen.com + + Multigen Inc. http://www.multigen.com + + 550 S. Winchester Blvd. phoneto:1-408-556-2654 + + Suite 500 San Jose CA 95128 faxto:1-408-261-4102 + ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 12:38:47 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA08576; Fri, 17 Jan 1997 12:37:19 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA08560; Fri, 17 Jan 1997 12:37:18 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA07916; Fri, 17 Jan 1997 12:37:06 -0800 Received: from mailhost.multigen.com (mailhost.multigen.com [204.119.69.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA18815 for ; Fri, 17 Jan 1997 12:37:02 -0800 Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [204.119.70.10]) by mailhost.multigen.com (8.6.11/8.6.12) with ESMTP id MAA29170 for ; Fri, 17 Jan 1997 12:42:43 -0800 Received: from vaisyas.engr.multigen.com (vaisyas.engr.multigen.com [204.119.70.76]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id UAA22211 for ; Fri, 17 Jan 1997 20:34:06 GMT Received: (from marcus@localhost) by vaisyas.engr.multigen.com (950413.SGI.8.6.12/8.6.12) id MAA06757 for info-performer@sgi.com; Fri, 17 Jan 1997 12:41:36 -0800 From: "Marcus Barnes" Message-Id: <9701171241.ZM6756@vaisyas.engr.multigen.com> Date: Fri, 17 Jan 1997 12:41:35 -0800 In-Reply-To: brian@sgi.com (Brian Furtaw) "Re: Texture detail and zbuffer on Impact" (Jan 15, 11:28am) References: <970115131432_101372.3460_JHP77-1@CompuServe.COM> <9701151128.ZM28372@hotsauce.clubfed.sgi.com> Organization: MultiGen Inc. X-Phones: 1-408-556-2654 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info_performer Subject: Re: Texture detail and zbuffer on Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 15, 11:28am, Brian Furtaw wrote: > On Jan 15, 8:14am, Jean BENOIT wrote: > > I work on Impact 5.3 with patch 1414 or 6.2 with patch 1392, 1347. > > With these patches have have always the same problem : > > - Bad texture detail on terrain > > Do the textures look dithered? Do you have 1 meg TRAMs or 4 meg TRAMs on this > IMPACT? You will see dithering with 1 meg TRAMs. Detail texture mag. filtering is very poor (broken) on Impact. I don't think that it improves with 4 meg TRAMS. I haven't seen a patch for it either. Regards. -- + Marcus Barnes, Technical Staff mailto:marcus@multigen.com + + Multigen Inc. http://www.multigen.com + + 550 S. Winchester Blvd. phoneto:1-408-556-2654 + + Suite 500 San Jose CA 95128 faxto:1-408-261-4102 + ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 13:53:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA08868; Fri, 17 Jan 1997 13:52:44 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA08852; Fri, 17 Jan 1997 13:52:43 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA14097; Fri, 17 Jan 1997 13:52:32 -0800 Received: from hoback.ncsa.uiuc.edu (hoback.ncsa.uiuc.edu [141.142.221.192]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA06179 for ; Fri, 17 Jan 1997 13:52:28 -0800 Received: (from elpeters@localhost) by hoback.ncsa.uiuc.edu (8.7.1/8.7.1) id PAA10977 for info-performer@sgi.com; Fri, 17 Jan 1997 15:52:25 -0600 (CST) From: "Edward Peters" Message-Id: <9701171552.ZM10975@hoback.ncsa.uiuc.edu> Date: Fri, 17 Jan 1997 15:52:25 -0600 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: intersection testing and pfTerrain Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I have a Geode which is a morphset of a pfTerrain node. I set up a segset and hits as follows: pfSegSet segset; pfHit **hits[32]; segset.isectMask = 0x01; segset.discFunc = NULL; segset.bound = NULL; segset.mode = PFTRAV_IS_PRIM; segset.segs[0].pos.set ((float)x, (float)y, 500.0f); segset.segs[0].dir.set (0.0f, 0.0f, -1.0f); segset.segs[0].length = 1000; segset.activeMask = 1; Then I do the following (my geode is pfGeode *ground): int isect = ground->isect(&segset, hits); if (isect) { // intersection, do something } else { // you missed, do something else } It fails every time (ie no intersections). Earlier I had some code (almost identical) which would fail sometimes, and work other times. Does the app and cull processing of the pfTerrain node use intersection testing to determine what's visible and what's not? If so, would it require a reset of the TravMask every frame for other intersection testing to work? I ask because part of the enigma seems to be where my intersections are placed relative to the call to pfFrame(). Thanks in advance for your help. Ed Peters elpeters@ncsa.uiuc.edu ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 13:52:56 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA08850; Fri, 17 Jan 1997 13:51:30 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA08834; Fri, 17 Jan 1997 13:51:30 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA14026; Fri, 17 Jan 1997 13:51:19 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA05795 for ; Fri, 17 Jan 1997 13:51:17 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA05808; Fri, 17 Jan 1997 16:50:19 -0500 Date: Fri, 17 Jan 1997 16:50:19 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701171650.ZM5807@hotsauce.clubfed.sgi.com> In-Reply-To: "Marcus Barnes" "Re: Texture detail and zbuffer on Impact" (Jan 17, 12:41pm) References: <970115131432_101372.3460_JHP77-1@CompuServe.COM> <9701151128.ZM28372@hotsauce.clubfed.sgi.com> <9701171241.ZM6756@vaisyas.engr.multigen.com> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Marcus Barnes" , info_performer Subject: Re: Texture detail and zbuffer on Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I don't think he is talking about detail texturing, he is refering to texture detail or image quality or artifacts created by dithering. I don't know if the # TRAMs have any effect on the quality of detail texturing. Brian On Jan 17, 12:41pm, Marcus Barnes wrote: > Subject: Re: Texture detail and zbuffer on Impact > On Jan 15, 11:28am, Brian Furtaw wrote: > > On Jan 15, 8:14am, Jean BENOIT wrote: > > > > I work on Impact 5.3 with patch 1414 or 6.2 with patch 1392, 1347. > > > With these patches have have always the same problem : > > > - Bad texture detail on terrain > > > > Do the textures look dithered? Do you have 1 meg TRAMs or 4 meg TRAMs on this > > IMPACT? You will see dithering with 1 meg TRAMs. > > Detail texture mag. filtering is very poor (broken) on Impact. I don't think > that it improves with 4 meg TRAMS. I haven't seen a patch for it either. > > Regards. > -- > + Marcus Barnes, Technical Staff mailto:marcus@multigen.com + > + Multigen Inc. http://www.multigen.com + > + 550 S. Winchester Blvd. phoneto:1-408-556-2654 + > + Suite 500 San Jose CA 95128 faxto:1-408-261-4102 + > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Marcus Barnes -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 16:25:20 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id QAA09850; Fri, 17 Jan 1997 16:24:12 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA09834; Fri, 17 Jan 1997 16:24:12 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id QAA28966; Fri, 17 Jan 1997 16:24:00 -0800 Received: from atlantis.actrix.gen.nz (atlantis.actrix.gen.nz [203.96.16.23]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14025 for ; Fri, 17 Jan 1997 16:23:57 -0800 Received: (from uuplgo@localhost) by atlantis.actrix.gen.nz (8.8.2/8.8.2) id NAA23105 for sgi.com!info-performer; Sat, 18 Jan 1997 13:23:53 +1300 (NZDT) X-Authentication-Warning: atlantis.actrix.gen.nz: uuplgo set sender to planetgo.co.nz!nigel using -f >Received: (from nigel@localhost) by planetgo.co.nz (8.7.1/8.7.1) id NAA04137 for info-performer@sgi.com; Sat, 18 Jan 1997 13:19:12 +1300 From: Nigel Caughey Message-Id: <199701180019.NAA04137@planetgo.co.nz> Subject: Re: AN interesting comment. To: info-performer@planetgo.co.nz Date: Sat, 18 Jan 1997 13:19:12 +1300 (NZDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: O Forwarded message: > Sender: mew@paradigmsim.com > I've come to realize that using only two question marks was > insufficient to indicate the incredulity I attempted to infer > in my original comment. :-) > > I would like to better understand exactly what Blinn is > describing. Is the term "conventional animators" > (perhaps meaning hand-drawn cel animation) significant > to the context of his comment? >From my experience in Animation(computer) yes, a reasonable amount of hand draw/conventional animation is/was 12.5fps(PAL) and in fact some early computer animation also (especially if the deadline got too tight :) ). We had a similar effect actually with rendering at 50fps vs 25fps, 50fps is visually smoother, though we were explicitly asked to render at 25fps because the "effect" was better (probably as that is what advertisers got with film). Remember this is all Televison animation I am talking about here and interlace is a significant factor in that, though the basic principle I presume stays the same. -- Nigel Caughey Ph:+64 4 6190482 Systems Analyst Fax:+64 4 6190483 PlanetGo Email:nigel@planetgo.co.nz Avalon TV Studios WWW:http://www.planetgo.co.nz/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 17 17:26:40 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA10038; Fri, 17 Jan 1997 17:25:21 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA10022; Fri, 17 Jan 1997 17:25:20 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA03376; Fri, 17 Jan 1997 17:25:10 -0800 Received: from sgidev.mdc.com (SGIDEV.MDC.COM [129.200.1.58]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA25408 for ; Fri, 17 Jan 1997 17:25:09 -0800 Received: from mbsgi4.mdc.com by sgidev.mdc.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for <@sgidev.mdc.com:info-performer@sgi.com> id RAA03968; Fri, 17 Jan 1997 17:18:53 -0800 Received: from mbsgi4 by mbsgi4.mdc.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA03042; Fri, 17 Jan 1997 17:18:50 -0800 Sender: olivier@sgidev.mdc.com Message-ID: <32E024FA.41C6@sgidev.mdc.com> Date: Fri, 17 Jan 1997 17:18:50 -0800 From: Olivier Schreiber Organization: McDonnell Douglas X-Mailer: Mozilla 3.0Gold (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: info-performer@sgi.com Subject: convolve, glConvolutionFilter2DEXT and IR Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O I have this simple minded example thanks to Nicolas Gauvin for using convolve in IRIS GL with performer 2.* It works fine on an RE2 but does not produce any effect on IR. The man page for convolve does not specifically say whether gl convolve is supported on IR. Additionally, I am trying to convert it to OPEN GL. The man page says results are unreliable. Any suggestion appreciated. Thanks. ksh> more simple.C // simpleC.C: simple Performer program for programmer's guide with convolution // // $Revision: 1.3 $ // $Date: 1997/01/18 00:58:14 $ // #include #include #include #include #include #include #include #include #include #include // // Usage() -- print usage advice and exit. This // procedure is executed in the application process. // static void Usage (void) { pfNotify(PFNFY_FATAL, PFNFY_USAGE, "Usage: simpleC file.ext ...\n"); exit(1); } static void drawCB( pfChannel* chan, void* data ) { static int first = 1; #define val7x7 0.020408163f static float blur7x7[] = { val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, val7x7, }; if (first) { #ifdef CONVOLVE #ifdef OPENGL glConvolutionFilter2DEXT( GL_CONVOLUTION_2D_EXT, /*has to be this value*/ GL_RGBA, /*filter kernel internal format*/ 7, 7, /*width & height of image pixel array*/ GL_RGBA, /*image internal format*/ GL_FLOAT, /*type of image pixel data*/ (const void*)blur7x7 /* image itself*/ ); #else convolve (CV_GENERAL, CV_REDUCE, 7,7, blur7x7, 0.0f ); pixmode (PM_INPUT_FORMAT, PM_BGR); pixmode (PM_OUTPUT_FORMAT, PM_BGR); #endif #endif first = 0; } #ifdef OPENGL glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); #else chan->clear(); #endif pfDraw(); #ifdef CONVOLVE /* convolution is done during the rectcopy */ #ifdef OPENGL glRasterPos2i(2,2); glCopyPixels(0, 0, 640-0+1, 480-0+1, GL_COLOR); #else rectcopy(0,0,640,480,2,2); #endif #endif } int main (int argc, char *argv[]) { float t = 0.0f; if (argc < 2) Usage(); // Initialize Performer pfInit(); // Use default multiprocessing mode based on number of // processors. // pfMultiprocess( PFMP_DEFAULT ); // Load all loader DSO's before pfConfig() forks pfdInitConverter(argv[1]); // initiate multi-processing mode set in pfMultiprocess call // FORKs for Performer processes, CULL and DRAW, etc. happen here. // pfConfig(); // Append to Performer search path, PFPATH, files in // /usr/share/Performer/data */ pfFilePath(".:/usr/share/Performer/data"); pfNode *root = pfdLoadFile(argv[1]); if (root == NULL) { pfExit(); exit(-1); } // Attach loaded file to a new pfScene pfScene *scene = new pfScene; scene->addChild(root); // Create a pfLightSource and attach it to scene scene->addChild(new pfLightSource); // Configure and open GL window pfPipe *p = pfGetPipe(0); pfPipeWindow *pw = new pfPipeWindow(p); pw->setWinType(PFPWIN_TYPE_X); pw->setName("IRIS Performer"); pw->setOriginSize(300,400,640,480); pw->open(); // Create and configure a pfChannel. pfChannel *chan = new pfChannel(p); chan->setScene(scene); chan->setFOV(45.0f, 0.0f); chan->setTravFunc(PFTRAV_DRAW, drawCB ); // determine extent of scene's geometry pfSphere bsphere; root->getBound(&bsphere); chan->setNearFar(1.0f, 10.0f * bsphere.radius); // Simulate for twenty seconds. while (t < 60.0f) { pfCoord view; float s, c,t0; // Go to sleep until next frame time. pfSync(); // Initiate cull/draw for this frame. pfFrame(); // Compute new view position. t = pfGetTime(); t0=t; pfSinCos(45.0f*t0, &s, &c); view.hpr.set(45.0f*t0, -10.0f, 0); view.xyz.set(2.0f * bsphere.radius * s, -2.0f * bsphere.radius *c, 0.5f * bsphere.radius); chan->setView(view.xyz, view.hpr); } // Terminate parallel processes and exit pfExit(); return 0; } ksh> -- Olivier Schreiber olivier@sgidev.mdc.com 310 593 9739 FAX 593 0296 Military Transport Aircraft, McDonnell Douglas Corporation Mail Code D041/0056, 2401 E. Wardlow Road Long Beach, CA 90807-5309 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 18 09:36:37 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA11353; Sat, 18 Jan 1997 09:35:25 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA11337; Sat, 18 Jan 1997 09:35:24 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA01608; Sat, 18 Jan 1997 09:35:13 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07570; Sat, 18 Jan 1997 09:35:11 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA14066; Sat, 18 Jan 1997 17:35:08 GMT From: "Angus Dorbie" Message-Id: <9701181735.ZM14064@bitch.reading.sgi.com> Date: Sat, 18 Jan 1997 17:35:08 +0000 In-Reply-To: Olivier Schreiber "convolve, glConvolutionFilter2DEXT and IR" (Jan 17, 5:18pm) References: <32E024FA.41C6@sgidev.mdc.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Olivier Schreiber , info-performer@sgi.com Subject: Re: convolve, glConvolutionFilter2DEXT and IR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 17, 5:18pm, Olivier Schreiber wrote: > Subject: convolve, glConvolutionFilter2DEXT and IR > I have this simple minded example thanks to Nicolas Gauvin > for using convolve in IRIS GL with performer 2.* > It works fine on an RE2 but does not produce any effect on IR. > The man page for convolve does not specifically say whether > gl convolve is supported on IR. > > Additionally, I am trying to convert it to OPEN GL. > The man page says results are unreliable. > > Any suggestion appreciated. > Thanks. > Using OpenGL you need to enable the convolution during pixel transfer: glEnable(GL_CONVOLUTION_2D_EXT); Adding this to your code will fix the OpenGL. I expect your IrisGL problems are due to bugs in IGLOO, you might want to try the IGLOO patch 1422 and also make sure you have the iR gfx patch 1355. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 18 09:21:12 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA11320; Sat, 18 Jan 1997 09:20:02 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA11304; Sat, 18 Jan 1997 09:20:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA01239; Sat, 18 Jan 1997 09:19:50 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA05787; Sat, 18 Jan 1997 09:19:48 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA14052; Sat, 18 Jan 1997 17:19:46 GMT From: "Angus Dorbie" Message-Id: <9701181719.ZM14050@bitch.reading.sgi.com> Date: Sat, 18 Jan 1997 17:19:45 +0000 In-Reply-To: "Elizabeth Smith" "Re: AN interesting comment." (Jan 17, 1:42pm) References: <9701162119.AA20838@mred.bgm.link.com> <32DFA0E9.41C6@iao.fhg.de> <9701170951.ZM20581@quid.csd.sgi.com> <9701171850.ZM13006@bitch.reading.sgi.com> <9701171342.ZM11726@daisy.paradigmsim.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Elizabeth Smith" , info-performer@sgi.com Subject: Re: AN interesting comment. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 17, 1:42pm, Elizabeth Smith wrote: > Subject: Re: AN interesting comment. > For those who don't have the Foley and Van Dam book handy: > the graphs are: > > |\ > ____________ | \__________ > | | > | | > | | > | | > | | > ______________| ____________ | > \ | > \| > actual intensity perceived intensity > > (intensity) > ^ > | > | > | > -------> (space) > > > On Jan 17, 6:50pm, Angus Dorbie wrote: > > The images in the URL show this Mach effect: > > > > ____________ __________ > > | / > > | / > > | | > > | | > > | / > > ______________| _________/ > > > > actual intensity perceived intensity ^ | Yep, this graph is wrong and actually shows | the opposite of the effect! _____________________| I must have had my receptors mixed up when I drew it :-) Still, both the posted URLs seem to reffer to the corrected graph above and not the mach banding effect in the graph below and now that I've checked Foley & Van Dam, both are described as examples of Mach banding. Even if the Foley example deviates a little from my graph below. I've resisted the temptation to post a gif of the effect below. Cheers, Angus. > > > > And I thought Mach banding was: > > __ > > ____________ / \_________ > > / / > > / / > > / / > > / / > > / / > > / / > > actual intensity perceived intensity > > > > Graph axes guide: > > > > (intensity) > > ^ > > | > > | > > | > > -------> (space) > > > > Hence a percieved intensity band where none exists, often seen in > > graphics when intensity gets clamped to a maximum value. > > > > Any takers for this Fridays pub trivia question? I think Foley van Damn > > is where I remember these graphs from but my copy is at home. > > ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 18 10:18:29 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA11543; Sat, 18 Jan 1997 10:17:04 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA11527; Sat, 18 Jan 1997 10:17:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA02456; Sat, 18 Jan 1997 10:16:52 -0800 Received: from gatekeeper.rayva.org (gatekeeper.rayva.org [204.254.244.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA12436 for ; Sat, 18 Jan 1997 10:16:43 -0800 Received: (from mail@localhost) by gatekeeper.rayva.org (8.6.12/8.6.12) id NAA05533; Sat, 18 Jan 1997 13:17:57 -0500 Received: from jpsds14e(192.168.5.103) by gatekeeper via smap (V1.3) id sma005531; Sat Jan 18 13:17:34 1997 Received: from tdecarlo (ppp226 [192.168.5.226]) by jpsds14e.rayva.org (8.6.12/8.6.12) with ESMTP id NAA01148; Sat, 18 Jan 1997 13:10:32 -0500 Message-ID: <32E11251.48E5@rayva.org> Date: Sat, 18 Jan 1997 13:11:29 -0500 From: Thom DeCarlo Reply-To: tdecarlo@rayva.org Organization: TASC, Inc. X-Sender: Thom DeCarlo X-Mailer: Mozilla 4.0b1 (Win95; I) MIME-Version: 1.0 To: info-performer , info-vega Subject: Still working on shadows... X-Priority: Normal Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Status: O Some time ago I wrote asking if anyone had any experience trying to render shadows cast by the sun in a large area sim. I haven't seen a responce, but several people have emailed me to ask if I have solved the problem. Well, since I haven't found a solution I thought I should try restating the question. I assume that I would need an infinite, rather than local, light source to achieve the correct effect. Am I right, or is there some other way to do this? Perhaps if I attach a local light to the observer's DCS? But then it would still need to be very far away and not rotate when the observer changes orientation. Has anyone out there come up with a workable solution? Thom  -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ Thom DeCarlo * Off-site contact info TASC * JPSD/IEC, US Army TEC 12100 Sunset Hills Rd. * 7701 Telegraph Rd., Bldg 2592 Reston, VA 22090 * Alexandria, VA 22315 phone: 703/834-5000 * phone: 703/428-7034 fax: 703/318-7900 * fax: 703/428-7054 mailto:trdecarlo@tasc.com * mailto:thom@dogwood.tec.army.mil ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ There was a time when religion ruled the world. It is known as the Dark Ages. -Ruth Hurmence Green "The Born-again Skeptic's Guide to the Bible" ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 18 12:46:03 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA11734; Sat, 18 Jan 1997 12:44:50 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA11718; Sat, 18 Jan 1997 12:44:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA05839; Sat, 18 Jan 1997 12:44:38 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA28267; Sat, 18 Jan 1997 12:44:31 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id UAA14633; Sat, 18 Jan 1997 20:44:29 GMT From: "Angus Dorbie" Message-Id: <9701182044.ZM14629@bitch.reading.sgi.com> Date: Sat, 18 Jan 1997 20:44:28 +0000 In-Reply-To: Thom DeCarlo "Still working on shadows..." (Jan 18, 1:11pm) References: <32E11251.48E5@rayva.org> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: tdecarlo@rayva.org, info-performer , info-vega Subject: Re: Still working on shadows... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19701182044.ZM14629.reading.sgi.com" Status: O -- --PART-BOUNDARY=.19701182044.ZM14629.reading.sgi.com Content-Type: text/plain; charset=us-ascii On Jan 18, 1:11pm, Thom DeCarlo wrote: > Subject: Still working on shadows... > Some time ago I wrote asking if anyone had any experience trying > to render shadows cast by the sun in a large area sim. I haven't > seen a responce, but several people have emailed me to ask if I > have solved the problem. Well, since I haven't found a solution > I thought I should try restating the question. > > I assume that I would need an infinite, rather than local, light > source to achieve the correct effect. Am I right, or is there some > other way to do this? Perhaps if I attach a local light to the > observer's DCS? But then it would still need to be very far away > and not rotate when the observer changes orientation. > > Has anyone out there come up with a workable solution? I'm surprised nobody has been able to help you with this. There's depth mapped shadows but this is impractical for most visual simulation due to the rendering overhead, even with the reduced number of passes required on iR. Another method is to render the projected shadow volume, outside then inside, to the stencil planes while zbuffering. With a stencil increment on the outside and decrement on the inside you end up with stencil == 1 where the shadow projects onto surfaces. Exactly the same method can be used for per-pixel spotlights. You then re-render the lit or shadowed surfaces with or without light with a stencil operation which only writes to stencil == 1 for your final effect. This is also multi-pass so for most Vis Sim it's not appropriate. It sounds like what you need is yer standard flat plane shadows projection, made famous by the "Ideas in Motion" demo. As this demo shows, it's possible to project geometry from the light source position onto a plane, and the light source can even be a local one. You can use the geometry of the object casting the shadow for this but it's probably wiser to use a very simplified representation of the object casting the shadow. You place the simplified object below a DCS which has the transformation required to project it onto the ground plane. For this to work you will have to work around zfighting issues, you should also use a black geostate and a stipple pattern or multisample transparency for the shadow contribution. So the only tricky part is figuring out how to produce the projective matrix required for the shadow. Thankfully I don't have to work this out because Thant Tessman has already described this in an IRIS Universe Programmers Corner, way back when that publication was usefull. Plagerising shamelessly from this article, here's how it's done for a infinite light source. I've adjusted the sums for Performers coordinate system: The equation to project to the ground where z==0 is as follows. Where, lx, ly, lz are the light vector and mx, my, mz are the model coordinates and sx, sy, sz are shadow coordinates. sx = mx + mz * lx/lz sy = my + mz * ly/lz sz = 0 So you now have to build a 4x4 matrix to set in a DCS which will apply this transformation to the model coordinates. [ 1.0 0.0 0.0 0.0 ] [ 0.0 1.0 0.0 0.0 ] [ lx/lz ly/lz 0.0 0.0 ] [ 0.0 0.0 0.0 1.0 ] In code this might look like: if ((root = pfdLoadFile(argv[arg])) != NULL) { pfMatrix *doomed; // create a DCS shadow casting pfDCS *shadow = new pfDCS(); // build the matrix with projection onto horizontal z=0 plane shadow->setMat( * (doomed = new pfMatrix ( 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, lx/lz, ly/lz, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f, )) ); delete doomed; shadow->addChild(root); scene->addChild(shadow); } Attached is a small gif of a test of this shadows method in performer using the above code by loading a duplicate flt file which has been made black in the modelling tool. For other horizontal planes you can very simply introduce the delta values in the arithmetic. Non horizontal planes and local light sources are more difficult to figure but can be done. If you want me to go over the local light source stuff in Thant's article I will. Cheers, Angus. --PART-BOUNDARY=.19701182044.ZM14629.reading.sgi.com X-Zm-Content-Name: shad.gif Content-Description: Gif Image Content-Type: image/gif ; name="shad.gif" ; x-irix-type=GIF89Image Content-Transfer-Encoding: base64 X-Zm-Decoding-Hint: mimencode -b -u R0lGODlhowBWAPUAAHSm6Wyj5jggASsZAa/E/qy+8Ze49pO08SB8yRl4x4BKAH5IABB1xAhw wcPCwbq6ulKV3EqR2WNIJWI4AKurq6OjpKKhobGhjaO++p+575CQkIiJitDU/sbP/gkFAAAA AImx8Yuq3UKN1jqJ04ecuJeZnDKFzymAzGuTwHSBjHtGA285A7vK/rvE452dnXxGAIJ7cpd2 TR0QAHlDAHM9AJaWl9HP8cXI0EwsAGSe436r7ABsvbW2tlya34BaKoODgiwAAAAAowBWAEUG /sCdcEgsGo/IpHLJbDqf0KjyRD2ZrFdTlrrdWqvgcPj6PY146AfvwUa7eZuffE6foxBisnjP 74O7XVWBXGVjhlQQiYqLjBA9jY6Kj4mTkI05aW+ZbnF0nZ11oaEpKJamkI+VkqeRrKiKOhk8 JBQkJSS4KCEAOr2+v8DBwr4gw8a9xcg3DmoUFRYlGhsbuCTTothyoD8bKcXfIOHIOuLg5Ofi 5+rjyd/A7iAEzM41NdJzGAUYBBj7/fwEAPrjty+gQYM3HlCwYO+HBn8DIxL8h2GZAx4VKriw FyfDwIMgCbS46MyFNJAFQ6pcybKlSwI25mnkyG2DDQ44c+rcybMn/oeEzqL9qOGzKM5lzWbe a3HTKM6YPErW2OC0qtWrRn3I3HhPzgwaYL+CpTGjrNmzZcmmNUuDZIWGMNDOWLCARt26dtMu cDBP6j0fC9DWlXvhBhqN0wLLXTw3L+PFjgcHVqu4cVnJNGKQtMC1U9yzah+LNjuPYRwYlc2m nnt3Lt+knX8AVj3XrILACy5s1fBDgQq6rHHjDk63+IzbCo4bL15cgXPlzIFLZ65Ac1TONH/A SD689nDgl5eztrtXITTeqNmCncAeB44B8GXI8OCB78WMLkzGkcA+L93bczmngG5RacTbbQs4 F92CzSWInIAP/ucghArSsMJ78nkwwHEK/jpnnVTXaIcccdOJFx2CYq0wgXsCDJAhfR/EKCN9 9MkwgAAC4DCBRRQ481YNcvhA4ZBEFmnkkUg6h4MHMjbppJMDTNjgkFJS6OB/DyappZZI8XAB BVzx5sOKOL745JkxeiBfjuyVReSESMqA5pxoDqAAAwngqWeefO7pZ5+A/ikooCdoosYbh4IC Qwon6MnAo5BGKumklFY6KZ+Y4hnopn46CmmekYL6KQMilGrqqaimGkGqrLaKKgSHqiHroZxk Y+uiKLia6ggi8OrrCMAG2yuvvZ7qa6m//josscUeS+yzzfYawLTUBpCDtddma22123bL7bff AsDttQGggEuI/ramq24oG6AQLrfiBhAvuPTWa2+9BjDDgwUMdfXDAQAbIPDABBdssMHLlMTb DwaDQLDDCCeEkUbRxBHCAQcbPFKB+mXs8ccgf4wByB3I1C8oLKSs8sosd5Cyyyy4DPPKQFUg lAYyvxzzzh3kvHOXUk31A1M596xzzx3cYJjCGyBt9NMxOz1z0TtH/bLPRlcN89Yqb62VQkqB MtbYZJdtNtmbCQXD2WyDZR/HJQjtwwoWtk1DYRxLY/fYdO9d91h0B173CoL3zfbXC8XmFVlh qcX4aKCVVRpcq6lG1mD+vcbxRnEARpd/l4WuG9gm/fCdbd4pV9vqwpG3OooMEie7/nAfhi3H Z6OtVtl3dE1+mmKVz+4aX3D/BbxwtSU3w+g9lv7ccgxGLz2JsSdoPXPQLVA7554F6N3prJH4 PW7IqeDcb9gnqLpiCC6ggubOnCybglg2h9zo+5buIo0fMNl/jfBh0wTo5ib6hS8wEKIBnZxE AwrF4DDygwEO1iQA9hDOTQGijgatxEEsdciDRAIaZ/Qzvy2Z0EhguVCZ5uO/NPFvgXPyQANP SMMa2vCGOMwhhdZDpv3RSAZsskuRGkDEIhrxiEhMohKXWEQGoMBctDDUoRaFgB0w8YpYzKIW t8jFIyLgi2AMoxjHSMYymhGMJjBUGmgFB1HAAAYmOKMc/ud4xgQgIAF2xOMdxWjHL/YRjH/k ox/v2Mc8IkALJgBWIhc5gkQ2UpGQZOQjIflILTSSkYs0gQjWwEk2rkEN21iXCDI5SUySEpOV jGSwKonIS1oyk6dEJCxlSctaRuCWt1QELncJgV3yMpcR6GUwe0nMYRaTmLDipBva8Mk2riuU dCBFLhdhzGFW85e+FKYvt8nNbnrTlz3oQQ7EOc4cmLOc5xQnOc9pTnK6k53qLGc8xclMZr6h R9DERj5t1a54shMC7GwnOucZUHm2k6AHDadA32lQcwLgoRCNqEQnStGKWvSiEpWXDiJKAhQ4 I34lqNg+5ZCCOpS0Dt1IAQkw/sqLi240oi9tqUwfGlOaWhQEW6nYHMgRjp769KdADapQh0pU EACNYvcIQU8NAIIDADUEtniLC0SK0qUW9apYzWpFSJedH3ikHyMLqwHEStaxjrUfZu1HC8B2 M7CG1a1wdetRObOwEBTgq3F168Ywop+8+vWvgA2sYMEqD7DJTw4qYUFAFPuSkNRMKBtQLGMl SwDKUrayFimQgeLQAssaJGWVxexF8ncSxoZWZaetLGgly7LUsla1rGWZbGMLk80c9gdSyy0H dNuB3fa2Z779CVt5Q5XcGldqR41NCzpgg+M6bRlRAZM0nMtb4wb3t8DNrm+zi93dbve6iLOd HNrW/jfC8Y1w6O3bBNpiHrVZKL3wjS/d4Ge7MaXXbHQjkFR+wLf3/q2/KQRcCuVLg/UauMDr QfCBFYxgrXCsHnRo3FggB5nByERtcrmLY0CzF770qL5kW8tXRqzfzY74cShmnN9WzOKxhFdx P1DPWsIy4rQ4bsakARvlamw5vUSGvrGZTeVSwzwDmS7D7DvO6sYjneSFbnzpW9ABgfOh/HSV MTS+ceQWMw+uaKc1jPkc8IBMEyGDDjfkwZ+RufNk3jVZyciDHnAgJD3hSHl72cEdhZf8mNK4 4HdLbg2axdxh2JTZzW/OzVbiwB07O9rR1Jvz9aTHnfY5KHvacwv3bkcb/tapBnjhO+Bc3mce uCiv0+EpDnne5pfOSXks7ZkA8+hqOkvX+dYnQhByogchDilHQVVW3HbgzLvvNQZ6qfOBD2IQ A2WPab1uul4CyZMg+3z4LcZrkISao2bnUelKukaRhVaEgxbJh4UwopGa1N1CJ+EATtXR9FQ8 0+jgzE7OJYKOgCa9bUyDhyzWxk+Z6bzvLCFp0gV/E7x3nfAVwLBJHij4BdCQuHlzmoc5ig+6 z6RuF+HIPRaKNv32bb8Q6gs/OhWSDldupCU9/Ek4IPmRzEdyECacSiwf0lwHXsNxl9tFLHRS u2ekphvpiCwQGsDLY/jBpuf86Sa/iAWeYQ/e/sgpTfIx+nptDnUiDX3pZ8KBFMY+diI+ygoo SADZ1872tjfB7A1gQNznLve60/3uds873vcu90J90pOZ4AYMfnACvhte74g//N67yPgs4vHx kI+85CdP+cpDPo1siNUy3RCKwZ+AkHkMPSFHr8fSW/70qE+96iXPADz44fWwDwMeZl+FM2hi E5zc52muQPsvfn72wP/954ffe+IbP4zEB/4Yf798MR7f9VTwPRdqSf3qW//61N+kMm+fhpHS YVHUxwL2xw+IWmLhC1nQwvnTj371I3L97F+l/Oe/LGEpa/72T9YqIcD9NSZqXaGAAo6EfwRY gAZ4gAiYgPRXKrfE/oCr0oCrIgIPCIEMWIENCAEigIEYuCobyEuaRyts5H3cYCuk4CoRKIES GIHANIEpqCooeConeIK60ioyCAnGRE2WcIOugApsJCu4533QdFKjUAquEEw6aIOMcIRJuINI SAnh9IRPCFBQOIVUWIVQaFD+ZE7b93f+B4BeaAcKJU5SSE4AlQNSOE5haIVXqFAGVYbwtFDq FIdPWFB0WId2eId2iAvScA2Kkg3eJ4RzUFLb0AmkgC14eIiImIh3SC/i0oiOKC/UEi8PFYnT IomQKImNKC+OCFGRGALmsodfGIpzQA2aWFGaWIoUhYqbeIqPmImryIm8cAy+EIuyWIu2/ngM NOULmVUSOkVSJkWCKKVSxpAMt1iMt4hTzZAf0jB4P6BU4FAO6MBTPPWM09hT1ZhVQJVcNBEC 66ADULUBC+OFGwBU14hV5YiNPsVT+UI6vfgDTRUOAgNUTDVU8ziPDnMAGUACIbCPSsVU/hiP AwOPAilCU5VUF2MAToWQAXOPBrAxQSENABMOBwmQIVORIAMxEJMxfpYdG4AxFjkwI+MxQNEv 3FCRIRmSSPFhBckbdpUBIbNWeaMBBOMRAiNWH1kwZPVWZ6WTO5lWadUXJ9MJgzURAvFXEmMz 07ABgxVXR4VtccADEfFXDklXDxGVS0kREjERVwlYhRU/HNEJ/ithWo0FEo8lDRrwWS1xWSkZ NBYjlizhkAZylmO5WHQ5l2M5WXSZMiajAaD4A7P1l4ApW2XJDYEJmNp4DSEwWzOjMtCVOHy5 MotZmJGpM1XTNZZZmLJVMlwFik3jXFEjNZ8pM8g1XA5BXc61i0jFWaHpXHBpEjhTNMcVmttl mrRZm70lb11BFVXRW95VFYOpm1hxFB4WFDSxXEjTm7zpXUpzGBXjE8m5m8FpFM+pEzGxmaBg A9iZndq5nTeBnRzQnd8Znjfxm+JZnuB5nj8xnBQjNA7Ane5pA42JGDbxnvTpnuZ5n+iZn/jJ AQ7GlnNQNoITYAI2oP9VGhWzNgJa/jhk0zeaI3B/cV+FIzjMI1389V7mJV8YGl8WSmDm9V9k s15k82JXpmItdjYz4BYYVqILwCMlUTqyYThtQyB8xRtiUaI2eqMuthUNMQdsARp2U6MnJjmk cxpBOmF2caQ1tqLE06J/ERlfMRlnUWIboWcUBmaQo2FgNmhIuhatIaL+QmM8hmOhERpbNjno URkqdmx5QRnJxTmyEaaXsWFFthExVqXhIWqBNmXGdkCug2wLgDjY4S9wSqZj2qNweqKldqZk yqWgQx7a+BdPKhhyuhtHtqd85mSiNh0AgjzHFmpMFh1zoRnWyaN7pmV9lqhyMBhhBjpz8aiu djlIZhdF/mYBvHE6TdYdCIRAqRNloGZsJSI9eCaojyNikbpho+FnZ5o6bUYZl6GNcmNnygoc c3ogcTYdrKOrAJIcm5o+p3arj/YddhGs3bNn5NplHJEeobM7ntaq+uKfQpYa4jGhdKo83ko9 9oYi9XZr2vqr2cMaHxKonhE8iyGwcmGmGxAXx2Nvd2FnzupqiTY+cwoktvZokcZrNWex2Uod lvavXnY76ioYZwEeodYdZqodmcocR8ocKrCW9cWr2DMg+nIeG5Cr34prGMtvJ4JAunZpt8Gx eZanu3qnguarJTtsEytlxdGwGyABL6Ju5wZEAuACu7EBusYhNssgO9s++ypt/ttWJAmCZyGC O6A2tsRxZsRRtOxWI+cmQDgQFiyqESTkA8Qxsc6hX2AisTw7ctYTbvB2JdZTFoRDJgLQtF/3 ARyyr9YhcGE7ttXauCcbIL5hPt+xrfbjt0rqACrJcznrt9PaG/QzYCwyuOiWbv9DQe7RoeQj AIUrdDKXuAB7O9vqq3IGZb+WPCpwu+0DudJGZwmCmk65ASpHcAQXAx9mGjBgIzmCAx36IJDb aDe3t3CyAFf3cAJAcq4rbI32qzU7ZbmqOrZmY+yBI/HxQh/wtmFSQnvbdTq0AKs7JxMAIQTy DNhbrWWbQjryc4TbPzPyP0WndSAKQhPiqiWkvjkHvSNgZ7gCcgFq4KCeEUMANADuMUBgQT4K N3IGlyQNO8AEvCWfo0Ki274LFHEdogBCEryRu2/h0XRT4kHp+yY21CXyy3NPtwAqgr9B5z9M 8nVqe8BPUr2WpiXgZiQLR8C7yC9facJ0VmDuAXQGDENqyyZ0oyUOx8NPsgIXLLxYvMEnhJqx oXQhDEA6snXfpkMTQMVocrhZrMUrt2wX0MYWcAEwwGxjIgForMZJMgFNDHZgPEB23Md+rMZD vCVBAAA7 --PART-BOUNDARY=.19701182044.ZM14629.reading.sgi.com-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 18 19:05:50 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id TAA12310; Sat, 18 Jan 1997 19:04:19 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id TAA12294; Sat, 18 Jan 1997 19:04:18 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id TAA15541; Sat, 18 Jan 1997 19:04:08 -0800 Received: from stealth.afit.af.mil (stealth.afit.af.mil [129.92.2.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA07401 for ; Sat, 18 Jan 1997 19:04:05 -0800 Received: from shark.afit.af.mil (jbush@shark.afit.af.mil [129.92.11.144]) by stealth.afit.af.mil (8.8.3/8.7.3) with ESMTP id WAA17523 for ; Sat, 18 Jan 1997 22:03:53 -0500 (EST) Received: (jbush@localhost) by shark.afit.af.mil (8.6.12/8.6.9) id WAA19336; Sat, 18 Jan 1997 22:03:54 -0500 Date: Sat, 18 Jan 1997 22:03:54 -0500 (EST) From: Jeff Bush X-Sender: jbush@shark To: Performer help Subject: HELP: Evaluating Performer for thesis topic. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hello, I am a grad student developing a 3D rendering application involving missile/aircraft engagement. There is current work done with Open Inventor but is too slow. I need to evaluate Performer as an alternative and would like some insight on a few things. If you can help me, please email me at jbush@afit.af.mil. Thank you. 1) Does it work well with Motif? I'll be using it for the UI. 2) Is there an easy interface for the user to change the viewing angle? (using mouse controls most likely) 3) The aircraft model (currently an Inventor .iv file) is broken up in sections (engine, skin, crew...) that need to have their visibility "toggled". Is there a way to turn a node's visibility off other than removing it from the scene graph heirarchy? 4) In order to turn the visibility on or off, I need to be able to identify these aircraft sections in the database. I understand there is a library function for loading Inventor files. Currently the Inventor file has the aircraft divided up with "SoLabel"s of each section that can be searched for in the Inventor tree, each section becomes an Inventor "child" object that can be manipulated seperatly. Can this be done in Performer? (I realize this might be a difficult question to answer without more info...) If I can't, my only solution would be to break up the .iv file into it's sections and load each seperatly, keeping track of them myself. I'd like to avoid this if possible. 5) The OpenInventor version had 4 viewing scenes, one main view and 3 smaller views showing top, front and side views, all rendering in sync. This was trivial in Inventor. Would this also be easy to do in Performer? (Create 4 "views" of the same scene) 6) Is there a Performer newsgroup yet? Thanks in advance. Any insight would be helpful. I'd actually like to get away from Inventor due to its slow performance. I am not subscrib5ed to this mail list any longer, so if you can answer any questions, please respond to: jbush@afit.af.mil. Capt Jeff Bush Graduate Student in Computer Science Air Force Institute of Technology jbush@afit.af.mil ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 19 06:35:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA12962; Sun, 19 Jan 1997 06:34:02 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA12946; Sun, 19 Jan 1997 06:34:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA01566; Sun, 19 Jan 1997 06:33:49 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA10288; Sun, 19 Jan 1997 06:33:47 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id OAA15355; Sun, 19 Jan 1997 14:33:36 GMT From: "Angus Dorbie" Message-Id: <9701191433.ZM15353@bitch.reading.sgi.com> Date: Sun, 19 Jan 1997 14:33:35 +0000 In-Reply-To: Jeff Bush "HELP: Evaluating Performer for thesis topic." (Jan 18, 10:03pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Jeff Bush , Performer help Subject: Re: HELP: Evaluating Performer for thesis topic. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 18, 10:03pm, Jeff Bush wrote: > Subject: HELP: Evaluating Performer for thesis topic. > > Hello, I am a grad student developing a 3D > rendering application involving missile/aircraft engagement. > There is current work done with Open Inventor but is too slow. > I need to evaluate Performer as an alternative and would like > some insight on a few things. If you can help me, please email > me at jbush@afit.af.mil. Thank you. > > 1) Does it work well with Motif? I'll be using it for the UI. > Yes you can have Performer rendering to a window insude a Motif GUI and there is example code, performer also has it's own GUI widgets which you may want to consider for simple interaction instead of Motif. > 2) Is there an easy interface for the user to change the > viewing angle? (using mouse controls most likely) You should understand that performer is primarily an API for writing applications. You can change the FOV from your application and the "perfly" example application allows the user to change the field of view using a slider on the GUI. > > 3) The aircraft model (currently an Inventor .iv file) is > broken up in sections (engine, skin, crew...) that need to have > their visibility "toggled". Is there a way to turn a node's > visibility off other than removing it from the scene graph > heirarchy? Yes, you can use node traversal masks to disable culling and rendering objects and in the scene very simply. You can even perform this on a a per channel basis. > > 4) In order to turn the visibility on or off, I need to be able > to identify these aircraft sections in the database. I > understand there is a library function for loading > Inventor files. Currently > the Inventor file has the aircraft divided up with "SoLabel"s of > each section that can be searched for in the Inventor tree, > each section becomes an Inventor "child" object that can be > manipulated seperatly. Can this be done in Performer? (I > realize this might be a difficult question to answer > without more info...) If I can't, my only solution would be to > break up the .iv file into it's sections and load each > seperatly, keeping track of them myself. I'd like to avoid > this if possible. pfFindNode is very usefull for finding named nodes in the scene graph. I think the Performer inventor loader names the nodes with the labels so it would be easy to identify the components you are interested in. I have used this in the past but I'm not sure which field was used in the inventor files I was reading. You could also perform your own traversal or use a traversal function to go through a loaded database and identify components using whatever other distinguising attributes they posessed. > > 5) The OpenInventor version had 4 viewing scenes, one main > view and 3 smaller views showing top, front and side views, all > rendering in sync. This was trivial in Inventor. Would this > also be easy to do in Performer? (Create 4 "views" of the same > scene) Yes, in Performer you have pfChannels which you create and give perspective or orthographic projections. You map these to areas of your application window by setting the viewport. You can use the same scene or different scenes in each of the viewports and your traversal masks (see 3 above) can selectively turn objects in the scene off on a per channel basis. You can also selectively disable rendering to the channels. When you call pfFrame in your application loop all of the channels you have created will be drawn, quickly :-). > > 6) Is there a Performer newsgroup yet? Nope just this list. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sun Jan 19 23:46:19 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id XAA14120; Sun, 19 Jan 1997 23:45:07 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id XAA14104; Sun, 19 Jan 1997 23:45:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA25056; Sun, 19 Jan 1997 23:44:56 -0800 Received: from alf.mandator.se (mandator.se [195.84.33.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id XAA26355 for ; Sun, 19 Jan 1997 23:44:45 -0800 From: ulf.yngwe@mandator.se Received: by alf.mandator.se; id AA02152; Mon, 20 Jan 97 08:46:26 +0100 Received: from mail.mandator.se(192.168.140.10) by alf.mandator.se via smap (3.2) id xma002150; Mon, 20 Jan 97 08:46:04 +0100 Received: by mail.mandator.se(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id C1256425.002A2EE9 ; Mon, 20 Jan 1997 08:40:45 +0200 X-Lotus-Fromdomain: MANDATOR To: info-performer@sgi.com Message-Id: Date: Mon, 20 Jan 1997 08:41:36 +0200 Subject: pfPipeWindows and OpenGL Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Status: O Ulf Yngwe 97-01-20 08:41 Hi! Shouldn=B4t this work on an O2 with Performer 2.0 or have I misunderstood something. I always get a BadMatch error on the glXMakeCurrent call. pfInit(); pfConfig(); p =3D pfGetPipe(0); pw =3D pfNewPWin(p); pfPWinType(pw, PFPWIN_TYPE_X); pfPWinName(pw, "IRIS Performer"); pfPWinOriginSize(pw, 0, 0, 500, 500); pfOpenPWin(pw); dpy=3DpfGetCurWSConnection(); win=3DpfGetPWinWSWindow(pw); wincxt=3DpfGetPWinGLCxt(pw); glXMakeCurrent(dpy,win,wincxt); = ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 01:49:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA14310; Mon, 20 Jan 1997 01:48:48 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA14294; Mon, 20 Jan 1997 01:48:48 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA29923; Mon, 20 Jan 1997 01:48:37 -0800 Received: from avalon.manchester.sgi.com ([144.253.96.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA10049 for ; Mon, 20 Jan 1997 01:48:30 -0800 Received: by avalon.manchester.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer@sgi.com id JAA26225; Mon, 20 Jan 1997 09:29:25 GMT From: "Chris Thornborrow" Message-Id: <9701200929.ZM26223@avalon.manchester.sgi.com> Date: Mon, 20 Jan 1997 09:29:25 +0000 In-Reply-To: Martin Reddy "Re: Underwater effects" (Jan 16, 10:09am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Performer List Subject: Re: Underwater effects Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O OK I'll get laughed off the list for refering to a game but have a look at Tomb Raider. As near as I can work out, the effects for underwater are as follows: 1) Semi-transparent flat polygon on surface, texture mapped with ripples. Texture map for ripples is time based and animates. 2) All surfaces under the water (besides being texture mapped nicely) appear to be broken into regular grids. The corners of said grids have a material applied which varies with time. The brightness of the material application seems to be a sinusoidal time variable. Each corner starts at a different brightness of course. This is gouraud shaded and combined with the texture map. All material colours are blue-green compared to surfaces outside the water. 3) 3-4 polygons are used to give bubble effects off any moving object by using transparent textures. 4) Sound underwater is deadened (except atmospheric music). This is incredibly effective and is perhaps the single biggest contributing factor. 5) Geometry close to the surface is lighter in colour. There are other things such as moving through the water requires you to press direction and power buttons (not just direction) which makes you feel like its an effort to move through it ! However, these are probably less relevant. Chris. -- ------------------------------------------------------------------------------- |Chris Thornborrow email : chris@manchester.sgi.com | |Silicon Graphics tel : +44 161 877 8801 ext 1309 | | | |Home Page URL : http://reality.sgi.com/chris_manchester/ | |Arthurian URL : http://reality.sgi.com/chris_manchester/arthur.html | ------------------------------------------------------------------------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 01:57:15 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA14337; Mon, 20 Jan 1997 01:56:25 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA14321; Mon, 20 Jan 1997 01:56:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA00014; Mon, 20 Jan 1997 01:56:13 -0800 Received: from swissonline.ch (www-sol2.swissonline.ch [194.209.12.19]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA10720; Mon, 20 Jan 1997 01:56:04 -0800 Received: from vt-pc2 by swissonline.ch (SMI-8.6/SMI-SVR4(19961218-sol)) id KAA05255; Mon, 20 Jan 1997 10:55:02 +0100 Message-Id: <199701200955.KAA05255@swissonline.ch> From: "Vector Technologies" To: Cc: Subject: Re: Texture detail and zbuffer on Impact Date: Mon, 20 Jan 1997 10:51:09 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: O We have upgraded a High Impact to 4M TRAM. The maximum texel depth is always 16 bits, that means 4bits per channel RGBA. With 16 levels per channel, the dithering process under certain circumstances (e.g. cloudy sky) even gives false colors. The patches 1447 and 1574 (under Irix 6.2) do not modify the behaviour. In the manual (paragraph 1.4, Indigo IMPACT Graphics) however 4M TRAM should come with 48 bits texel depth. We inputted these results last year to Mountain View, we have no feed-back up to now. Will this bug be fixed, or do we have to live on an Impact with these poor texel depth definitions? Cheers. Alexander Knob. ****************************************** VECTOR TECHNOLOGIES SA 7, ch de la Venoge CH - 1025 St-SULPICE Switzerland tel: +41 21 691 42 43 fax: +41 21 691 42 40 eml: vectortc@swissonline.ch Explore with us the 3rd dimension ! ****************************************** ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 02:52:07 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA14535; Mon, 20 Jan 1997 02:50:38 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA14519; Mon, 20 Jan 1997 02:50:37 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA01576; Mon, 20 Jan 1997 02:50:26 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA17547; Mon, 20 Jan 1997 02:50:19 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id KAA16406; Mon, 20 Jan 1997 10:50:15 GMT From: "Angus Dorbie" Message-Id: <9701201050.ZM16404@bitch.reading.sgi.com> Date: Mon, 20 Jan 1997 10:50:15 +0000 In-Reply-To: "Vector Technologies" "Re: Texture detail and zbuffer on Impact" (Jan 20, 10:51am) References: <199701200955.KAA05255@swissonline.ch> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Vector Technologies" , Subject: Re: Texture detail and zbuffer on Impact Cc: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Are you relying on Performer to create your textures? Try explicitly requesting a texture format with 8 bits per component. This works on IMPACT with 4Mb TRAM so it sounds like your problems are due to your software/database loader. You go on to mention dithering, is this what you mean? Textures don't dither, although they will to quantize when you use fewer bits per texture component. You get dithering in your shading if you have a visual which doesn't have 8 bits per component. Have you mixed your terminology or are you talking about two distinct problems? Can you run a demo like "distort" to see if you have a problem with 8 bits per component texturing? It should be pretty obvious if it uses 4 bits per component and this would indicate a problem specific to your system. Cheers, Angus. On Jan 20, 10:51am, Vector Technologies wrote: > Subject: Re: Texture detail and zbuffer on Impact > We have upgraded a High Impact to 4M TRAM. The maximum texel depth is > always 16 bits, that means 4bits per channel RGBA. With 16 levels per > channel, the dithering process under certain circumstances (e.g. cloudy > sky) even gives false colors. The patches 1447 and 1574 (under Irix 6.2) do > not modify the behaviour. In the manual (paragraph 1.4, Indigo IMPACT > Graphics) however 4M TRAM should come with 48 bits texel depth. > We inputted these results last year to Mountain View, we have no feed-back > up to now. > Will this bug be fixed, or do we have to live on an Impact with these poor > texel depth definitions? > Cheers. > Alexander Knob. > ****************************************** > VECTOR TECHNOLOGIES SA > 7, ch de la Venoge > CH - 1025 St-SULPICE > Switzerland > tel: +41 21 691 42 43 > fax: +41 21 691 42 40 > eml: vectortc@swissonline.ch > > Explore with us the 3rd dimension ! > ****************************************** > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Vector Technologies ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 05:55:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA14775; Mon, 20 Jan 1997 05:54:32 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA14759; Mon, 20 Jan 1997 05:54:31 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA07294; Mon, 20 Jan 1997 05:54:20 -0800 Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA09371 for ; Mon, 20 Jan 1997 05:54:06 -0800 From: inca@public.bta.net.cn Received: (from inca@localhost) by public.bta.net.cn (8.6.8.1/8.6.9) id VAA16879; Mon, 20 Jan 1997 21:54:01 +0800 Date: Mon, 20 Jan 1997 21:54:01 +0800 Message-Id: <199701201354.VAA16879@public.bta.net.cn> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: pfPipeWindows and OpenGL To: info-performer@sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Hi, -- Ulf Yngwe 97-01-20 08:41 wrote: > pfInit(); _try_ pfMultiprocess(PFMP_APPCULLDRAW); ^^^ > pfConfig(); > > p = pfGetPipe(0); > pw = pfNewPWin(p); > pfPWinType(pw, PFPWIN_TYPE_X); > pfPWinName(pw, "IRIS Performer"); > pfPWinOriginSize(pw, 0, 0, 500, 500); > pfOpenPWin(pw); > > dpy=pfGetCurWSConnection(); > win=pfGetPWinWSWindow(pw); _try_ fprintf(stderr,"win is 0x%x\n",win); ^^^ is it zero or some number? then move win=pfGetPWinWSWindow(pw); and fprintf(stderr,"win is 0x%x\n",win); to pfOpenPWin(), try PFMP_APPCULLDRAW, PFMP_APP_CULLDRAW. > wincxt=pfGetPWinGLCxt(pw); > > glXMakeCurrent(dpy,win,wincxt); /* if win is zero, fault */ key problem is pfGetPWinWSWindow don't work in APP process when multiprocess case. man page say it works, but it don't. Hope this helps. liubin ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 06:25:44 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA14882; Mon, 20 Jan 1997 06:24:40 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA14866; Mon, 20 Jan 1997 06:24:40 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA08500; Mon, 20 Jan 1997 06:24:28 -0800 Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA13236 for ; Mon, 20 Jan 1997 06:24:19 -0800 From: inca@public.bta.net.cn Received: (from inca@localhost) by public.bta.net.cn (8.6.8.1/8.6.9) id WAA17985; Mon, 20 Jan 1997 22:24:12 +0800 Date: Mon, 20 Jan 1997 22:24:12 +0800 Message-Id: <199701201424.WAA17985@public.bta.net.cn> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: pfPipeWindows and OpenGL To: info-performer@sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Hi, sorry i make a mistake in last mail, please discard it. -- Ulf Yngwe 97-01-20 08:41 wrote: > pfInit(); _try_ pfMultiprocess(PFMP_APPCULLDRAW); ^^^ > pfConfig(); > > p = pfGetPipe(0); > pw = pfNewPWin(p); > pfPWinType(pw, PFPWIN_TYPE_X); > pfPWinName(pw, "IRIS Performer"); > pfPWinOriginSize(pw, 0, 0, 500, 500); > pfOpenPWin(pw); in multiprocess case, use: pfPWinConfigFunc(pw,OpenPipeWindow); and pfConfigPWin(pw); you can do pfOpenPWin() in function OpenPipeWindow. > > dpy=pfGetCurWSConnection(); > win=pfGetPWinWSWindow(pw); _try_ fprintf(stderr,"win is 0x%x\n",win); ^^^ is it zero or some number? then move win=pfGetPWinWSWindow(pw); and fprintf(stderr,"win is 0x%x\n",win); to OpenPipeWindow(), try PFMP_APPCULLDRAW, PFMP_APP_CULLDRAW. > wincxt=pfGetPWinGLCxt(pw); > > glXMakeCurrent(dpy,win,wincxt); /* if win is zero, fault */ key problem is pfGetPWinWSWindow doesn't work in APP process when multiprocess case. man page say it works, but it doesn't. it works in DRAW process. Hope this helps. liubin ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 08:00:08 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA15182; Mon, 20 Jan 1997 07:59:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA15166; Mon, 20 Jan 1997 07:59:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA11665; Mon, 20 Jan 1997 07:59:06 -0800 Received: from despair.paradigmsim.com (despair.paradigmsim.com [206.7.114.164]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA26771 for ; Mon, 20 Jan 1997 07:58:58 -0800 Received: (from angus@localhost) by despair.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA16387; Mon, 20 Jan 1997 09:57:41 -0600 From: "Angus W.S. Henderson" Message-Id: <9701200957.ZM16385@despair.paradigmsim.com> Date: Mon, 20 Jan 1997 09:57:40 -0600 In-Reply-To: "DreamTeam Ltd." "Re: Underwater effects" (Jan 19, 11:39am) References: <9701161415.ZM1823@despair.paradigmsim.com> <32E27873.2D14@netvision.net.il> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "DreamTeam Ltd." Subject: Re: Underwater effects Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > > The best water effects I have seen in a long time - Nintendo !!!! > Why don't they supply the code when you buy the game ?! > > Roni Kass > V.P. Research & Development > DreamTeam Ltd. >-- End of excerpt from DreamTeam Ltd. The thing about graphics is you can guess how they are done just by looking. The dynamic water surface looks like it has a shiny blue/green environment map, with 50% transparency I can't be sure of course but it looks like they use point sampled minification. That makes all these flickering artifacts in the distance that actually makes the water look more active. It's more of a swimming pool water surface than the sea of course. ANgus ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 07:54:52 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA15155; Mon, 20 Jan 1997 07:53:45 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA15139; Mon, 20 Jan 1997 07:53:44 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA11556; Mon, 20 Jan 1997 07:53:33 -0800 Received: from swissonline.ch (www-sol2.swissonline.ch [194.209.12.19]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA25968; Mon, 20 Jan 1997 07:53:28 -0800 Received: from vt-pc2 by swissonline.ch (SMI-8.6/SMI-SVR4(19961218-sol)) id QAA21089; Mon, 20 Jan 1997 16:52:25 +0100 Message-Id: <199701201552.QAA21089@swissonline.ch> From: "Vector Technologies" To: Cc: Subject: HW-texture representation on Impact Date: Mon, 20 Jan 1997 16:49:15 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: O Angus: we are creating textured polygons with MultiGen. The loader cannot be the problem since on an IR (with RM-6) the texel depth representation is fine. For our test, we created a rectangle textured with R=G=const. and B decreasing from 255 (left) to 0 (right). The texture on the Impact is clearly quantified (not dithered, sorry!) with 16 levels. The demo "distort" with the dog gives a uniform brown color. Ciao. Alexander. ****************************************** VECTOR TECHNOLOGIES SA 7, ch de la Venoge CH - 1025 St-SULPICE Switzerland tel: +41 21 691 42 43 fax: +41 21 691 42 40 eml: vectortc@swissonline.ch Explore with us the 3rd dimension ! ****************************************** ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 08:49:14 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA15351; Mon, 20 Jan 1997 08:48:03 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA15335; Mon, 20 Jan 1997 08:48:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA13698; Mon, 20 Jan 1997 08:47:52 -0800 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA04682 for ; Mon, 20 Jan 1997 08:47:48 -0800 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbzih03057; Mon, 20 Jan 1997 11:47:46 -0500 (EST) Received: from ds9.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 20 Jan 1997 11:47:46 -0500 Received: from cavalier.cambridge.com by cambridge.com (4.1/SMI-4.1-SWS) id AA02007; Mon, 20 Jan 97 10:46:19 EST Received: by cavalier.cambridge.com (940816.SGI.8.6.9/SMI-4.1-SWS) id PAA14343; Mon, 20 Jan 1997 15:46:18 GMT From: rock.csd.sgi.com!sgi.com!uunet.uu.net!ds9!cavalier!gan (Gan Wang) Message-Id: <9701201046.ZM14341@cavalier> Date: Mon, 20 Jan 1997 10:46:15 -0500 In-Reply-To: "Edward Peters" "intersection testing and pfTerrain" (Jan 17, 3:52pm) References: <9701171552.ZM10975@hoback.ncsa.uiuc.edu> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Edward Peters" , uunet.uu.net!uunet!sgi.com!info-performer Subject: Re: intersection testing and pfTerrain Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 17, 3:52pm, Edward Peters wrote: > Subject: intersection testing and pfTerrain > I have a Geode which is a morphset of a pfTerrain node. I set up a segset and > hits as follows: > > pfSegSet segset; > pfHit **hits[32]; > > segset.isectMask = 0x01; > segset.discFunc = NULL; > segset.bound = NULL; > segset.mode = PFTRAV_IS_PRIM; > > segset.segs[0].pos.set ((float)x, (float)y, 500.0f); > segset.segs[0].dir.set (0.0f, 0.0f, -1.0f); > segset.segs[0].length = 1000; > segset.activeMask = 1; > > Then I do the following (my geode is pfGeode *ground): > > int isect = ground->isect(&segset, hits); > > if (isect) { > // intersection, do something > } > > else { > // you missed, do something else > } > > It fails every time (ie no intersections). I had a similar experience. A way to get around it is to set the appropriate nodeTravMask everytime before isect() call is made. The default node/gset mask does not work for some reason. This may be a Performer bug with morph gset. > Earlier I had some code (almost > identical) which would fail sometimes, and work other times. > > Does the app and cull processing of the pfTerrain node use intersection testing > to determine what's visible and what's not? If so, would it require a reset of > the TravMask every frame for other intersection testing to work? I ask because > part of the enigma seems to be where my intersections are placed relative to > the call to pfFrame(). > > Thanks in advance for your help. > > > Ed Peters > elpeters@ncsa.uiuc.edu > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Edward Peters -- Gan Wang Cambridge Research Associates Voice: 703-790-0505 ext.7210 1430 Spring Hill Road, Suite 200 Fax: 703-790-0370 McLean, VA 22102 E-mail: gan@cambridge.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 09:22:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA15512; Mon, 20 Jan 1997 09:21:02 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA15496; Mon, 20 Jan 1997 09:21:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA15125; Mon, 20 Jan 1997 09:20:50 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10124; Mon, 20 Jan 1997 09:20:43 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA17006; Mon, 20 Jan 1997 17:20:37 GMT From: "Angus Dorbie" Message-Id: <9701201720.ZM17004@bitch.reading.sgi.com> Date: Mon, 20 Jan 1997 17:20:37 +0000 In-Reply-To: "Vector Technologies" "HW-texture representation on Impact" (Jan 20, 4:49pm) References: <199701201552.QAA21089@swissonline.ch> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Vector Technologies" , Subject: Re: HW-texture representation on Impact Cc: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 20, 4:49pm, Vector Technologies wrote: > Subject: HW-texture representation on Impact > Angus: > we are creating textured polygons with MultiGen. The loader cannot be the > problem since on an IR (with RM-6) the texel depth representation is fine. > For our test, we created a rectangle textured with R=G=const. and B > decreasing from 255 (left) to 0 (right). The texture on the Impact is > clearly quantified (not dithered, sorry!) with 16 levels. > The demo "distort" with the dog gives a uniform brown color. The iR supports different texture formats, ie 5,5,5 bits RGB instead of 4,4,4 rgb so it'd look a _lot_ better than IMPACT. Performer will also default to a different internal format. What you have to do is get the texture on the MultiGen palette and press "=", then edit the internal format flag to be RGB 8,8,8 (or whatever the token reads this will create an attributes file which tells the flight loader to use more bits per texel. Next time you load the database you should see the improved texture format being used. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 09:36:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA15573; Mon, 20 Jan 1997 09:35:52 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA15557; Mon, 20 Jan 1997 09:35:51 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA15863; Mon, 20 Jan 1997 09:35:36 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12485 for ; Mon, 20 Jan 1997 09:35:35 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id JAA15857; Mon, 20 Jan 1997 09:35:34 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id JAA25132; Mon, 20 Jan 1997 09:35:44 -0800 From: "Rob Jenkins" Message-Id: <9701200935.ZM25130@quid.csd.sgi.com> Date: Mon, 20 Jan 1997 09:35:44 -0800 In-Reply-To: "Vector Technologies" "Re: Texture detail and zbuffer on Impact" (Jan 20, 10:51am) References: <199701200955.KAA05255@swissonline.ch> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Vector Technologies" , Subject: Re: Texture detail and zbuffer on Impact Cc: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O With 4M TRAM you can indeed have > 4bits/component textures. In summary, the following are the supported texture formats on different TRAM configurations. BITS/COMPONENT 4 4 4 4 8 8 8 8 12 12 12 12 COMPONENTS 1 2 3 4 1 2 3 4 1 2 3 4 1 TRAM Y Y Y Y Y Y N N N N N N 4 TRAM Y Y Y Y Y Y Y Y Y Y Y Y If you are seeing banding on all textured applications I suppose you could have bad TRAM - does /usr/gfx/gfxinfo actually see 4M TRAM ? If the dithering is only on certian texturing applications only then perhaps you need to change the internal texture format ( pfTexture::setFormat in Performer). When you say 'inputted these results last year to Mountain View' do you mean you logged a support call ? If so please let email me the reference number and I'll follow it up. If not, then maybe you could log one ( mail me the ref too ). Cheers Rob On Jan 20, 10:51am, Vector Technologies wrote: > Subject: Re: Texture detail and zbuffer on Impact > We have upgraded a High Impact to 4M TRAM. The maximum texel depth is > always 16 bits, that means 4bits per channel RGBA. With 16 levels per > channel, the dithering process under certain circumstances (e.g. cloudy > sky) even gives false colors. The patches 1447 and 1574 (under Irix 6.2) do > not modify the behaviour. In the manual (paragraph 1.4, Indigo IMPACT > Graphics) however 4M TRAM should come with 48 bits texel depth. > We inputted these results last year to Mountain View, we have no feed-back > up to now. > Will this bug be fixed, or do we have to live on an Impact with these poor > texel depth definitions? > Cheers. > Alexander Knob. > ****************************************** > VECTOR TECHNOLOGIES SA > 7, ch de la Venoge > CH - 1025 St-SULPICE > Switzerland > tel: +41 21 691 42 43 > fax: +41 21 691 42 40 > eml: vectortc@swissonline.ch > > Explore with us the 3rd dimension ! > ****************************************** > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Vector Technologies -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 09:58:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA15677; Mon, 20 Jan 1997 09:57:49 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA15661; Mon, 20 Jan 1997 09:57:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA16759; Mon, 20 Jan 1997 09:57:38 -0800 Received: from cluny.ensam.fr (pictel.cluny.ensam.fr [193.50.253.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA16277 for ; Mon, 20 Jan 1997 09:57:34 -0800 From: pere1@cluny.ensam.fr Received: from VIDEO3 by cluny.ensam.fr (SMI-8.6/SMI-SVR4) id SAA28859; Mon, 20 Jan 1997 18:58:21 GMT Received: by VIDEO3 (940816.SGI.8.6.9/930416.SGI) id GAA15431; Wed, 8 Jan 1997 06:15:56 GMT Message-Id: <9701080615.ZM15429@unknown.zmail.host> Date: Wed, 8 Jan 1997 06:15:56 +0000 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com Subject: Shadow and projected texture Cc: PERE@cluny.ensam.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Like Scott McMillan and Mark Baranowski, I try to make shadows with Performer 2.1 and Irix 6.2. Remi ARNAUD says: > OpenGL shadows are not supported by Performer 2.x, but the OpenGL shadow > extensions are in the patch 1355 for 6.2. Is this the solution ? if, it is, ok I will install this patch. Another problem exists with pfLightSource and PROJTEX . I would like to use more than one pfLightSource, the documentation says > PROJTEX lighting requires that a pfTexture be specified with the > PFLS_PROJ_TEX token to pfLSourceAttr. obj should be an intensity-alpha > (2-component) pfTexture* with identical intensity and alpha components. > If lsource is the only pfLightSource in the scene using PROJTEX lighting, > the texture may be a full-color, 4-component texture. I tried this with 2 projected texture, but the result was that the scene is saturated even if I set PFLS_INTENSITY token to normalize lighting . In fact, my second texture seems invisible. Help !!! Please If somebody have an idea, I have some but not always clever. Thanks PS: You could see my application on IMAGINA next February in Monaco. You could not miss it... See you there -- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 10:21:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA15817; Mon, 20 Jan 1997 10:19:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA15801; Mon, 20 Jan 1997 10:19:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA17760; Mon, 20 Jan 1997 10:19:42 -0800 Received: from bur.visidyne.com (netsafe-outer.bur.visidyne.com [204.180.72.4]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA19967; Mon, 20 Jan 1997 10:19:28 -0800 Received: from spock.hsv.visidyne.com (spock.hsv.visidyne.com [207.60.194.10]) by bur.visidyne.com (8.6.11/8.6.6) with SMTP id NAA10590; Mon, 20 Jan 1997 13:34:23 -0500 Organization: Visidyne Inc. Message-Id: <2.2.32.19970120182147.006ecb34@mail.bur.visidyne.com> X-Sender: sartor@mail.bur.visidyne.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 1997 12:21:47 -0600 To: "Angus Dorbie" From: ken sartor Subject: Re: Scene Density Requirements Cc: info-performer@sgi.com Status: O At 06:54 PM 1/15/97 +0000, Angus Dorbie wrote: >On Jan 15, 10:22am, Timothy Moore wrote: snip... >> color and Z buffers if the depth test succeeds. So, you may get a >> measurably better fill rate if you render polygons front to back, > >I very much doubt this would be worthwhile on RE2 or iR systems >unless you manage to occlude some transparency, but anything is worth >a try I suppose. Is this really true? I thought that rendering front to back (on either an iR or a RE2) would be significantly faster than vice versa. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 10:26:27 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA15859; Mon, 20 Jan 1997 10:25:37 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA15843; Mon, 20 Jan 1997 10:25:37 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA18051; Mon, 20 Jan 1997 10:25:26 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA20974; Mon, 20 Jan 1997 10:25:23 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA17224; Mon, 20 Jan 1997 18:25:20 GMT From: "Angus Dorbie" Message-Id: <9701201825.ZM17222@bitch.reading.sgi.com> Date: Mon, 20 Jan 1997 18:25:19 +0000 In-Reply-To: pere1@cluny.ensam.fr "Shadow and projected texture" (Jan 8, 6:15am) References: <9701080615.ZM15429@unknown.zmail.host> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: pere1@cluny.ensam.fr, info-performer@sgi.com Subject: Re: Shadow and projected texture Cc: PERE@cluny.ensam.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 8, 6:15am, pere1@cluny.ensam.fr wrote: > Subject: Shadow and projected texture > Like Scott McMillan and Mark Baranowski, I try to make shadows with > Performer 2.1 and Irix 6.2. > > Remi ARNAUD says: > > OpenGL shadows are not supported by Performer 2.x, but the OpenGL shadow > > extensions are in the patch 1355 for 6.2. > > Is this the solution ? if, it is, ok I will install this patch. Well what Remi has just said means that 1355 is essential but even with it it's not a solution: "OpenGL shadows are not supported by Performer 2.x" Compile for IrisGL and perhaps this will support the shadows via IrisGL and IGLOO. Failing this you'll have to hand code the OpenGL shadows multi-pass. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 10:35:53 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA15947; Mon, 20 Jan 1997 10:35:03 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA15931; Mon, 20 Jan 1997 10:35:02 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA18527; Mon, 20 Jan 1997 10:34:50 -0800 Received: from bur.visidyne.com (netsafe-outer.bur.visidyne.com [204.180.72.4]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22604 for ; Mon, 20 Jan 1997 10:34:48 -0800 Received: from spock.hsv.visidyne.com (spock.hsv.visidyne.com [207.60.194.10]) by bur.visidyne.com (8.6.11/8.6.6) with SMTP id NAA10642 for ; Mon, 20 Jan 1997 13:49:45 -0500 Organization: Visidyne Inc. Message-Id: <2.2.32.19970120183708.006b34c4@mail.bur.visidyne.com> X-Sender: sartor@mail.bur.visidyne.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 1997 12:37:08 -0600 To: info-performer@sgi.com From: ken sartor Subject: Re: AN interesting comment. Status: O At 04:55 PM 1/17/97 +0100, Andreas Simon wrote: >Steve Baker wrote: > >> > There is another effect of double framing however. A motion that is >> > double framed seems to move faster than one that is single framed, > Is this 'feature' being discussed not exactly the same as using a 30 Hz screen refresh rate screen that is single framed? ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 10:33:54 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA15907; Mon, 20 Jan 1997 10:32:41 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA15891; Mon, 20 Jan 1997 10:32:40 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA18380; Mon, 20 Jan 1997 10:32:29 -0800 Received: from gauntlet.ht.com (he.ht.com [207.22.119.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22322 for ; Mon, 20 Jan 1997 10:32:20 -0800 Received: by gauntlet.ht.com; id BAA02535; Wed, 22 Jan 1997 01:06:09 -0500 (EST) Received: from unknown(10.0.100.2) by gauntlet.ht.com via smap (3.2) id xma002530; Wed, 22 Jan 97 01:05:59 -0500 Received: from hf.ht.com by ht.com (950413.SGI.8.6.12/3.1.090690-High Techsplanations) id SAA20126; Mon, 20 Jan 1997 18:31:07 GMT Received: by hf.ht.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer@sgi.com id NAA02037; Mon, 20 Jan 1997 13:31:02 -0500 From: scott@ht.com (Scott McMillan) Message-Id: <199701201831.NAA02037@hf.ht.com> Subject: Re: 2.1 vs 2.0 for Max Impacts To: info-performer@sgi.com Date: Mon, 20 Jan 1997 13:31:02 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Status: O Excuse the delay (I have been out of the office), but I am really interested in some clarification on which Impacts Performer 2.1 can/should be installed. The following comment has me curious: > From guest@holodeck.csd.sgi.com Wed Jan 15 04:42:20 1997 > Message-Id: <9701150430.AA25478@gdi4.gdi.net> > From: pratts@gdi4.gdi.net (Shirley Pratt) > X-Mailer: SCO System V Mail (version 3.2) > To: info-performer@sgi.com > Subject: Re: 2.1 vs 2.0 for Max Impacts > Date: Tue, 14 Jan 97 23:30:21 EST > > >From: "Howard Larson" > >Date: Tue, 14 Jan 1997 19:28:41 -0800 > >To: pratts@gdi4.gdi.net (Shirley Pratt) > >Subject: Re: 2.1 vs 2.0 for Max Impacts > > ... > > > >Performer 2.0 came out Dec 95, > > > >you should use Performer 2.1 > > if you do NOT have a R4400 in your Indigo 2 Max Impacts What is particularly wrong with installing 2.1 on a machine with R4400's? -- Scott McMillan | HT Medical, Inc. | Developing virtual environ- scott@ht.com | http://www.ht.com | ment medical and surgical Ph: 301-984-3706 | 6001 Montrose Rd., Ste. 902 | simulations and surgery Fax: 301-984-2104 | Rockville, MD 20852 | simulation creation tools. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 11:11:50 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA16288; Mon, 20 Jan 1997 11:10:41 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA16272; Mon, 20 Jan 1997 11:10:40 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA20125; Mon, 20 Jan 1997 11:10:29 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28644; Mon, 20 Jan 1997 11:10:26 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id TAA17329; Mon, 20 Jan 1997 19:10:22 GMT From: "Angus Dorbie" Message-Id: <9701201910.ZM17327@bitch.reading.sgi.com> Date: Mon, 20 Jan 1997 19:10:21 +0000 In-Reply-To: ken sartor "Re: AN interesting comment." (Jan 20, 12:37pm) References: <2.2.32.19970120183708.006b34c4@mail.bur.visidyne.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: ken sartor , info-performer@sgi.com Subject: Re: AN interesting comment. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 20, 12:37pm, ken sartor wrote: > Subject: Re: AN interesting comment. > At 04:55 PM 1/17/97 +0100, Andreas Simon wrote: > >Steve Baker wrote: > > > >> > There is another effect of double framing however. A motion that is > >> > double framed seems to move faster than one that is single framed, > > > > Is this 'feature' being discussed not exactly the same as using a > 30 Hz screen refresh rate screen that is single framed? > Sounds like the answer to this question requires much research, would wall clock time appear faster if you ran double framed at 120Hz? And what's the effect of motion blur on this effect, presumably the cell animators wouldn't draw this so perhaps the whole issue relates back to the incredible observer excitement induced by temporal aliasing? Incase you haven't see this: http://www.sgi.com/grafica/light/index.html I thought I posted this but I didn't get it back so it may just have gone to one individual. Like I indicated the last time I sent this, it's during discussions of subjective effects that I like to remind myself of this description. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 17:44:29 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA17019; Mon, 20 Jan 1997 17:43:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA17003; Mon, 20 Jan 1997 17:43:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA07135; Mon, 20 Jan 1997 17:43:06 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02158 for ; Mon, 20 Jan 1997 17:43:05 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA05363; Mon, 20 Jan 1997 20:41:57 -0500 Date: Mon, 20 Jan 1997 20:41:57 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701202041.ZM5362@hotsauce.clubfed.sgi.com> In-Reply-To: "Angus Dorbie" "Re: Shadow and projected texture" (Jan 20, 6:25pm) References: <9701080615.ZM15429@unknown.zmail.host> <9701201825.ZM17222@bitch.reading.sgi.com> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Angus Dorbie" , pere1@cluny.ensam.fr, info-performer@sgi.com Subject: Re: Shadow and projected texture Cc: PERE@cluny.ensam.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 20, 6:25pm, Angus Dorbie wrote: > Subject: Re: Shadow and projected texture > On Jan 8, 6:15am, pere1@cluny.ensam.fr wrote: > > Subject: Shadow and projected texture > > Like Scott McMillan and Mark Baranowski, I try to make shadows with > > Performer 2.1 and Irix 6.2. > > > > Remi ARNAUD says: > > > OpenGL shadows are not supported by Performer 2.x, but the OpenGL shadow > > > extensions are in the patch 1355 for 6.2. > > > > Is this the solution ? if, it is, ok I will install this patch. > > Well what Remi has just said means that 1355 is essential but even with > it it's not a solution: "OpenGL shadows are not supported by Performer 2.x" > > Compile for IrisGL and perhaps this will support the shadows via IrisGL > and IGLOO. > > Failing this you'll have to hand code the OpenGL shadows multi-pass. > > Cheers, > Angus. > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Angus Dorbie Angus, I think Remi was trying to say that performer does not have a node that implements OpenGL shadows. Not that OpenGL shadow extension would not work. Even with the OpenGL shadow extension you still have to do two passes one to render to the depth buffer from the point view of the light source. Then in the final pass you load the depth buffer information into the texture memory using the OpenGL extension and render from the point of view of the observer. You can read about this in glintro. SO you will need to draw the channel twice with two different viewpoints. The OpenGL calls can be put into a post-draw callback. Brian -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 20 18:33:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id SAA17171; Mon, 20 Jan 1997 18:32:32 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id SAA17155; Mon, 20 Jan 1997 18:32:31 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id SAA09658; Mon, 20 Jan 1997 18:32:20 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA10314 for ; Mon, 20 Jan 1997 18:32:20 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id SAA03769; Mon, 20 Jan 1997 18:32:19 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id SAA04389; Mon, 20 Jan 1997 18:32:17 -0800 From: "Sharon Clay" Message-Id: <9701201832.ZM4387@rose.asd.sgi.com> Date: Mon, 20 Jan 1997 18:32:17 -0800 In-Reply-To: inca@public.bta.net.cn "Re: pfPipeWindows and OpenGL" (Jan 20, 9:54pm) References: <199701201354.VAA16879@public.bta.net.cn> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: inca@public.bta.net.cn, info-performer@sgi.com Subject: Re: pfPipeWindows and OpenGL Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 20, 9:54pm, inca@public.bta.net.cn wrote: > Subject: Re: pfPipeWindows and OpenGL ->From guest@holodeck.csd.sgi.com Mon Jan 20 06:25:55 1997 -> ->> pfInit(); -> _try_ pfMultiprocess(PFMP_APPCULLDRAW); FYI, this is the default on a single CPU system. -> ^^^ ->> pfConfig(); ->> ->> p = pfGetPipe(0); ->> pw = pfNewPWin(p); ->> pfPWinType(pw, PFPWIN_TYPE_X); ->> pfPWinName(pw, "IRIS Performer"); ->> pfPWinOriginSize(pw, 0, 0, 500, 500); ->> pfOpenPWin(pw); ->> ->> dpy=pfGetCurWSConnection(); ->> win=pfGetPWinWSWindow(pw); -> _try_ fprintf(stderr,"win is 0x%x\n",win); -> ^^^ -> is it zero or some number? then move win=pfGetPWinWSWindow(pw); -> and fprintf(stderr,"win is 0x%x\n",win); to pfOpenPWin(), try -> PFMP_APPCULLDRAW, PFMP_APP_CULLDRAW. -> ->> wincxt=pfGetPWinGLCxt(pw); ->> ->> glXMakeCurrent(dpy,win,wincxt); /* if win is zero, fault */ -> ->key problem is pfGetPWinWSWindow don't work in APP process when multiprocess ->case. man page say it works, but it don't. It does work but the window has to have been opened first for you to be able to get anything back. The window will be opened in the draw process which isn't even running until after the first call to pfFrame(). Since we don't propagate requests from one app frame until you have called pfFrame(), you have to call pfFrame() after the request to open the window. Even so, since it is an asynchronous request, if you call pfGetPWinWSWindow() right away you still might get back 0x0 and might have to loop waiting for the result. An example of how to more resonably structure such code is in pguide/libpf/C/complex.c where each frame we check to see if the window is initialized and then once get back an indication that it is go and do all of the other X window hook-up stuff. Hope this helps, src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 00:53:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id AAA17973; Tue, 21 Jan 1997 00:52:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id AAA17957; Tue, 21 Jan 1997 00:52:50 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA23105; Tue, 21 Jan 1997 00:52:17 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA26466 for ; Tue, 21 Jan 1997 00:52:17 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id AAA13065; Tue, 21 Jan 1997 00:52:15 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id AAA05296; Tue, 21 Jan 1997 00:52:14 -0800 From: "Sharon Clay" Message-Id: <9701210052.ZM5294@rose.asd.sgi.com> Date: Tue, 21 Jan 1997 00:52:13 -0800 In-Reply-To: rany@rtset.co.il (Ran Yakir) "Re: Performer with dm pbuffers" (Jan 14, 10:27am) References: <9701141027.ZM2422@oren.rtset.co.il> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: rany@rtset.co.il (Ran Yakir), ulf.yngwe@mandator.se Subject: Re: Performer with dm pbuffers Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 14, 10:27am, Ran Yakir wrote: > Subject: Re: Performer with dm pbuffers ->From guest@holodeck.csd.sgi.com Tue Jan 14 01:08:18 1997 ->Date: Tue, 14 Jan 1997 10:27:16 +0200 ->From: rany@rtset.co.il (Ran Yakir) ->In-Reply-To: ulf.yngwe@mandator.se -> "Performer with dm pbuffers" (Jan 13, 5:01pm) ->X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) ->To: ulf.yngwe@mandator.se ->Subject: Re: Performer with dm pbuffers ->Cc: info-performer@sgi.com -> ->On Jan 13, 5:01pm, ulf.yngwe@mandator.se wrote: ->> Subject: Performer with dm pbuffers ->> ->> Is there anybody who has used the digital media pbuffers with performer. I am ->> trying ->> to create a pbuffer to use performer to draw in, but i can't find out how to ->> create one. ->> If anyone has some piece of code it would be greatly apreciated. ->> -> ->The proper way to set up Performer with dmedia pbuffers, is through the calls ->pfPWinWSDrawable() and pfPWinGLCxt(). The drawable is the pbuffer and the ->context can be created with glXCreateContextWithConfigSGIX(). ->The problem is that only Performer 2.2 can get a pbuffer as a drawable. ->Performer 2.1 will crash on that. The way to work around this is creating a ->plain old pfPipeWindow, but call glXMakeCurrent with your pbuffer and context ->at the beginning of the drawing frame. FYI, Performer versions 2.0.3/2.1.1 shipped in IRIX6.3 and versions 2.0.4/2.1.2 to be shipped in IRIX6.4 and soon to be released patch 1696 for IRIX6.2 supports the work-around of handing pf{P}WinWSDrawable a pfbuffer and pf{P}WinFBConfig a GLXFBConfigSGIX. This methodology, though not graceful, was choosen as the first line of support because it could be put into 2.0 without breaking binary compatibility. Ultimately, Performer2.2 will have a more graceful way of supporting pbuffers. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 01:05:58 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA18010; Tue, 21 Jan 1997 01:04:42 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA17994; Tue, 21 Jan 1997 01:04:41 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA23451; Tue, 21 Jan 1997 01:04:29 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA27817 for ; Tue, 21 Jan 1997 01:04:29 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id BAA13268; Tue, 21 Jan 1997 01:04:27 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id BAA05355; Tue, 21 Jan 1997 01:04:26 -0800 From: "Sharon Clay" Message-Id: <9701210104.ZM5353@rose.asd.sgi.com> Date: Tue, 21 Jan 1997 01:04:26 -0800 In-Reply-To: BOCCARA Michael "_pfDirtCheck : pfWhatsThat ???" (Jan 17, 1:33pm) References: <199701171217.EAA09191@sgi.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: BOCCARA Michael , Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: Re: _pfDirtCheck : pfWhatsThat ??? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 17, 1:33pm, BOCCARA Michael wrote: > Subject: _pfDirtCheck : pfWhatsThat ??? ->From guest@holodeck.csd.sgi.com Fri Jan 17 05:18:53 1997 -> -> Hi, -> I am loading many model files in pfb format. -> Her is an error notified by Performer at the first frame, and looping all -> time since then:` -> -> PF Warning/SysErr _pfDirtCheck : bad pfObject index 415106528 -> The strangest is that this error disappears and my sim works OK when I -> replace one of my models from pfb to iv format. -> -> Is there a bug in libpfpfb that limits the number of models you can load in 1 -> simulation ? -> -> I am working on an Onyx RE2, Performer 2.0 and I extracted libpfpfb from the -> sgi web site. -> -> Please give me some explanation because I am facing a wall in my development. Any chance you are using the N32 versions and haven't gotten the Performer 2.0.2 patches (1347 for eoe and 1392 for dev)? You can request these patches from your sales office if you do not have them. There was a bug in the N32 compiler when we built Performer2.0 and it caused an infinite loop in the internal routine _pfDirtCheck once you hit a certain number of allocated and deleted pfObjects. A different model or different loader could change the number of deletions and thus change when you would this this threshold. This bug would not be in the O32 version so if it fails also in O32 then this is not your problem. Let us know if you need more assistance! src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 01:24:00 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA18068; Tue, 21 Jan 1997 01:22:49 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA18052; Tue, 21 Jan 1997 01:22:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA24002; Tue, 21 Jan 1997 01:22:37 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA29943 for ; Tue, 21 Jan 1997 01:22:36 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id BAA13629; Tue, 21 Jan 1997 01:22:30 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id BAA05448; Tue, 21 Jan 1997 01:22:26 -0800 From: "Sharon Clay" Message-Id: <9701210122.ZM5446@rose.asd.sgi.com> Date: Tue, 21 Jan 1997 01:22:25 -0800 In-Reply-To: Christopher R Volpe "Solution: Re: Sudden X/Performer problem" (Jan 14, 3:29pm) References: <32D2D4D4.1296@ash.crd.ge.com> <9701081304.ZM13842@octave> <9701081058.ZM28017@rose.asd.sgi.com> <32DA9881.58E4@ash.crd.ge.com> <32DBECB0.21AD@ash.crd.ge.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: Christopher R Volpe Subject: Re: Solution: Re: Sudden X/Performer problem Cc: Fred Clyne , Christopher R Volpe , info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 14, 3:29pm, Christopher R Volpe wrote: > Subject: Solution: Re: Sudden X/Performer problem -> ->Christopher R Volpe (that's me) wrote: ->> ->So, I decided to ensure that I had enough mallocable space by malloccing ->and freeing some memory prior to initializing the shared arena. I ->mallocced and freed 16MB, under the assumption that this would be enough ->to shift the brk point a little, leaving enough room for whatever pfInit ->needed. But I noticed that the arena base was now placed 128Mb beyond ->the brk point, no longer right at the brk point. -> ->So, maybe just moving the brk point at all causes the bug to disappear ->and allows the shared arena base to be placed where it should, 128MB ->beyond the brk point. I tested this by scrapping the malloc/free of 16MB ->and replaced it with sbrk(1), i.e. move the brk point by one byte. Sure ->enough, this did the trick. -> ->So, if anyone else runs into this problem, before hardcoding virtual ->addresses for the shared arena with pfSharedArenaBase(), try putting a ->sbrk(1) before your pfInit() call. Yup - if you can edit your program to call API anyway, then this is a better soln. FYI, I'll go ahead and put the "tricky rld WAR previously requested at the end of this email. -> ->Now, the question on my mind is: What on earth would tell Irix to ->allocate shared arena right at the brk point, and why does it only do ->this under certain circumstances? An IRIX bug that is fixed in IRIX 6.4. -> ->-Chris -> ->-- -> ->Chris Volpe Phone: (518) 387-7766 ->GE Corporate R&D Fax: (518) 387-6560 ->PO Box 8 Email: volpecr@crd.ge.com ->Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr rld init WAR (thx Don Hatch) This causes rld to load a DSO with a fix routine in it and upon loading that DSO call the routine pfInitFix(). Notes: 1) separate compiled versions will be needed for N32 and O32 2) on ficus between different methods of just compiling perfly different base addresses are needed and so these addresses may not even work for all programs. ======== shell script to run pf program: #!/bin/csh # # runpf shell script to set Performer shared arena base # to run: # runpf progname progargs setenv _RLD_LIST ./pfInitFix.so:DEFAULT #setenv PFSHAREDBASE 0x5fa80000 # for DSO setenv PFSHAREDBASE 0x18000000 # for static built $* ========= pfInitFix.c /* * Compile with: cc -g -fullwarn -shared -Wl,-init,pfInitFix pfInitFix.c -o pfInitFix.so * Run with: setenv PFSHAREDBASE 0xWhatever setenv _RLD_LIST ./pfInitFix.so:DEFAULT * or setenv _RLD_LIST libdmalloc.so:./pfInitFix.so:DEFAULT */ #include #include #include pfInitFix() { void *myself = dlopen(NULL, RTLD_LAZY); if (dlsym(myself, "pfSharedArenaBase")) { char *e = getenv("PFSHAREDBASE"); if (e != NULL) { void *base = (*e ? (void *)strtoull(e, NULL, 0) : 0); pfNotify(PFNFY_INFO, PFNFY_PRINT, "Requesting shared arena base %#0*llx", 2+2*sizeof(base), (unsigned long long)base); pfSharedArenaBase(base); } } dlclose(myself); } -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 01:53:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA18244; Tue, 21 Jan 1997 01:52:10 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA18228; Tue, 21 Jan 1997 01:52:09 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA24988; Tue, 21 Jan 1997 01:51:58 -0800 Received: from imtsg11.epfl.ch (imtsg11.epfl.ch [128.178.45.8]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA03358 for ; Tue, 21 Jan 1997 01:51:54 -0800 Received: (from andenmat@localhost) by imtsg11.epfl.ch (940816.SGI.8.6.9/8.6.12) id KAA23853 for info-performer@sgi.com; Tue, 21 Jan 1997 10:51:47 +0100 From: "Yann Andenmatten" Message-Id: <9701211051.ZM23851@imtsg11.epfl.ch> Date: Tue, 21 Jan 1997 10:51:47 +0100 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com Subject: add triangles in a pfGeode Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi , Actually I'm looking for the best solution to cut a pfGeode in two pieces. Today, I've seen for the first time the demos CAT-SCAN data display and FEA of a Piston (in Performance Features/Alpha Bitplanes/Finite Element Analysis). Can someone confirme that no new triangles are added to have a so clean clip ? Second question, can someone tell me if Performer offer some possibilies to add triangles in a pfGeode easily ? Thanks in advance. Yann Andenmatten -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [][][] [][] [][][] [] > Ecole Polytechnique Federale de Lausanne [] [] [] [] [] > Swiss Federal Institute of Technology [][] [][][] [][] [] > [] [] [] [] > Yann Andenmatten, +41.22 693.58.50 [][][] [] [] [][][] > yandenmat@di.epfl.ch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 01:49:40 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA18212; Tue, 21 Jan 1997 01:48:13 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA18196; Tue, 21 Jan 1997 01:48:12 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA24836; Tue, 21 Jan 1997 01:48:00 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA02820 for ; Tue, 21 Jan 1997 01:47:59 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id BAA14110; Tue, 21 Jan 1997 01:47:49 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id BAA05595; Tue, 21 Jan 1997 01:47:48 -0800 From: "Sharon Clay" Message-Id: <9701210147.ZM5593@rose.asd.sgi.com> Date: Tue, 21 Jan 1997 01:47:48 -0800 In-Reply-To: tidrowd@cc.tacom.army.mil "Re: Q: No picking of pfbillboards?" (Jan 17, 10:08am) References: <2dfadfe0@cc.tacom.army.mil> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: tidrowd@cc.tacom.army.mil, Thomas.Steudten@philosys.de (Thomas Steudten), info-performer@sgi.com Subject: Re: Q: No picking of pfbillboards? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 17, 10:08am, tidrowd@cc.tacom.army.mil wrote: > Subject: Re: Q: No picking of pfbillboards? -> ->Not sure if you have already received a reply, so here goes: -> ->From the pfBillboard man page (under BUGS): ->"Intersection traversals test only the pfBillboard's bounding volume, not -> its individual pfGeoSets." -> ->If you really need it, you might be able to add intersection traversal callbacks ->to a pfBillboard node to fix this. -> ->Question to Performer team: Will this be fixed in the next release? Or is it ->something we should do using callbacks? Well, you still probably don't want to intersect with the bboard gset geometry anyway but with some other geometry that better represents your actual object? That can currently be managed with traversal masks. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 02:06:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA18335; Tue, 21 Jan 1997 02:05:12 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA18319; Tue, 21 Jan 1997 02:05:11 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA25622; Tue, 21 Jan 1997 02:05:00 -0800 Received: from relay.interserv.com (relay.interserv.com [165.121.2.67]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id CAA04732 for ; Tue, 21 Jan 1997 02:04:58 -0800 From: inca@public.bta.net.cn Received: from 202.96.61.16 ([202.96.61.16]) by relay.interserv.com with SMTP id AA28327 (5.67b/IDA-1.5 for info-performer@sgi.com); Tue, 21 Jan 1997 02:04:52 -0800 Date: Tue, 21 Jan 1997 02:04:52 -0800 Message-Id: <199701211004.AA28327@relay.interserv.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: pfPipeWindows & Texture on iR To: info-performer@sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Hi, Sharon Clay, You are right about pfGetPWinWSWindow. Thanks. i asked follow question last week, can you help me? ---- on Aug 16, 1996, Sharon Clay wrote: >This is because each pfPipeWindow has a separate graphics context so >when you have to change pfPipeWindows, a graphics context switch occurs. >One additional issue is the management of textures and display lists >between graphics contexts. By default separate graphics >contexts do _not_ share textures which means that you might be >running out of texture memory from duplicated textures. >You can verify if this is the case with performer graphics stats - they >will show texture downloads happening. >If this is your trouble, you can attach multiple pfPipeWindows (the >default Performer share mask specifies to share GL objects, PFWIN_SHARE_GL_OBJS). it's only available in PFMP_APPCULLDRAW. this is result of test: APPCULLDRAW APP_CULLDRAW APPCULL_DRAW 1 pfPipeWindows 100% 100% 100% 2 shared 100% 50% 50% 2 not shared 50% 50% 50% 3 shared 100% 33% 33% 3 not shared 33% 33% 33% the number in table is boundary, speed down if go beyond the limit. test on iR/2xR4400, 2xRM6, IRIX6.2, PF2.1, patch 1355(Aug,96 second release). Question: is it a normal behaviour, known bug, or my mistake ? I'm able to supply source code if necessary. Thanks for any help! liubin ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 04:41:22 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA18728; Tue, 21 Jan 1997 04:40:17 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA18712; Tue, 21 Jan 1997 04:40:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA00389; Tue, 21 Jan 1997 04:40:05 -0800 Received: from cucs18.cs.cuhk.hk (cucs18.cs.cuhk.hk [137.189.91.190]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA24366 for ; Tue, 21 Jan 1997 04:39:57 -0800 Received: from sgi17.cs.cuhk.hk by cs.cuhk.hk with ESMTP id UAA14305; Tue, 21 Jan 1997 20:39:48 +0800 Received: by sgi17.cs.cuhk.hk (940816.SGI.8.6.9/Spike-2.0) id UAA09007; Tue, 21 Jan 1997 20:39:47 +0800 Date: Tue, 21 Jan 1997 20:39:46 +0800 (HKT) From: David Chan To: info-performer Subject: specify a path for a user Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O HI, I want to ask, What is the approach to specify a path for a user to travel through a scene, and what is the approach's advantages and disadvantages? Any suggestion are welcome, Thanks very much. Bye! David ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 05:28:37 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA18851; Tue, 21 Jan 1997 05:27:31 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA18835; Tue, 21 Jan 1997 05:27:30 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA02115; Tue, 21 Jan 1997 05:27:18 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA00311; Tue, 21 Jan 1997 05:27:14 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id NAA18163; Tue, 21 Jan 1997 13:27:11 GMT From: "Angus Dorbie" Message-Id: <9701211327.ZM18161@bitch.reading.sgi.com> Date: Tue, 21 Jan 1997 13:27:11 +0000 In-Reply-To: brian@sgi.com (Brian Furtaw) "Re: Shadow and projected texture" (Jan 20, 8:41pm) References: <9701080615.ZM15429@unknown.zmail.host> <9701201825.ZM17222@bitch.reading.sgi.com> <9701202041.ZM5362@hotsauce.clubfed.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: brian@sgi.com, pere1@cluny.ensam.fr, info-performer@sgi.com Subject: Re: Shadow and projected texture Cc: PERE@cluny.ensam.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 20, 8:41pm, Brian Furtaw wrote: > Subject: Re: Shadow and projected texture > On Jan 20, 6:25pm, Angus Dorbie wrote: > > Subject: Re: Shadow and projected texture > > On Jan 8, 6:15am, pere1@cluny.ensam.fr wrote: > > > Subject: Shadow and projected texture > > > Like Scott McMillan and Mark Baranowski, I try to make shadows with > > > Performer 2.1 and Irix 6.2. > > > > > > Remi ARNAUD says: > > > > OpenGL shadows are not supported by Performer 2.x, but the OpenGL shadow > > > > extensions are in the patch 1355 for 6.2. > > > > > > Is this the solution ? if, it is, ok I will install this patch. > > > > Well what Remi has just said means that 1355 is essential but even with > > it it's not a solution: "OpenGL shadows are not supported by Performer 2.x" > > > > Compile for IrisGL and perhaps this will support the shadows via IrisGL > > and IGLOO. > > > > Failing this you'll have to hand code the OpenGL shadows multi-pass. > > > > Cheers, > > Angus. > > > > ======================================================================= > > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > > Submissions: info-performer@sgi.com > > Admin. requests: info-performer-request@sgi.com > >-- End of excerpt from Angus Dorbie > > Brian, For the sake of avoiding confusion: Remi clearly stated that you need patch 1355 for shadows in OpenGL. If you have shadows in OpenGL you can support this yourself using performer but the support Remi is talking about is automatic shadows using performers multipass capability; PFTRAV_MULTIPASS and the pflightsource; PFLS_SHADOW_ENABLE. This works for an IrisGL compile in Performer but not OpenGL. I hope this is clearer now. Cheers, Angus. > Angus, > I think Remi was trying to say that performer does not have a node that > implements OpenGL shadows. Not that OpenGL shadow extension would not work. > Even with the OpenGL shadow extension you still have to do two passes one > to render to the depth buffer from the point view of the light source. Then > in the final pass you load the depth buffer information into the texture > memory using the OpenGL extension and render from the point of view of the > observer. You can read about this in glintro. SO you will need to draw the > channel twice with two different viewpoints. The OpenGL calls can be put > into a post-draw callback. > > Brian > > -- > o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o > > Brian Furtaw (brian@sgi.com) > VisSim Technical Consultant > 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 > Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer >-- End of excerpt from Brian Furtaw ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 05:58:11 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA19046; Tue, 21 Jan 1997 05:56:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA19030; Tue, 21 Jan 1997 05:56:56 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA03539; Tue, 21 Jan 1997 05:56:44 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA04664; Tue, 21 Jan 1997 05:56:43 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA06403; Tue, 21 Jan 1997 08:55:44 -0500 Date: Tue, 21 Jan 1997 08:55:44 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701210855.ZM6402@hotsauce.clubfed.sgi.com> In-Reply-To: "Angus Dorbie" "Re: Shadow and projected texture" (Jan 21, 1:27pm) References: <9701080615.ZM15429@unknown.zmail.host> <9701201825.ZM17222@bitch.reading.sgi.com> <9701202041.ZM5362@hotsauce.clubfed.sgi.com> <9701211327.ZM18161@bitch.reading.sgi.com> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Angus Dorbie" , brian@sgi.com, pere1@cluny.ensam.fr, info-performer@sgi.com Subject: Re: Shadow and projected texture Cc: PERE@cluny.ensam.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O My apologies Angus, I did not know about those features. I did not mean to cause any confusion. Brian On Jan 21, 1:27pm, Angus Dorbie wrote: > Subject: Re: Shadow and projected texture > On Jan 20, 8:41pm, Brian Furtaw wrote: > > Subject: Re: Shadow and projected texture > > On Jan 20, 6:25pm, Angus Dorbie wrote: > > > Subject: Re: Shadow and projected texture > > > On Jan 8, 6:15am, pere1@cluny.ensam.fr wrote: > > > > Subject: Shadow and projected texture > > > > Like Scott McMillan and Mark Baranowski, I try to make shadows with > > > > Performer 2.1 and Irix 6.2. > > > > > > > > Remi ARNAUD says: > > > > > OpenGL shadows are not supported by Performer 2.x, but the OpenGL > shadow > > > > > extensions are in the patch 1355 for 6.2. > > > > > > > > Is this the solution ? if, it is, ok I will install this patch. > > > > > > Well what Remi has just said means that 1355 is essential but even with > > > it it's not a solution: "OpenGL shadows are not supported by Performer 2.x" > > > > > > Compile for IrisGL and perhaps this will support the shadows via IrisGL > > > and IGLOO. > > > > > > Failing this you'll have to hand code the OpenGL shadows multi-pass. > > > > > > Cheers, > > > Angus. > > > > > > ======================================================================= > > > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > > > Submissions: info-performer@sgi.com > > > Admin. requests: info-performer-request@sgi.com > > >-- End of excerpt from Angus Dorbie > > > > > > Brian, > For the sake of avoiding confusion: > > Remi clearly stated that you need patch 1355 for shadows in OpenGL. > If you have shadows in OpenGL you can support this yourself > using performer but the support Remi is talking about is automatic > shadows using performers multipass capability; PFTRAV_MULTIPASS and > the pflightsource; PFLS_SHADOW_ENABLE. This works for an IrisGL > compile in Performer but not OpenGL. > > I hope this is clearer now. > > Cheers, > Angus. > > > Angus, > > I think Remi was trying to say that performer does not have a node that > > implements OpenGL shadows. Not that OpenGL shadow extension would not work. > > Even with the OpenGL shadow extension you still have to do two passes one > > to render to the depth buffer from the point view of the light source. Then > > in the final pass you load the depth buffer information into the texture > > memory using the OpenGL extension and render from the point of view of the > > observer. You can read about this in glintro. SO you will need to draw the > > channel twice with two different viewpoints. The OpenGL calls can be put > > into a post-draw callback. > > > > Brian > > > > -- > > o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o > > > > Brian Furtaw (brian@sgi.com) > > VisSim Technical Consultant > > 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 > > Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer > >-- End of excerpt from Brian Furtaw > >-- End of excerpt from Angus Dorbie -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office: (301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 07:11:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA19257; Tue, 21 Jan 1997 07:10:00 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA19241; Tue, 21 Jan 1997 07:09:59 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA07527; Tue, 21 Jan 1997 07:09:48 -0800 Received: from hades.sharp.co.uk (hades.sharp.co.uk [193.114.241.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA16540 for ; Tue, 21 Jan 1997 07:09:44 -0800 Received: (from uucp@localhost) by hades.sharp.co.uk (8.6.12/8.6.12) id PAA19695 for ; Tue, 21 Jan 1997 15:13:32 GMT Received: from sharp.co.uk by hades.sharp.co.uk via smap (RMS/1) id sma019693; Tue Jan 21 15:13:20 1997 Received: from inca.sle.sharp.co.uk (aardog) by sharp.co.uk (5.x/SMI-SVR4) id AA27611; Tue, 21 Jan 1997 15:08:47 GMT Message-Id: <32E4DB77.3D55@sharp.co.uk> Date: Tue, 21 Jan 1997 15:06:31 +0000 From: Graham Jones Reply-To: graham.jones@sharp.co.uk Organization: Sharp Laboratories of Europe X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: info-performer@sgi.com Subject: Infinite Reality, Colour matrix and pfTexEnv Component Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hopefully the answer to these questions should be short and simple, I hope someone can help me: 1) More an OpenGL question than a specific Performer question: The glTexImage2D manual page states that RE, RE2 and VTX graphics systems do not support colour matrix transformations as textures are loaded or read back from texture memory. Does this apply to InfiniteReality graphics as well? I think so, but then I may just be doing something wrong. 2) Performer question - the pfTexEnv::setComponent call allows one component of an RGBA texture to be selected and used as a single component intensity texture. The manual says that a 16 bit RGBA texture could be used to provide 4 independent 4-bit intensity textures - I presume this is just an example, am I correct? I want to use a 32bit RGBA texture as separate 8 bit intensity textures as an alternative to the colour matrix transformation. Could somebody clarify the situation here, Thanks in advance, Graham. -- Sharp Laboratories of Europe, Phone: +44-(0)1865-747711 Oxford Science Park, Fax: +44-(0)1865-714217 Oxford, OX4 4GA England Graham.Jones@sharp.co.uk ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 08:45:20 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA19477; Tue, 21 Jan 1997 08:41:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA19461; Tue, 21 Jan 1997 08:41:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA14492; Tue, 21 Jan 1997 08:41:45 -0800 Received: from rainich.dcs.ed.ac.uk ([129.215.160.105]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA05060 for ; Tue, 21 Jan 1997 08:41:40 -0800 Received: from calvay.dcs.ed.ac.uk by rainich.dcs.ed.ac.uk with SMTP (PP); Tue, 21 Jan 1997 16:40:25 +0000 Received: from localhost by calvay.dcs.ed.ac.uk; Tue, 21 Jan 1997 16:40:13 GMT Date: Tue, 21 Jan 1997 16:40:10 +0000 (GMT) From: Martin Reddy To: Rambabu cc: info-performer@sgi.com Subject: Re: Dual Updates frequencies ?? In-Reply-To: <32DAB754.212D@ivex3d.com> Message-ID: Organisation: Department of Computer Science - University of Edinburgh MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O > Is it possible to have different update frequencies for different > objects in a scene ? For example, I have cloud models or other static > objects on the terrain that don't change much between frames so I just > want to update the rest of the scene every frame and these objects every > two frames ? That depends on what you mean by updating objects. The principal work which I am aware of on the subject is being done by Matthias Wloka at Brown University as his doctoral topic (see refs below). In [2], Wloka illustrates how Update Rates could be incorporated into contemporary graphics systems, however I am not aware of any system that explicity supports this concept (and he notes, 3 years ago, that no system existed then). Most real-time graphics systems implicitly couple all objects' update rate with the frame rate. As I understand it, the notion of Update Rates is applicable to any processing that you do in order to update the representation/state of an object - i.e. it is not concerned with rendering of an object; which is Performer's primary aim. You would have to implement any such processing stages yourself, and so you would have to manage the update frequency of that object yourself. Wloka mentions that the Inventor package offers built-in support for Update Rates via its timer callbacks - these can be used to update an object's attributes over time. Perhaps you could adopt a similar approach under Performer, e.g. use a callback function which is called each frame. Within that function you have a count of the number of times it has been called (a local static counter). You then only perform the processing if this counter, modulo the Update Rate, is zero. Hope this helps, Martin. [1] M. M. Wloka (1993). "Thesis Proposal: Time-Critical Graphics". Technical Report CS-93-50. Department of Computer Science, Brown University, Providence, RI. (November) ftp://ftp.cs.brown.edu/pub/techreports/93/cs93-50.ps.Z [2] M. M. Wloka (1993). "Incorporating Update Rates into Today's Graphics Systems". Technical Report CS-93-56. Department of Computer Science, Brown University, Providence, RI. (December) ftp://ftp.cs.brown.edu/pub/techreports/93/cs93-56.ps.Z +============================================================================+ | Martin Reddy Dept. of Computer Science | | University of Edinburgh | | e-mail : M.Reddy@ed.ac.uk Mayfield Road, EH9 3JZ | | http://www.dcs.ed.ac.uk/~mxr/ Tel : +44 131 650 5164 | +============================================================================+ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 08:46:00 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA19495; Tue, 21 Jan 1997 08:43:14 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA19479; Tue, 21 Jan 1997 08:43:13 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA14563; Tue, 21 Jan 1997 08:43:02 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA05244 for ; Tue, 21 Jan 1997 08:42:56 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA06909; Tue, 21 Jan 1997 11:41:40 -0500 Date: Tue, 21 Jan 1997 11:41:40 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701211141.ZM6908@hotsauce.clubfed.sgi.com> In-Reply-To: Graham Jones "Infinite Reality, Colour matrix and pfTexEnv Component" (Jan 21, 3:06pm) References: <32E4DB77.3D55@sharp.co.uk> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: graham.jones@sharp.co.uk, info-performer@sgi.com Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 21, 3:06pm, Graham Jones wrote: > Subject: Infinite Reality, Colour matrix and pfTexEnv Component > Hopefully the answer to these questions should be short and simple, I > hope someone can help me: > > 1) More an OpenGL question than a specific Performer question: > The glTexImage2D manual page states that RE, RE2 and VTX graphics > systems do not support colour matrix transformations as textures are > loaded or read back from texture memory. Does this apply to > InfiniteReality graphics as well? I think so, but then I may just be > doing something wrong. It would mention Inifinite Reality if it was to be included with the RE and RE2. Since it does not this feature should work unless a note further down the page states otherwise. > > 2) Performer question - the pfTexEnv::setComponent call allows one > component of an RGBA texture to be selected and used as a single > component intensity texture. The manual says that a 16 bit RGBA texture > could be used to provide 4 independent 4-bit intensity textures - I > presume this is just an example, am I correct? I want to use a 32bit > RGBA texture as separate 8 bit intensity textures as an alternative to > the colour matrix transformation. You are talking about the select feature read the glTexImage2D man page for the particulars of this function here are some excerpts from the man page. ... GL_DUAL_ALPHA4_SGIS, GL_DUAL_ALPHA8_SGIS, GL_DUAL_ALPHA12_SGIS, GL_DUAL_ALPHA16_SGIS, GL_DUAL_LUMINANCE4_SGIS, GL_DUAL_LUMINANCE8_SGIS, GL_DUAL_LUMINANCE12_SGIS, GL_DUAL_LUMINANCE16_SGIS, GL_DUAL_INTENSITY4_SGIS, GL_DUAL_INTENSITY8_SGIS, GL_DUAL_INTENSITY12_SGIS, GL_DUAL_INTENSITY16_SGIS, GL_DUAL_LUMINANCE_ALPHA4_SGIS, GL_DUAL_LUMINANCE_ALPHA8_SGIS, GL_QUAD_ALPHA4_SGIS, GL_QUAD_ALPHA8_SGIS, GL_QUAD_LUMINANCE4_SGIS, GL_QUAD_LUMINANCE8_SGIS, GL_QUAD_INTENSITY4_SGIS, or GL_QUAD_INTENSITY8_SGIS. ... I see 4 and 8 bit per component formats listed here so I guess you can split up an 32bit RGBA texture into four 8bit Intensity textures. ... The mapping of components from the canonical RGBA to the internal storage formats that begin with GL_DUAL_ and GL_QUAD_ needs to be clarified. There are three cases. The first case is for the GL_DUAL_ formats that are groups of GL_ALPHA, GL_LUMINANCE, and GL_INTENSITY. The R value goes to the first group while the A value goes to the second group. The second case is for the GL_DUAL_ formats that are groups of GL_LUMINANCE_ALPHA. The R and G values go to the first group while the B and A values go to the second group. The third case is for the GL_QUAD_ formats. The R value goes to the first group, the G value to the second group, the B value to the third group, and the A value to the fourth group. > > Could somebody clarify the situation here, > > Thanks in advance, > > Graham. > > -- > Sharp Laboratories of Europe, Phone: +44-(0)1865-747711 > Oxford Science Park, Fax: +44-(0)1865-714217 > Oxford, OX4 4GA > England Graham.Jones@sharp.co.uk > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Graham Jones -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 09:26:07 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA19651; Tue, 21 Jan 1997 09:24:44 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA19635; Tue, 21 Jan 1997 09:24:43 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA18390; Tue, 21 Jan 1997 09:24:31 -0800 Received: from server.rtset.co.il ([194.90.96.254]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13542 for ; Tue, 21 Jan 1997 09:24:01 -0800 Received: from rtset.co.il (jimbo.rtset.co.il [194.90.96.248]) by server.rtset.co.il (8.6.12/8.6.9) with ESMTP id TAA02439; Mon, 22 Jan 1996 19:14:04 +0200 Received: (from rany@localhost) by rtset.co.il (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA08561; Tue, 21 Jan 1997 08:35:02 -0800 From: "Ran Yakir" Message-Id: <9701210835.ZM8559@jimbo.rtset.co.il> Date: Tue, 21 Jan 1997 08:35:02 -0800 In-Reply-To: Graham Jones "Infinite Reality, Colour matrix and pfTexEnv Component" (Jan 21, 3:06pm) References: <32E4DB77.3D55@sharp.co.uk> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: graham.jones@sharp.co.uk Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > > 1) More an OpenGL question than a specific Performer question: > The glTexImage2D manual page states that RE, RE2 and VTX graphics > systems do not support colour matrix transformations as textures are > loaded or read back from texture memory. Does this apply to > InfiniteReality graphics as well? I think so, but then I may just be > doing something wrong. Color matrix (and also colour matrix) can be applied to texture loads on InfiniteReality, Impact and O2. On RE, RE2 and VTX it is applied only to pixel transfers (glCopyPixels, glDrawPixels). > > 2) Performer question - the pfTexEnv::setComponent call allows one > component of an RGBA texture to be selected and used as a single > component intensity texture. The manual says that a 16 bit RGBA texture > could be used to provide 4 independent 4-bit intensity textures - I > presume this is just an example, am I correct? I want to use a 32bit > RGBA texture as separate 8 bit intensity textures as an alternative to > the colour matrix transformation. The setComponent call is valid only in IrisGL on RE2. On all OpenGL machines, interleaved textures are supported through the GL_DUAL_TEXTURE and GL_QUAD_TEXTURE parameters in OpenGL, and not through the texture environment. Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | RT-SET Ltd. / )_ (_(_) ) \/ (_(_/<_(_)( | _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@rtset.co.il Work : 972-9-9552236 | rany@netvision.net.il Res. : 972-9-7489974 | Fax : 972-9-9552239 | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 09:38:58 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA19717; Tue, 21 Jan 1997 09:36:52 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA19701; Tue, 21 Jan 1997 09:36:52 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA19763; Tue, 21 Jan 1997 09:36:41 -0800 Received: from swissonline.ch (www-sol2.swissonline.ch [194.209.12.19]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA16728; Tue, 21 Jan 1997 09:36:05 -0800 Received: from vt-pc2 by swissonline.ch (SMI-8.6/SMI-SVR4(19960912-ast)) id SAA25039; Tue, 21 Jan 1997 18:21:48 +0100 Message-Id: <199701211721.SAA25039@swissonline.ch> From: "Vector Technologies" To: "Info Performer" , "Rob Jenkins" , "Angus Dorbie" Cc: "Urs Lauenstein" Subject: Re: HW-texture representation on Impact Date: Tue, 21 Jan 1997 18:17:44 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: O Yoooupeee!!! Great thanks to Angus and Rob - we could adjust the texel depth under MultiGen with the attribute menu. Now 2 questions: 1. in our flt models, we always used "default" value for texel depth attributes. On an RM-4, this value equals 8bits/component (RGBA), on an Impact (even with 4M TRAM) default value is 4 bits/component (RGBA). If we want to run the same application on both machines with the same quality, is it possible under Performer to override the default parameters in order not to have to modify the attribute of the textures under MultiGen? 2. on the Impact, we have a slight (10%) drop in the frame rate passing from 4bits/ component to 8bits/component RGBA. Is this normal ? Ciao. Alexander. ****************************************** VECTOR TECHNOLOGIES SA 7, ch de la Venoge CH - 1025 St-SULPICE Switzerland tel: +41 21 691 42 43 fax: +41 21 691 42 40 eml: vectortc@swissonline.ch Explore with us the 3rd dimension ! ****************************************** ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 09:50:05 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA19796; Tue, 21 Jan 1997 09:48:36 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA19780; Tue, 21 Jan 1997 09:48:35 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA21037; Tue, 21 Jan 1997 09:48:24 -0800 Received: from cesit1.unifi.it (cesit1.unifi.it [150.217.1.31]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA20437 for ; Tue, 21 Jan 1997 09:48:06 -0800 Received: from INGFI1.ING.UNIFI.IT by CESIT1.UNIFI.IT (PMDF V5.0-4 #3688) id <01IEHGFREW740007PB@CESIT1.UNIFI.IT> for info-performer@sgi.com; Tue, 21 Jan 1997 18:31:26 +0100 (MET) Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Tue, 21 Jan 1997 18:30:23 +0100 (MET) Received: from vesna.dsi.unifi.it by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA04085; Tue, 21 Jan 1997 18:28:42 +0100 Received: by vesna.dsi.unifi.it (950413.SGI.8.6.12) id SAA03603; Tue, 21 Jan 1997 18:28:09 +0100 Date: Tue, 21 Jan 1997 18:28:04 +0100 From: Luigi Rella Subject: Large Digital Terrain Management To: info-performer@sgi.com Message-id: <9701211828.ZM3601@vesna.dsi.unifi.it> MIME-version: 1.0 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Status: O How can I build a large textured digital terrain model to improve performance of my machine? I have a large digital model highly detailed. Presently I build the terrain dividing it in N x M sub-models grid (like a chessboard) and attach each sub-model under a matrix of pfSCS. --------------------------------- | | | | | | | | | | --------------------------------- | | | | | | | | | | --------------------------------- | | | | | | | | | | --------------------------------- Starting from a sub-model I obtain two new less-detailed sub-models through sub-sampling of the original one. These three sub-models then are attached to a pfLOD that manages the long distance parts of the terrain. pfSCS | -------------- pfLOD ------------ | | | | | | sub-model i sub-model i sub-model i (low detail) (medium detail) (high detail) On each sub-model (at all resolution), I apply a satellite image of the terrain as a texture. Without textures I have a frame rate of 15 Hz and the navigation is quite good. But when I apply the textures I obtain very poor performance. Someone have suggestion to improve the performance? Can I build the model in a different way? How can I manage the texture to have the low occupation of TRAM? Thank in advance. I'm running pf2.1 on a Indigo2 with R10K, Irix 6.2, 1 TRAM , 128MB RAM. -- ----------------------------------------------------------------------- | | | Luigi Rella | | | | Visual Information Processing Lab. | | CS Dept. - University of Florence | | e-mail: rella@aguirre.ing.unifi.it | | tel: +39.55.4796365 | ! | ----------------------------------------------------------------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 09:55:48 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA19843; Tue, 21 Jan 1997 09:54:41 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA19827; Tue, 21 Jan 1997 09:54:40 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA21670; Tue, 21 Jan 1997 09:54:19 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA22313; Tue, 21 Jan 1997 09:54:06 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA18617; Tue, 21 Jan 1997 17:53:57 GMT From: "Angus Dorbie" Message-Id: <9701211753.ZM18615@bitch.reading.sgi.com> Date: Tue, 21 Jan 1997 17:53:57 +0000 In-Reply-To: Graham Jones "Infinite Reality, Colour matrix and pfTexEnv Component" (Jan 21, 3:06pm) References: <32E4DB77.3D55@sharp.co.uk> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: graham.jones@sharp.co.uk Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Graham, On Jan 21, 3:06pm, Graham Jones wrote: > Subject: Infinite Reality, Colour matrix and pfTexEnv Component > Hopefully the answer to these questions should be short and simple, I > hope someone can help me: > > 1) More an OpenGL question than a specific Performer question: > The glTexImage2D manual page states that RE, RE2 and VTX graphics > systems do not support colour matrix transformations as textures are > loaded or read back from texture memory. Does this apply to > InfiniteReality graphics as well? I think so, but then I may just be > doing something wrong. Infinite Reality supports the glPixelTransfer transformations on texture downloads. > > 2) Performer question - the pfTexEnv::setComponent call allows one > component of an RGBA texture to be selected and used as a single > component intensity texture. The manual says that a 16 bit RGBA texture > could be used to provide 4 independent 4-bit intensity textures - I > presume this is just an example, am I correct? I want to use a 32bit > RGBA texture as separate 8 bit intensity textures as an alternative to > the colour matrix transformation. This relates to the IrisGL TV_COMPONENT_SELECT possible with the texture environment and it's OpenGL equivalent. This is possible with OpenGL on IMPACT and Infinite Reality systems but one consideration is; has the OpenGL functionality been implemented in Performer? It is probably has but if not you may have to try: glTexParameter(gltexhandle, GL_QUAD_TEXTURE_SELECT_SGIS, component); This will enable you to select an 8 bit single component from a 32 bit RGBA, but if you have to resort to OpenGL then the callbacks will be a pain when using different components from a single texture in the same scene. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 10:27:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA20138; Tue, 21 Jan 1997 10:24:52 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA20122; Tue, 21 Jan 1997 10:24:52 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA24830; Tue, 21 Jan 1997 10:24:41 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00820; Tue, 21 Jan 1997 10:24:35 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA18718; Tue, 21 Jan 1997 18:24:27 GMT From: "Angus Dorbie" Message-Id: <9701211824.ZM18716@bitch.reading.sgi.com> Date: Tue, 21 Jan 1997 18:24:26 +0000 In-Reply-To: "Vector Technologies" "Re: HW-texture representation on Impact" (Jan 21, 6:17pm) References: <199701211721.SAA25039@swissonline.ch> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Vector Technologies" , "Info Performer" , "Rob Jenkins" Subject: Re: HW-texture representation on Impact Cc: "Urs Lauenstein" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 21, 6:17pm, Vector Technologies wrote: > Subject: Re: HW-texture representation on Impact > Yoooupeee!!! > Great thanks to Angus and Rob - we could adjust the texel depth under > MultiGen with the attribute menu. > Now 2 questions: > 1. in our flt models, we always used "default" value for texel depth > attributes. On an RM-4, this value equals 8bits/component (RGBA), on an I expect the default is actually five bits per component on RE2, which means it looks much better than IMPACT. > Impact (even with 4M TRAM) default value is 4 bits/component (RGBA). If we > want to run the same application on both machines with the same quality, is > it possible under Performer to override the default parameters in order not > to have to modify the attribute of the textures under MultiGen? You'd have to traverse the scene graph and change the pftextures. > 2. on the Impact, we have a slight (10%) drop in the frame rate passing > from 4bits/ component to 8bits/component RGBA. Is this normal ? Yes, you may experience a larger performance hit on RE2 due to the slower fill performance, but this depends on what you are rendering. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 10:50:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA20290; Tue, 21 Jan 1997 10:48:22 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA20274; Tue, 21 Jan 1997 10:48:21 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA26975; Tue, 21 Jan 1997 10:48:10 -0800 Received: from mailhost.multigen.com (mailhost.multigen.com [204.119.69.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06515 for ; Tue, 21 Jan 1997 10:48:01 -0800 Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [204.119.70.10]) by mailhost.multigen.com (8.6.11/8.6.12) with ESMTP id KAA01939 for ; Tue, 21 Jan 1997 10:53:41 -0800 Received: from vaisyas.engr.multigen.com (vaisyas.engr.multigen.com [204.119.70.76]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id SAA06050 for ; Tue, 21 Jan 1997 18:44:56 GMT Received: (from marcus@localhost) by vaisyas.engr.multigen.com (950413.SGI.8.6.12/8.6.12) id KAA13143 for info-performer@sgi.com; Tue, 21 Jan 1997 10:52:32 -0800 From: "Marcus Barnes" Message-Id: <9701211052.ZM13142@vaisyas.engr.multigen.com> Date: Tue, 21 Jan 1997 10:52:32 -0800 In-Reply-To: "Vector Technologies" "Re: HW-texture representation on Impact" (Jan 21, 6:17pm) References: <199701211721.SAA25039@swissonline.ch> Organization: MultiGen Inc. X-Phones: 1-408-556-2654 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Info Performer" Subject: Re: HW-texture representation on Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 21, 6:17pm, Vector Technologies wrote: > Subject: Re: HW-texture representation on Impact > Now 2 questions: > 1. in our flt models, we always used "default" value for texel depth > attributes. On an RM-4, this value equals 8bits/component (RGBA), on an > Impact (even with 4M TRAM) default value is 4 bits/component (RGBA). If we > want to run the same application on both machines with the same quality, is > it possible under Performer to override the default parameters in order not > to have to modify the attribute of the textures under MultiGen? If you set your texture attribute's internal format field to be RGBA_8 then the OpenFlight loader will always load your textures that way, just like you want. I guess that you have alot of textures that you don't want to correct manually? > 2. on the Impact, we have a slight (10%) drop in the frame rate passing > from 4bits/ component to 8bits/component RGBA. Is this normal ? Yes, because you've doubled your texture memory and bandwidth requirements . Regards. -- + Marcus Barnes, Technical Staff mailto:marcus@multigen.com + + Multigen Inc. http://www.multigen.com + + 550 S. Winchester Blvd. phoneto:1-408-556-2654 + + Suite 500 San Jose CA 95128 faxto:1-408-261-4102 + ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 10:58:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA20345; Tue, 21 Jan 1997 10:57:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA20329; Tue, 21 Jan 1997 10:57:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA27693; Tue, 21 Jan 1997 10:57:06 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08653; Tue, 21 Jan 1997 10:55:46 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA18743; Tue, 21 Jan 1997 18:55:33 GMT From: "Angus Dorbie" Message-Id: <9701211855.ZM18741@bitch.reading.sgi.com> Date: Tue, 21 Jan 1997 18:55:33 +0000 In-Reply-To: Luigi Rella "Large Digital Terrain Management" (Jan 21, 6:28pm) References: <9701211828.ZM3601@vesna.dsi.unifi.it> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Luigi Rella , info-performer@sgi.com Subject: Re: Large Digital Terrain Management Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O The problem is that you will be paging texture from ram to texture memory. You could consider buying the extra TRAM but this may not help much if you really have high resolution imagery. You could try using a tlut to use 8 bit immagery to give a colour representation but this suffers from some interpolation problems. You could also try using MORE textures. How can this help? I expect you are asking. Well you can have your database with high resolution immagery on the high Level of detail. You then have lower resolution immagery on the lower LODs, this means that as you fly around the database the graphics system won't have to page as much information every frame. Currently it will be loading all the visible texture immagery at highest resolution (and possibly with MIP maps), most of this you don't need. So by using the model LODs to reduce the ground resolution in the distance you will dramatically cut the download requirement probably without affecting image quality even though it will require more texture data. Cheers, Angus. On Jan 21, 6:28pm, Luigi Rella wrote: > Subject: Large Digital Terrain Management > How can I build a large textured digital terrain model to improve performance > of my machine? > > I have a large digital model highly detailed. > Presently I build the terrain dividing it in N x M sub-models grid (like a > chessboard) and attach each sub-model under a matrix of pfSCS. > > --------------------------------- > | | | | | > | | | | | > --------------------------------- > | | | | | > | | | | | > --------------------------------- > | | | | | > | | | | | > --------------------------------- > > Starting from a sub-model I obtain two new less-detailed sub-models through > sub-sampling of the original one. These three sub-models then are attached to > a pfLOD that manages the long distance parts of the terrain. > > pfSCS > | > -------------- pfLOD ------------ > | | | > | | | > sub-model i sub-model i sub-model i > (low detail) (medium detail) (high detail) > > > On each sub-model (at all resolution), I apply a satellite image of the terrain > as a texture. > > Without textures I have a frame rate of 15 Hz and the navigation is quite good. > But when I apply the textures I obtain very poor performance. > > Someone have suggestion to improve the performance? > Can I build the model in a different way? > How can I manage the texture to have the low occupation of TRAM? > > Thank in advance. > > I'm running pf2.1 on a Indigo2 with R10K, Irix 6.2, 1 TRAM , 128MB RAM. >-- End of excerpt from Luigi Rella ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 11:13:08 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA20671; Tue, 21 Jan 1997 11:11:41 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA20655; Tue, 21 Jan 1997 11:11:40 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA29138; Tue, 21 Jan 1997 11:11:29 -0800 Received: from mailhost.multigen.com (mailhost.multigen.com [204.119.69.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13513 for ; Tue, 21 Jan 1997 11:11:27 -0800 Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [204.119.70.10]) by mailhost.multigen.com (8.6.11/8.6.12) with ESMTP id LAA02072 for ; Tue, 21 Jan 1997 11:17:08 -0800 Received: from vaisyas.engr.multigen.com (vaisyas.engr.multigen.com [204.119.70.76]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id TAA06483 for ; Tue, 21 Jan 1997 19:08:23 GMT Received: (from marcus@localhost) by vaisyas.engr.multigen.com (950413.SGI.8.6.12/8.6.12) id LAA13221 for info-performer@sgi.com; Tue, 21 Jan 1997 11:15:59 -0800 From: "Marcus Barnes" Message-Id: <9701211115.ZM13220@vaisyas.engr.multigen.com> Date: Tue, 21 Jan 1997 11:15:59 -0800 In-Reply-To: "Angus Dorbie" "Re: HW-texture representation on Impact" (Jan 21, 6:24pm) References: <199701211721.SAA25039@swissonline.ch> <9701211824.ZM18716@bitch.reading.sgi.com> Organization: MultiGen Inc. X-Phones: 1-408-556-2654 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Info Performer" Subject: Re: HW-texture representation on Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 21, 6:24pm, Angus Dorbie wrote: > On Jan 21, 6:17pm, Vector Technologies wrote: > > Impact (even with 4M TRAM) default value is 4 bits/component (RGBA). If we > > want to run the same application on both machines with the same quality, is > > it possible under Performer to override the default parameters in order not > > to have to modify the attribute of the textures under MultiGen? > > You'd have to traverse the scene graph and change the pftextures. ... or you can fetch the loader's shared palette and walk its list of pfTextures. Do this after loading, but before downloading the textures or calling pfFrame(): #include static void TexFormat ( void ) { fltSharedPalette* palette = fltGetCurSharedPalette(); pfList* texList = palette->texList; int howMany = pfGetNum ( texList ); int which; for ( which = 0; which < howMany; ++ which ) { fltSharedObj* obj = pfGet ( texList, which ); pfTexture* tex = ( pfTexture* ) obj->object; int comp; unsigned* image; int ns; int nt; int nr; pfGetTexImage( tex, & image, & comp, & ns, & nt, & nr ); switch ( comp ) { case 4: pfTexFormat( tex, PFTEX_INTERNAL_FORMAT, PFTEX_RGBA_8 ); break; case 3: pfTexFormat( tex, PFTEX_INTERNAL_FORMAT, PFTEX_RGB_8 ); break; case 2: pfTexFormat( tex, PFTEX_INTERNAL_FORMAT, PFTEX_IA_8 ); break; case 1: pfTexFormat( tex, PFTEX_INTERNAL_FORMAT, PFTEX_I_8 ); break; } } } Regards. -- + Marcus Barnes, Technical Staff mailto:marcus@multigen.com + + Multigen Inc. http://www.multigen.com + + 550 S. Winchester Blvd. phoneto:1-408-556-2654 + + Suite 500 San Jose CA 95128 faxto:1-408-261-4102 + ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 12:17:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA21699; Tue, 21 Jan 1997 12:15:53 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA21683; Tue, 21 Jan 1997 12:15:52 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA05389; Tue, 21 Jan 1997 12:15:41 -0800 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00891 for ; Tue, 21 Jan 1997 12:15:39 -0800 From: dpugmire@facility.cs.utah.edu Received: from gemini.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id NAA15919; Tue, 21 Jan 1997 13:15:06 -0700 (MST) Received: by gemini.cs.utah.edu (8.6.12/utah-2.15sun-leaf) id NAA20197; Tue, 21 Jan 1997 13:15:04 -0700 Date: Tue, 21 Jan 1997 13:15:04 -0700 Message-Id: <199701212015.NAA20197@gemini.cs.utah.edu> To: info-performer@sgi.com Subject: Create Semaphore Arena problem Status: O Hi, I'm having some problems getting a performer 1.2 application running again. We recently upgraded an ONYX to IRIX 6.2. I was hoping that the Performer1.2 program would still run on the new operating system, but it wont. When I run it I get: Performer Fatal: pfInit: Cannot create semaphore arena via NFS (/usr/tmp). Change PFTMPDIR Currently the PFTMPDIR is not set to anything. I change it to /tmp or ./ and I still get the same problem. Any suggestions out there ? I'm sure it's something really simple. I hope... thanks, dp. ==================================================== |David Pugmire dpugmire@facility.cs.utah.edu | | | |Unbreakable toys can be used to break other toys. | ==================================================== ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 12:26:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA21865; Tue, 21 Jan 1997 12:25:22 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA21849; Tue, 21 Jan 1997 12:25:22 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA06290; Tue, 21 Jan 1997 12:25:10 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA03391 for ; Tue, 21 Jan 1997 12:25:09 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id MAA10689; Tue, 21 Jan 1997 12:25:07 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id MAA07221; Tue, 21 Jan 1997 12:25:06 -0800 From: "Sharon Clay" Message-Id: <9701211225.ZM7219@rose.asd.sgi.com> Date: Tue, 21 Jan 1997 12:25:06 -0800 In-Reply-To: inca@public.bta.net.cn "pfPipeWindows & Texture on iR" (Jan 21, 2:04am) References: <199701211004.AA28327@relay.interserv.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: inca@public.bta.net.cn, info-performer@sgi.com Subject: Re: pfPipeWindows & Texture on iR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 21, 2:04am, inca@public.bta.net.cn wrote: > Subject: pfPipeWindows & Texture on iR -> ->Hi, Sharon Clay, -> ->You are right about pfGetPWinWSWindow. Thanks. ->i asked follow question last week, can you help me? -> ->---- on Aug 16, 1996, Sharon Clay wrote: ->>This is because each pfPipeWindow has a separate graphics context so ->>when you have to change pfPipeWindows, a graphics context switch occurs. ->>One additional issue is the management of textures and display lists ->>between graphics contexts. By default separate graphics ->>contexts do _not_ share textures which means that you might be ->>running out of texture memory from duplicated textures. ->>You can verify if this is the case with performer graphics stats - they ->>will show texture downloads happening. ->>If this is your trouble, you can attach multiple pfPipeWindows (the ->>default Performer share mask specifies to share GL objects, ->PFWIN_SHARE_GL_OBJS). -> ->it's only available in PFMP_APPCULLDRAW. this is result of test: Yes :-( - this bug is fixed in 2.2. -> -> APPCULLDRAW APP_CULLDRAW APPCULL_DRAW ->1 pfPipeWindows 100% 100% 100% ->2 shared 100% 50% 50% ->2 not shared 50% 50% 50% ->3 shared 100% 33% 33% ->3 not shared 33% 33% 33% -> ->the number in table is boundary, speed down if go beyond the limit. ->test on iR/2xR4400, 2xRM6, IRIX6.2, PF2.1, patch 1355(Aug,96 second release). So then if you pull up the gfx stats you probably see texture loads happening each frame? That will have a pretty big performance hit. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 13:59:00 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA22430; Tue, 21 Jan 1997 13:57:21 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA22414; Tue, 21 Jan 1997 13:57:20 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA15600; Tue, 21 Jan 1997 13:57:08 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA25748 for ; Tue, 21 Jan 1997 13:57:03 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Tue, 21 Jan 1997 16:43:55 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Tue, 21 Jan 1997 16:43:54 Eastern Standard Time Message-ID: <32E53DB1.7D86@ivex3d.com> Date: Tue, 21 Jan 1997 17:05:37 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com Subject: pfuFlybox with BG FlyBox !!! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi : Using BGFlybox; Has anybody used the pfuFlybox utilities ? I was trying to use them in simple.c and tried printing the analog/digital values, which doesn't seem to work. I was calling the funtions in this order pfuInitFlybox(); pfuOpenFlyBox("/dev/ttyd2"); pfuGetFlybox(analog, digital); .... while(1) { ..... pfuGetFlybox(analog, digital); printf(" %f %f %d, %d", analog[0], .....digital[1]); ..... } Is this order correct ? The man page says, pfuInitFlybox uses pfuOpenFlybox and pfuGetFlybox(). I keep getting a message " /dev/flybox" not found. Do I need to set any ENV variable to fix this. I did find that, "/dev/flybox" is hard coded in the pfutil library. DO I need to change this and build a new lib or set some ENV variable ? Thanks Rambabu ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 13:47:09 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA22375; Tue, 21 Jan 1997 13:45:24 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA22359; Tue, 21 Jan 1997 13:45:23 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA14409; Tue, 21 Jan 1997 13:45:11 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA22486 for ; Tue, 21 Jan 1997 13:44:46 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Tue, 21 Jan 1997 16:30:16 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Tue, 21 Jan 1997 16:30:15 Eastern Standard Time Message-ID: <32E53A7D.73F8@ivex3d.com> Date: Tue, 21 Jan 1997 16:51:57 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: dpugmire@facility.cs.utah.edu, info-performer@sgi.com Subject: Re: Create Semaphore Arena problem References: <199701212015.NAA20197@gemini.cs.utah.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O dpugmire@facility.cs.utah.edu wrote: > > Hi, > > I'm having some problems getting a performer 1.2 application running again. > We recently upgraded an ONYX to IRIX 6.2. I was hoping that the > Performer1.2 program > would still run on the new operating system, but it wont. > When I run it I get: > > Performer Fatal: pfInit: Cannot create semaphore arena via NFS (/usr/tmp). Change PFTMPDIR > > Currently the PFTMPDIR is not set to anything. I change it to /tmp or > ./ and I still get the same problem. > > Any suggestions out there ? I'm sure it's something really simple. I hope... > > thanks, > > dp. > > ==================================================== > |David Pugmire dpugmire@facility.cs.utah.edu | > | | > |Unbreakable toys can be used to break other toys. | > ==================================================== > =======================================================================> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com Hi David : I had the same problem a few weeks back, when I was trying to run some old (pf1.2) app. And had a suggestion from SGI which fixed the problem. I understand that, you must be having a disk with XFS on it at "/". And this creates the problem for creating a Semphore on these disks. I dont' know why. Try setting the PFTMPDIR to point to a tmp directory on a disk with EFS. And it should work. Hope this helps Rambabu ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 14:19:12 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA22626; Tue, 21 Jan 1997 14:17:39 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA22610; Tue, 21 Jan 1997 14:17:38 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA17866; Tue, 21 Jan 1997 14:17:27 -0800 Received: from gauntlet.ht.com (he.ht.com [207.22.119.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01005 for ; Tue, 21 Jan 1997 14:17:14 -0800 Received: by gauntlet.ht.com; id EAA09231; Thu, 23 Jan 1997 04:51:11 -0500 (EST) Received: from unknown(10.0.100.2) by gauntlet.ht.com via smap (3.2) id xma009227; Thu, 23 Jan 97 04:50:42 -0500 Received: from hf.ht.com by ht.com (950413.SGI.8.6.12/3.1.090690-High Techsplanations) id WAA01135; Tue, 21 Jan 1997 22:15:46 GMT Received: by hf.ht.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer@sgi.com id RAA02370; Tue, 21 Jan 1997 17:15:46 -0500 From: scott@ht.com (Scott McMillan) Message-Id: <199701212215.RAA02370@hf.ht.com> Subject: Re: HW-texture representation on Impact and Texture detail discussion To: info-performer@sgi.com Date: Tue, 21 Jan 1997 17:15:46 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Status: O This discussion reminds me of one of my posts back in September. You can run it on any part of a scene graph rooted by the node passed as the argument (at least that is the way it worked the last time I checked :). --------------------------------------------------------------------- Below is a recursive function (an extension of Dwight's post) that traverses the scene graph below a node specified by the argument, and replaces all Textures specified to the 32bit (RGBA_8) format. Note this problem also occurs with the obj and pfb loaders. Also note that many times in my apps, multiple GeoSets share the same texture. This function will just set the same Texture multiple times. Since I only do this once during initialization, I don't care about efficiency. scott void upgradeTextures(pfNode *node) { if (node->isOfType(pfGroup::getClassType())) { for (int i=0; i<((pfGroup *) node)->getNumChildren(); i++) { upgradeTextures(((pfGroup *) node)->getChild(i)); } } else if (node->isOfType(pfGeode::getClassType())) { // okay...I have found a Geode now access the Texture, if present pfGeode *gnode = (pfGeode *)node; pfGeoSet *gset = gnode->getGSet(0); if (gset) { pfGeoState* gstate = gset->getGState(); if (gstate) { pfTexture *tex = (pfTexture *) gstate->getAttr(PFSTATE_TEXTURE); if (tex) { // You probably should access the existing format and make a // decision about what to change it to here. This is how you // access the existing format: // int old_format = tex->getFormat(PFTEX_INTERNAL_FORMAT); tex->setFormat(PFTEX_INTERNAL_FORMAT, PFTEX_RGBA_8); } } } } } --------------------------------------------------------------------- -- Scott McMillan | HT Medical, Inc. | Developing virtual environ- scott@ht.com | http://www.ht.com | ment medical and surgical Ph: 301-984-3706 | 6001 Montrose Rd., Ste. 902 | simulations and surgery Fax: 301-984-2104 | Rockville, MD 20852 | simulation creation tools. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 14:39:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA22823; Tue, 21 Jan 1997 14:35:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA22807; Tue, 21 Jan 1997 14:35:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA19355; Tue, 21 Jan 1997 14:35:23 -0800 Received: from gauntlet.ht.com (he.ht.com [207.22.119.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA05157 for ; Tue, 21 Jan 1997 14:35:12 -0800 Received: by gauntlet.ht.com; id FAA09307; Thu, 23 Jan 1997 05:09:10 -0500 (EST) Received: from unknown(10.0.100.2) by gauntlet.ht.com via smap (3.2) id xma009305; Thu, 23 Jan 97 05:08:56 -0500 Received: from hf.ht.com by ht.com (950413.SGI.8.6.12/3.1.090690-High Techsplanations) id WAA01290; Tue, 21 Jan 1997 22:34:00 GMT Received: by hf.ht.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer@sgi.com id RAA02405; Tue, 21 Jan 1997 17:34:01 -0500 From: scott@ht.com (Scott McMillan) Message-Id: <199701212234.RAA02405@hf.ht.com> Subject: Re: Create Semaphore Arena problem (fwd) To: info-performer@sgi.com Date: Tue, 21 Jan 1997 17:34:00 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Status: O "Rambabu" wrote: > dpugmire@facility.cs.utah.edu wrote: > > > > Hi, > > > > I'm having some problems getting a performer 1.2 application running again. > > We recently upgraded an ONYX to IRIX 6.2. I was hoping that the > > Performer1.2 program > > would still run on the new operating system, but it wont. > > When I run it I get: > > > > Performer Fatal: pfInit: Cannot create semaphore arena via NFS (/usr/tmp). Change PFTMPDIR > > > > Currently the PFTMPDIR is not set to anything. I change it to /tmp or > > ./ and I still get the same problem. > > > > Any suggestions out there ? I'm sure it's something really simple. I hope... > > > > thanks, > > > > dp. > > > > ==================================================== > > |David Pugmire dpugmire@facility.cs.utah.edu | > > | | > > |Unbreakable toys can be used to break other toys. | > > ==================================================== > > Hi David : > > I had the same problem a few weeks back, when I was trying to run some > old (pf1.2) app. And had a suggestion from SGI which fixed the problem. > > I understand that, you must be having a disk with XFS > on it at "/". And this creates the problem for creating a Semphore on > these disks. I dont' know why. Try setting the PFTMPDIR to point to a > tmp directory on a disk with EFS. And it should work. > > Hope this helps > > Rambabu > > ram@ivex3d.com I was trying to run the atlantis demo from the Reality Centre and was encountering the same problem. If you don't have an EFS system to switch to, there is a script file which can patch the executable. Rob Jenkins posted this in November. It is in the monthly-archives. I can run the atlantis demo but I spews the following Warning continuously: Performer Warning: pfESkyMode() Bad value 0 for mode 300 Also, it doesn't recognize Impact hardware, and even though it downloads the textures it won't display them. Any plans for an update of this demo for the newer hardware systems? Happy hunting, scott -- Scott McMillan | HT Medical, Inc. | Developing virtual environ- scott@ht.com | http://www.ht.com | ment medical and surgical Ph: 301-984-3706 | 6001 Montrose Rd., Ste. 902 | simulations and surgery Fax: 301-984-2104 | Rockville, MD 20852 | simulation creation tools. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 17:56:31 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA24207; Tue, 21 Jan 1997 17:54:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA24191; Tue, 21 Jan 1997 17:54:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA08015; Tue, 21 Jan 1997 17:54:44 -0800 Received: from tuvok.mugu.navy.mil (tuvok.mugu.navy.mil [143.113.247.22]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA19811 for ; Tue, 21 Jan 1997 17:54:43 -0800 Received: from qmsmtpgw.mugu.navy.mil (qmsendgw.mugu.navy.mil) by tuvok.mugu.navy.mil (4.1/SMI-4.1) id AA18409; Tue, 21 Jan 97 17:55:44 PST Message-Id: Date: 21 Jan 1997 17:58:24 U From: "SCOTT OFRIEL" Subject: Getting Gouraud Color To: info-performer@sgi.com X-Mailer: Mail*Link SMTP-QM 3.0.2 Status: O Subject: Time: 5:42 PM OFFICE MEMO Getting Gouraud Color Date: 1/21/97 Performer: Is it possible to get the RGB color value from any place between the two end points of a Gouraud shaded line? The line is a pfGeoSet. Thank you, Scott O'Friel ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 18:56:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id SAA24615; Tue, 21 Jan 1997 18:55:32 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id SAA24599; Tue, 21 Jan 1997 18:55:31 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id SAA11726; Tue, 21 Jan 1997 18:55:20 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA00838; Tue, 21 Jan 1997 18:55:09 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id CAA19658; Wed, 22 Jan 1997 02:54:56 GMT From: "Angus Dorbie" Message-Id: <9701220254.ZM19656@bitch.reading.sgi.com> Date: Wed, 22 Jan 1997 02:54:56 +0000 In-Reply-To: "SCOTT OFRIEL" "Getting Gouraud Color" (Jan 21, 5:58pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "SCOTT OFRIEL" , info-performer@sgi.com Subject: Re: Getting Gouraud Color Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O This is a linear interpolation in screen space. Problems will arise if you want to calculate this for projected screen space and the line is in perspective because the colour interpolation is not perspective correct. This gets real fun when you clip the line because the colour gets shaded from the interpolated clipped line end colour. Could you give a little more info on why you want to do this so I can better understand how these issues might relate to you? Cheers, Angus. On Jan 21, 5:58pm, SCOTT OFRIEL wrote: > Subject: Getting Gouraud Color > Subject: Time: 5:42 PM > OFFICE MEMO Getting Gouraud Color Date: 1/21/97 > > Performer: > > Is it possible to get the RGB color value from any place between the two end > points of a Gouraud shaded line? The line is a pfGeoSet. > > Thank you, > Scott O'Friel > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from SCOTT OFRIEL ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 20:00:12 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id TAA24892; Tue, 21 Jan 1997 19:58:52 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id TAA24876; Tue, 21 Jan 1997 19:58:51 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id TAA14575; Tue, 21 Jan 1997 19:58:40 -0800 Received: from newton.ncsa.uiuc.edu (newton.ncsa.uiuc.edu [141.142.2.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA10587 for ; Tue, 21 Jan 1997 19:58:39 -0800 Received: from eads.ncsa.uiuc.edu (eads.ncsa.uiuc.edu [141.142.4.3]) by newton.ncsa.uiuc.edu (8.8.4/8.8.4) with SMTP id VAA04709 for ; Tue, 21 Jan 1997 21:58:38 -0600 (CST) Date: Tue, 21 Jan 1997 21:55:33 -0600 (CST) From: "Dee A. Chapman" To: info-performer@sgi.com Subject: path following - pfuAddDelay Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hello, I posted this awhile ago, with no response so I thought I'd try again. I would like to use the "pfuAddDelay" function in the middle of one of my paths. However, when my object following the path encounters this function, the object is moved from the current path location to the origin for the duration of the delay. After the delay, it moves back to the previous path location. I need the object to stay at the current path location for the duration of the delay instead of moving. Is there a way to make it do this? Has anyone else experienced this? Thanks for any help you can provide! Dee ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 21:33:33 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id VAA25356; Tue, 21 Jan 1997 21:32:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id VAA25340; Tue, 21 Jan 1997 21:32:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id VAA18137; Tue, 21 Jan 1997 21:32:19 -0800 Received: from mailsvr.mumbai.tcs.co.in ([202.54.5.70]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA23050 for ; Tue, 21 Jan 1997 21:31:34 -0800 Received: from [145.17.40.179] by mailsvr.mumbai.tcs.co.in (NTMail 3.02.07) with ESMTP id ha010225 for ; Wed, 22 Jan 1997 11:02:09 +0530 Message-ID: <310320A8.11AE@mumbai.tcs.co.in> Date: Mon, 22 Jan 1996 10:59:12 +0530 From: Rajesh Thakur Reply-To: rajesht@mumbai.tcs.co.in Organization: Tata Consultancy Services X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: Eric Rose CC: info-performer@sgi.com Subject: Re: SIRIUS Board References: <32D62337.2D0A@mumbai.tcs.co.in> <199701201431.PAA21931@euclid.ecrc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi Eric, I am sorry for the snag. Now you can try again and you should be able to download the utility. - Rajesh *********************************************************************** Eric Rose wrote: > > >>>>> "Rajesh" == Rajesh Thakur writes: > > Rajesh> Hi Tran, We have developed an utility based on basic > Rajesh> sirius commands which will help you to dump 1500 or more > Rajesh> images at one strech. This utility is fully tested with > Rajesh> IRIX5.2, sirius1.1 > > Rajesh> The download is available at following URL: > Rajesh> http://www.tcs.co.in/tcshome/visalt/html/login.htm > > Rajesh> You will have to register (free registration) first with > Rajesh> your name and then download the first GUI based utility. > > Rajesh> All the documentation is provided alongwith. However, if > Rajesh> you have any queries regarding the setup or operation, you > Rajesh> can send a mail to me any time. > > Rajesh> Would appreciate your feedback on the usability of this > Rajesh> utility > > Rajesh> - Rajesh Thakur > Rajesh> ======================================================================= > Rajesh> List Archives, FAQ, FTP: > Rajesh> http://www.sgi.com/Technology/Performer/ Submissions: > Rajesh> info-performer@sgi.com Admin. requests: > Rajesh> info-performer-request@sgi.com > > Any way any of the rest of us can get it? I've tried several times and > each time I click on the software to download it, I get: > > HTTP/1.0 404 Object Not Found > > I would love to try out your software (improve it maybe, even). > > --------------------------------------------------------------- > Eric Rose http://www.ecrc.de/staff/erose/ > Fraunhofer Projektgruppe fuer Augmented Reality im > Zentrum fuer Grafische Datenverarbeitung (ZGDv) eV Email: erose@ecrc.de > European Computer-Industry Research Centre (ECRC) GmbH Phone: +49-89-92699-201 > Arabellastrasse 17, D-81925 Munich FAX: +49-89-92699-170 > > -Eric ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 21 23:17:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id XAA01134; Tue, 21 Jan 1997 23:15:23 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id XAA01118; Tue, 21 Jan 1997 23:15:21 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA21056; Tue, 21 Jan 1997 23:15:19 -0800 Received: from sable.nus.sg (sable.nus.sg [137.132.1.21]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA05922 for ; Tue, 21 Jan 1997 23:14:40 -0800 Received: from leonis.nus.sg (eng30228@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.8.4/8.6.9) with ESMTP id PAA23052 for ; Wed, 22 Jan 1997 15:14:30 +0800 (SST) Received: from localhost (eng30228@localhost) by leonis.nus.sg (8.6.10/8.6.9/CNS-3.5) with SMTP id PAA23465 for ; Wed, 22 Jan 1997 15:14:28 +0800 Date: Wed, 22 Jan 1997 15:14:27 +0800 (SST) From: Ming Wah To: info-performer@sgi.com Subject: Putting attr list into geosets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Dear all, Does anybody know how to put a modified attr list into a geoset? I have obtained a copy of the coordinates and its normals and have transformed them and tried to put them back but the results were rubbish inside the geoset which causes a segmentation error. I used pfGSetAttr to put the list of attributes back. Thanks Ming Wah ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 00:07:58 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id AAA01458; Wed, 22 Jan 1997 00:06:01 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id AAA01442; Wed, 22 Jan 1997 00:06:00 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA24126; Wed, 22 Jan 1997 00:05:59 -0800 Received: from cluny.ensam.fr (pictel.cluny.ensam.fr [193.50.253.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA12230 for ; Wed, 22 Jan 1997 00:05:45 -0800 From: pere1@cluny.ensam.fr Received: from VIDEO3 by cluny.ensam.fr (SMI-8.6/SMI-SVR4) id JAA06626; Wed, 22 Jan 1997 09:06:32 GMT Received: by VIDEO3 (940816.SGI.8.6.9/930416.SGI) id UAA19843; Thu, 9 Jan 1997 20:06:30 GMT Message-Id: <9701092006.ZM19841@unknown.zmail.host> Date: Thu, 9 Jan 1997 20:06:29 +0000 In-Reply-To: scott@ht.com (Scott McMillan) "Re: Shadow and projected texture" (Jan 21, 6:50pm) References: <199701212350.SAA02673@hf.ht.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: scott@ht.com (Scott McMillan) Subject: Re: Shadow and projected texture Cc: info-performer@sgi.com, PERE@cluny.ensam.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Dear Scott, I thank you for your answer. Yes, I am still looking for an sample code of two projected texture spotlights. But, the man pages says: > the total number of rendering passes is numProjLights + 2 * numNonFrozenShadowLights. So if I put 2 ProjLights, I will get a number of rendering passes equals to 2*numProjLights = 2. So, I could render a 'shadow' for two objets (each ProjLight is attached to the pfDCS of each objet and place upside it). Well, It is not 'the foot' (in french)(that means: It is not the best solution) to render the shadow of all objets in the scene to have a spotLight for each objet attached to its pfDCS. So, I am not so stupid, if I could (or somebody could) put only one ShadowLight, it costs 2 rendering passes too to render the shadow of all the scene. By reading the mail list of info-performer, I saw that you fight with shadow since a long time,Scott , don't you win? If you could send me your sample code, I will sincerly thank you. If somebody have another sample code with shadow perhaps in OpenGL(and Irix 6.2), I will thank this man too. Thank you to Angus and Brian for their participation in: "Battle against the shadow" Cheers, Christian -- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 02:08:35 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA01938; Wed, 22 Jan 1997 02:06:31 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA01922; Wed, 22 Jan 1997 02:06:29 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA27893; Wed, 22 Jan 1997 02:06:19 -0800 Received: from hades.sharp.co.uk (hades.sharp.co.uk [193.114.241.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA26793 for ; Wed, 22 Jan 1997 02:06:16 -0800 Received: (from uucp@localhost) by hades.sharp.co.uk (8.6.12/8.6.12) id KAA23411 for ; Wed, 22 Jan 1997 10:10:02 GMT Received: from sharp.co.uk by hades.sharp.co.uk via smap (RMS/1) id sma023406; Wed Jan 22 10:09:50 1997 Received: from inca.sle.sharp.co.uk (aardog) by sharp.co.uk (5.x/SMI-SVR4) id AA04215; Wed, 22 Jan 1997 10:05:13 GMT Message-Id: <32E5E5CD.7D68@sharp.co.uk> Date: Wed, 22 Jan 1997 10:02:53 +0000 From: Graham Jones Reply-To: graham.jones@sharp.co.uk Organization: Sharp Laboratories of Europe X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: info-performer@sgi.com Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component References: <32E4DB77.3D55@sharp.co.uk> <9701210835.ZM8559@jimbo.rtset.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Thanks to those who replied to my question (Ran, Brian and Angus) Ran Yakir wrote: > Color matrix (and also colour matrix) can be applied to texture loads > on InfiniteReality, Impact and O2. On RE, RE2 and VTX it is applied > only to pixel transfers (glCopyPixels, glDrawPixels). Would I be right in thinking that, on InfiniteReality, the colour matrix is not applied when an object is rendered with a texture, but only when the texture is sent to the hardware then? So I wouldn't be able to render the same object three times with three different colour matrices without downloading the texture three times (I'm trying to avoid all that data flying around the place). > > I wrote originally: > > 2) Performer question - the pfTexEnv::setComponent call allows one > > component of an RGBA texture to be selected and used as a single > > component intensity texture. Ran Yakir wrote: > The setComponent call is valid only in IrisGL on RE2. On all OpenGL > machines, interleaved textures are supported through the > GL_DUAL_TEXTURE and GL_QUAD_TEXTURE parameters in OpenGL, and not > through the texture environment. So you are saying I will need to resort to using the OpenGL calls after applying my Performer texture, as Angus suggested. I'll have a go but I might have a few more questions if it doesn't come off! Thanks for all your help. Graham. -- Sharp Laboratories of Europe, Phone: +44-(0)1865-747711 Oxford Science Park, Fax: +44-(0)1865-714217 Oxford, OX4 4GA England Graham.Jones@sharp.co.uk ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 03:53:38 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA02366; Wed, 22 Jan 1997 03:52:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA02350; Wed, 22 Jan 1997 03:52:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA00561; Wed, 22 Jan 1997 03:52:07 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA11552; Wed, 22 Jan 1997 03:51:53 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id LAA20309; Wed, 22 Jan 1997 11:51:45 GMT From: "Angus Dorbie" Message-Id: <9701221151.ZM20307@bitch.reading.sgi.com> Date: Wed, 22 Jan 1997 11:51:44 +0000 In-Reply-To: Graham Jones "Re: Infinite Reality, Colour matrix and pfTexEnv Component" (Jan 22, 10:02am) References: <32E4DB77.3D55@sharp.co.uk> <9701210835.ZM8559@jimbo.rtset.co.il> <32E5E5CD.7D68@sharp.co.uk> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: graham.jones@sharp.co.uk, info-performer@sgi.com Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 10:02am, Graham Jones wrote: > Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component > Thanks to those who replied to my question (Ran, Brian and Angus) > > Ran Yakir wrote: > > Color matrix (and also colour matrix) can be applied to texture loads > > on InfiniteReality, Impact and O2. On RE, RE2 and VTX it is applied > > only to pixel transfers (glCopyPixels, glDrawPixels). > > Would I be right in thinking that, on InfiniteReality, the colour matrix > is not applied when an object is rendered with a texture, but only when > the texture is sent to the hardware then? Yes. > > So I wouldn't be able to render the same object three times with three > different colour matrices without downloading the texture three times > (I'm trying to avoid all that data flying around the place). You want to use glColorTableSGI for this kind of thing. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 04:06:51 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA02539; Wed, 22 Jan 1997 04:05:27 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA02523; Wed, 22 Jan 1997 04:05:26 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA01379; Wed, 22 Jan 1997 04:05:15 -0800 Received: from cluny.ensam.fr (pictel.cluny.ensam.fr [193.50.253.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA12813; Wed, 22 Jan 1997 04:04:59 -0800 Received: from VIDEO6 by cluny.ensam.fr (SMI-8.6/SMI-SVR4) id NAA08572; Wed, 22 Jan 1997 13:05:50 GMT Received: by VIDEO6 (950413.SGI.8.6.12/930416.SGI) id NAA06408; Wed, 22 Jan 1997 13:04:29 -0800 From: "login IRIX" Message-Id: <9701221304.ZM6406@unknown.zmail.host> Date: Wed, 22 Jan 1997 13:04:28 -0800 In-Reply-To: "Angus Dorbie" "Re: Shadow and projected texture" (Jan 21, 1:27pm) References: <9701080615.ZM15429@unknown.zmail.host> <9701201825.ZM17222@bitch.reading.sgi.com> <9701202041.ZM5362@hotsauce.clubfed.sgi.com> <9701211327.ZM18161@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Angus Dorbie" Subject: Re: Shadow and projected texture Cc: info-performer@sgi.com, PERE@cluny.ensam.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Angus, You say in your last mail about shadows that: - if I would like to have shadows in my perfomer 2.1 application compiled in OpenGL, I need patch 1355 and must hand code the openGL shadows multi-pass: have you got some sample code about that? - if I would like to have shadows in my perfomer 2.1 by using PFLS_SHADOW_ENABLE and PFTRAV_MULTIPASS, the only way today is to compile in IrisGL... but another question: how could I make this compilation : I try with igldso or iglopt, but errors occured during execution like -> 6019:./perfly: rld: Error: unresolvable symbol in ./perfly: GLOBALBorder -> 6019:./perfly: rld: Fatal Error: this executable has unresolvable symbols Could you tell me why? And what is the frame speed in IrisGL on a Infinite Reality? OpenGL should be faster, shouldn't it? Thanks a lot for your answer! Regards. Christian -- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 04:29:24 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA02700; Wed, 22 Jan 1997 04:26:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA02684; Wed, 22 Jan 1997 04:26:51 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA02004; Wed, 22 Jan 1997 04:26:40 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA15256; Wed, 22 Jan 1997 04:26:17 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id MAA20415; Wed, 22 Jan 1997 12:26:03 GMT From: "Angus Dorbie" Message-Id: <9701221226.ZM20413@bitch.reading.sgi.com> Date: Wed, 22 Jan 1997 12:26:02 +0000 In-Reply-To: "login IRIX" "Re: Shadow and projected texture" (Jan 22, 1:04pm) References: <9701080615.ZM15429@unknown.zmail.host> <9701201825.ZM17222@bitch.reading.sgi.com> <9701202041.ZM5362@hotsauce.clubfed.sgi.com> <9701211327.ZM18161@bitch.reading.sgi.com> <9701221304.ZM6406@unknown.zmail.host> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "login IRIX" Subject: Re: Shadow and projected texture Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 1:04pm, login IRIX wrote: > Subject: Re: Shadow and projected texture > Angus, > > You say in your last mail about shadows that: > > - if I would like to have shadows in my perfomer 2.1 application > compiled in OpenGL, I need patch 1355 and must hand code the openGL shadows > multi-pass: have you got some sample code about that? No I don't, there only code I've seen to do this is the IrisGL code by John Rholf in 4DGifts. You should be able to obtain some sample OpenGL code though. > > - if I would like to have shadows in my perfomer 2.1 by using > PFLS_SHADOW_ENABLE and PFTRAV_MULTIPASS, the only way today is to compile in > IrisGL... but another question: how could I make this compilation : I try with > igldso or iglopt, but errors occured during execution like > -> 6019:./perfly: rld: Error: unresolvable symbol in ./perfly: GLOBALBorder > -> 6019:./perfly: rld: Fatal Error: this executable has unresolvable symbols > Could you tell me why? You either aren't linking a library you need or the code is making calls to unsupported functions, not necessarily your code, possibly something in a performer dso. Did you really get the code to compile with iglopt? Again, make sure you have patch 1422 for the IrisGL. > And what is the frame speed in IrisGL on a Infinite Reality? OpenGL should be > faster, shouldn't it? OpenGL is much faster than IrisGL on iR, I think IrisGL will give you RE2-ish performance. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 04:49:36 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA02902; Wed, 22 Jan 1997 04:48:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA02884; Wed, 22 Jan 1997 04:48:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA02975; Wed, 22 Jan 1997 04:48:06 -0800 Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA18171 for ; Wed, 22 Jan 1997 04:48:03 -0800 From: inca@public.bta.net.cn Received: (from inca@localhost) by public.bta.net.cn (8.6.8.1/8.6.9) id UAA08202; Wed, 22 Jan 1997 20:47:58 +0800 Date: Wed, 22 Jan 1997 20:47:58 +0800 Message-Id: <199701221247.UAA08202@public.bta.net.cn> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: pfPipeWindows & Texture on iR To: info-performer@sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Sharon Clay wrote: >Yes :-( - this bug is fixed in 2.2. Thanks for the reply. i'm doing a difficult project that has 9 non-rectangular viewports with real-time responding. i know multi-windows is bad thing, but can't avoid it. You can see my work in sgigate.sgi.com:receive/snap.rgb, please let me know if you are amazed or have some suggestion for it. (pls delete it after seen) Thanks for your time! liubin ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 05:57:39 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA03116; Wed, 22 Jan 1997 05:56:31 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA03100; Wed, 22 Jan 1997 05:56:30 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA05624; Wed, 22 Jan 1997 05:56:19 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA26642; Wed, 22 Jan 1997 05:56:07 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id NAA20586; Wed, 22 Jan 1997 13:56:03 GMT From: "Angus Dorbie" Message-Id: <9701221356.ZM20583@bitch.reading.sgi.com> Date: Wed, 22 Jan 1997 13:56:02 +0000 In-Reply-To: inca@public.bta.net.cn "Re: pfPipeWindows & Texture on iR" (Jan 22, 8:47pm) References: <199701221247.UAA08202@public.bta.net.cn> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: inca@public.bta.net.cn, info-performer@sgi.com Subject: Re: pfPipeWindows & Texture on iR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Looks great, what is it? On Jan 22, 8:47pm, inca@public.bta.net.cn wrote: > Subject: Re: pfPipeWindows & Texture on iR > > Thanks for the reply. i'm doing a difficult project that > has 9 non-rectangular viewports with real-time responding. > i know multi-windows is bad thing, but can't avoid it. > Why can't you avoid multiple windows? A few overlapping channels and the use of arbitrary clip planes or maybe just stencil operations would work. eg: You draw the channels masks to the stencil planes with specific values. You don't need unique values for each channel just ensure that for a given rectangle you have a unique value for the channel of interest, I reckon you'd need 2 bits of stencil info: 3 2 2 3 1 3 2 2 3 Everything else is stencil == 0. You do this once, then in the channel draw function you set the appropriate stencil test so that rendering is only performed when the stencil test value == framebuffer value. Clip planes could then be used to reduce fill overhead. Here's some OpenGL code I used in Performer for a similar thing, the idea was to save some pixel fill time by culling hidden blended pixels outside a circular region using stencil operations, it didn't produce a measurable improvement for my project but you have a different objective. Cheers, Angus. static void StencilHUD(pfPipeWindow *pw) { double f; static int mapped = 0; float new_x = 0.0f, new_y = 0.0f; if(Visual_Mode != VISUAL_OPTICAL) return; pfSelectPWin(pw); glPushMatrix(); glLoadIdentity(); glMatrixMode(GL_PROJECTION); glPushMatrix(); glLoadIdentity(); glOrtho(-1.0, 1.0, -1.0, 1.0, -1.0, 1.0); glMatrixMode(GL_MODELVIEW); glDisable(GL_CULL_FACE); glDisable(GL_DEPTH_TEST); glEnable(GL_STENCIL_TEST); glOrtho(-1.0, 1.0, -1.0, 1.0, -1.0, 1.0); glClearColor(1.0f, 0.0f, 0.0f, 1.0f); glClear(GL_COLOR_BUFFER_BIT); glColor3f(0.0f, 0.0f, 0.0f); /* Clear stencil planes to one over entire window */ glClearStencil(0); glClear(GL_STENCIL_BUFFER_BIT); /* were a drawin' */ glStencilFunc(GL_ALWAYS, channel_stencil_value, 0x3); glStencilOp(GL_REPLACE, GL_REPLACE, GL_REPLACE); glBegin(GL_TRIANGLE_FAN); for(f = 0.0; f< 359.5; f+=1.0) { pfSinCos((float)f, &new_x, &new_y); glVertex2f(new_x, new_y); } glEnd(); glEnable(GL_CULL_FACE); glEnable(GL_DEPTH_TEST); glMatrixMode(GL_PROJECTION); glPopMatrix(); glMatrixMode(GL_MODELVIEW); glPopMatrix(); } Use this in your channel draw function: glStencilFunc(GL_EQUAL, channel_stencil_value, 0x3); glStencilOp(GL_KEEP, GL_KEEP, GL_KEEP); glEnable(GL_STENCIL_TEST); ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 07:44:34 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA03421; Wed, 22 Jan 1997 07:43:20 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA03405; Wed, 22 Jan 1997 07:43:19 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA11516; Wed, 22 Jan 1997 07:43:09 -0800 Received: from indy3.gstone.com (indy3.gstone.com [199.35.226.23]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA12896 for ; Wed, 22 Jan 1997 07:43:08 -0800 Received: from [199.35.226.167] (dstipe.gstone.com [199.35.226.167]) by indy3.gstone.com (8.8.3/8.8.3) with SMTP id HAA27974 for ; Wed, 22 Jan 1997 07:42:12 -0800 (PST) Date: Wed, 22 Jan 1997 07:42:12 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.com From: dstipe@indy3.gstone.com (Daniel Stipe) Subject: 16mb or 64 mb max tex memory on RE2 Status: O Greetings Performers, An internal debaate has generated a question (basic) for the group. Is the maximum texture memory on a Reality Engine 2 16mb or 64mb? Thanks, Dan Dan Stipe - Sr. Staff Member Tele: (619) 974-6300 ext. 176 /\/\/\ GreyStone Technology, Inc. fax: (619) 974-6303 / /\/\ \ 4950 Murphy Canyon Road e-mail: dstipe@gstone.com \ \/\/ / San Diego, CA 92123-4325 web: http://www.gstone.com/ \/\/\/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 08:23:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA03555; Wed, 22 Jan 1997 08:21:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA03539; Wed, 22 Jan 1997 08:21:46 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA15058; Wed, 22 Jan 1997 08:21:35 -0800 Received: from hni.uni-paderborn.de (hni-ff.uni-paderborn.de [131.234.22.55]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA20580 for ; Wed, 22 Jan 1997 08:21:31 -0800 Received: from chakotay.uni-paderborn.de (chakotay [131.234.246.18]) by hni.uni-paderborn.de (8.8.4/hni-mailhub) with ESMTP id RAA16334; Wed, 22 Jan 1997 17:21:11 +0100 (MET) Received: (pe@localhost) by chakotay.uni-paderborn.de (951211.SGI.8.6.12.PATCH1042/client-irix-hni) id RAA00915; Wed, 22 Jan 1997 17:21:10 +0100 From: "Peter Ebbesmeyer" Message-Id: <9701221721.ZM913@chakotay> Date: Wed, 22 Jan 1997 17:21:09 +0100 In-Reply-To: dstipe@indy3.gstone.com (Daniel Stipe) "16mb or 64 mb max tex memory on RE2" (Jan 22, 7:42am) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: dstipe@indy3.gstone.com (Daniel Stipe), info-performer@sgi.com Subject: Re: 16mb or 64 mb max tex memory on RE2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Dan, > An internal debaate has generated a question (basic) for the group. > Is the maximum texture memory on a Reality Engine 2 > 16mb or 64mb? To my knowledge the Relity Engine2 graphics supports to kinds of raster managers: RM4 (4 MB texture memory) RM5 (16 MB texture memory) So the maximum amount of texture memory available on the RE2 is 16 MB Peter -- ----------------------------------------------------------------------- Dipl.-Ing. Peter Ebbesmeyer Universitaet-GH Paderborn Raum F0.210 Heinz Nixdorf Institut Tel. + 49 5251 606234 Rechnerintegrierte Produktion Fax. + 49 5251 606268 Virtual Environments Team email: pe@hni.uni-paderborn.de Fuerstenallee 11 33102 Paderborn Germany ----------------------------------------------------------------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 08:10:29 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA03500; Wed, 22 Jan 1997 08:09:12 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA03484; Wed, 22 Jan 1997 08:09:11 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA13963; Wed, 22 Jan 1997 08:09:00 -0800 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17477 for ; Wed, 22 Jan 1997 08:08:59 -0800 Received: from christine.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA51966; Wed, 22 Jan 1997 10:58:22 -0500 Received: by christine.cae.ca (950413.SGI.8.6.12/930416.SGI) id KAA08859; Wed, 22 Jan 1997 10:54:59 -0500 From: "Nicolas Gauvin" Message-Id: <9701221054.ZM8857@christine.cae.ca> Date: Wed, 22 Jan 1997 10:54:59 -0500 In-Reply-To: Ming Wah "Putting attr list into geosets" (Jan 22, 3:14pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: eng30228@leonis.nus.sg Subject: Re: Putting attr list into geosets Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 3:14pm, Ming Wah wrote: > Subject: Putting attr list into geosets > > Dear all, > Does anybody know how to put a modified attr list into a geoset? I > have obtained a copy of the coordinates and its normals and have > transformed them and tried to put them back but the results were rubbish > inside the geoset which causes a segmentation error. I used pfGSetAttr to > put the list of attributes back. > -- End of excerpt from Ming Wah You shouldn't need to call pfGSetAttr again to put the list back. pfGetGSetAttrLists gives you the pointers to the actual list, not a copy of them. Once you have the pointer, simply modify its content and thats it. The geoset will be aware of the changes. However the safest way to do this sort of thing is to use a pfCycleBuffer for the attribute list you intend to modify. This way you will be frame accurate when multiprocessing. The man page of pfCycleBuffer contains a simple example for this: pfVec3 *prevVerts, *curVerts; pfInit(); pfMultiprocess(mpMode); /* * This calls pfCBufferConfig() with the number of buffers * appropriate to the multiprocessing mode. */ pfConfig(); verts = pfNewCBuffer(sizeof(pfVec3) * numVerts, pfGetSharedArena()); pfGSetAttr(gset, PFGS_COORD3, PFGS_PER_VERTEX, verts, NULL); while(!done) { curVerts = pfGetCurCBufferData(verts); /* Compute new positions of mass-spring system */ for (i=0; i Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA03661; Wed, 22 Jan 1997 08:36:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA16465; Wed, 22 Jan 1997 08:35:56 -0800 Received: from gauntlet.ht.com (he.ht.com [207.22.119.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA23745 for ; Wed, 22 Jan 1997 08:35:46 -0800 Received: by gauntlet.ht.com; id XAA13234; Thu, 23 Jan 1997 23:09:40 -0500 (EST) Received: from unknown(10.0.100.2) by gauntlet.ht.com via smap (3.2) id xma013230; Thu, 23 Jan 97 23:09:21 -0500 Received: from hf.ht.com by ht.com (950413.SGI.8.6.12/3.1.090690-High Techsplanations) id QAA07399; Wed, 22 Jan 1997 16:34:25 GMT Received: by hf.ht.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA03569; Wed, 22 Jan 1997 11:34:20 -0500 From: scott@ht.com (Scott McMillan) Message-Id: <199701221634.LAA03569@hf.ht.com> Subject: Re: Shadow and projected texture To: pere1@cluny.ensam.fr Date: Wed, 22 Jan 1997 11:34:20 -0500 (EST) Cc: info-performer@sgi.com In-Reply-To: <9701092006.ZM19841@unknown.zmail.host> from "pere1@cluny.ensam.fr" at Jan 9, 97 08:06:29 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Status: O > > Dear Scott, > > I thank you for your answer. Yes, I am still looking for an sample code of > two projected texture spotlights. But, the man pages says: > > If you could send me your sample code, I will sincerly thank you. > Can do. It would be MUCH easier if I could tar up the stuff and upload it to an FTP site. I have a pfC++/OpenGL example of two such spotlights of different colors (yellow and blue, I think) that rotate around a scene with three walls (2 of which are texture mapped) and a 3D model. The FOV of the spotlights are modulated. Colored line segments have been added to identify the two spotlight origins and directions. This example illustrates a few bugs (there are a few more in pf2.2): - the color of both spotlights projected onto textured surfaces are the same and the color modulates between the color specified for each light (it will change from yellow to blue and back as the lights are rotated in space). The color projected onto the non-textured surface is different but exhibits the same behaviour. - as the FOV of the light shrinks light appears behind the spotlight - on my High Impact (with Perf 2.0.2) one projected texture is dithered MUCH more than the other. I know that Remi was looking into these (any news?). > By reading the mail list of info-performer, I saw that you fight with > shadow since a long time,Scott , don't you win? For the record, I never got around to tackling shadows...I got bogged down with the bugs (in 2.2 and 2.0.2). If I am not mistaken, shadows in OpenGL will require that you do your own multipass rendering. I do not know how to accomplish this *yet*. If anybody out there has an example of ANY kind of multipass rendering on top of Performer I too would be grateful. > If somebody have another sample code with shadow perhaps in OpenGL(and > Irix 6.2), I will thank this man too. > > Thank you to Angus and Brian for their participation in: "Battle > against the shadow" > > Cheers, scott -- Scott McMillan | HT Medical, Inc. | Developing virtual environ- scott@ht.com | http://www.ht.com | ment medical and surgical Ph: 301-984-3706 | 6001 Montrose Rd., Ste. 902 | simulations and surgery Fax: 301-984-2104 | Rockville, MD 20852 | simulation creation tools. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 08:38:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA03722; Wed, 22 Jan 1997 08:37:39 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA03706; Wed, 22 Jan 1997 08:37:38 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA16529; Wed, 22 Jan 1997 08:37:28 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA24313 for ; Wed, 22 Jan 1997 08:37:26 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA11098; Wed, 22 Jan 1997 11:36:32 -0500 Date: Wed, 22 Jan 1997 11:36:32 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701221136.ZM11097@hotsauce.clubfed.sgi.com> In-Reply-To: dstipe@indy3.gstone.com (Daniel Stipe) "16mb or 64 mb max tex memory on RE2" (Jan 22, 7:42am) References: Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: dstipe@indy3.gstone.com (Daniel Stipe), info-performer@sgi.com Subject: Re: 16mb or 64 mb max tex memory on RE2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O The RM4 RE2 comes with 4megs of texture memory. The RM5 RE2 comes with 16MB of texture memory. 64MB of texture memory is available on the RM6 and RM7 for Infinite Reality graphics. Brian On Jan 22, 7:42am, Daniel Stipe wrote: > Subject: 16mb or 64 mb max tex memory on RE2 > Greetings Performers, > > An internal debaate has generated a question (basic) for the group. > Is the maximum texture memory on a Reality Engine 2 > 16mb or 64mb? > > Thanks, > > Dan > > Dan Stipe - Sr. Staff Member > Tele: (619) 974-6300 ext. 176 > > /\/\/\ GreyStone Technology, Inc. fax: (619) 974-6303 > / /\/\ \ 4950 Murphy Canyon Road e-mail: dstipe@gstone.com > \ \/\/ / San Diego, CA 92123-4325 web: http://www.gstone.com/ > \/\/\/ > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Daniel Stipe -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 08:38:35 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA03703; Wed, 22 Jan 1997 08:37:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA03687; Wed, 22 Jan 1997 08:37:15 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA16512; Wed, 22 Jan 1997 08:37:05 -0800 Received: from tuvok.mugu.navy.mil (tuvok.mugu.navy.mil [143.113.247.22]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA24258 for ; Wed, 22 Jan 1997 08:37:04 -0800 Received: from qmsmtpgw.mugu.navy.mil (qmsendgw.mugu.navy.mil) by tuvok.mugu.navy.mil (4.1/SMI-4.1) id AA22253; Wed, 22 Jan 97 08:37:52 PST Message-Id: Date: 22 Jan 1997 08:35:12 U From: "SCOTT OFRIEL" Subject: Re: Getting Gouraud Color To: "Angus Dorbie" , info-performer@sgi.com X-Mailer: Mail*Link SMTP-QM 3.0.2 Status: O Perhaps a little more explanation of our situation will help. Thanks for looking in. What I am doing is a 3D type bar graph where each bar represents a radar's range and/or doppler gate (range (x-axis) vs. doppler (y-axis)). The height of the gate (z-axis) represents the amplitude of the signal in that particular gate. I would like to have the amplitude of each gate related to color where blue is the lowest energy and red is the highest. The line I was referring to is the z-axis which is the amplitude axis and is Gouraud shaded from blue to red. For example, if a the max signal strength was 80db and a gates value was 80 db that bar would be Gouraud shaded from blue to red. If the signal strength for a gate was 40db the bar would have the same color as the z-axis, from blue to the color of at the mid-point of the z-axis. Thanks again, Scott O'Friel ------------------------------ Date: 1/21/97 7:33 PM To: OFRIEL, SCOTT From: Angus Dorbie This is a linear interpolation in screen space. Problems will arise if you want to calculate this for projected screen space and the line is in perspective because the colour interpolation is not perspective correct. This gets real fun when you clip the line because the colour gets shaded from the interpolated clipped line end colour. Could you give a little more info on why you want to do this so I can better understand how these issues might relate to you? Cheers, Angus. On Jan 21, 5:58pm, SCOTT OFRIEL wrote: > Subject: Getting Gouraud Color > Subject: Time: 5:42 PM > OFFICE MEMO Getting Gouraud Color Date: 1/21/97 > > Performer: > > Is it possible to get the RGB color value from any place between the two end > points of a Gouraud shaded line? The line is a pfGeoSet. > > Thank you, > Scott O'Friel > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from SCOTT OFRIEL ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com ------------------ RFC822 Header Follows ------------------ Received: by qmsmtpgw.mugu.navy.mil with SMTP;21 Jan 1997 19:21:28 U Received: from holodeck.csd.sgi.com by sgigate.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/940406a.SGI) id TAA24582; Tue, 21 Jan 1997 19:15:07 -0800 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id SAA24615; Tue, 21 Jan 1997 18:55:32 -0800 Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id SAA24599; Tue, 21 Jan 1997 18:55:31 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id SAA11726; Tue, 21 Jan 1997 18:55:20 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA00838; Tue, 21 Jan 1997 18:55:09 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id CAA19658; Wed, 22 Jan 1997 02:54:56 GMT From: "Angus Dorbie" Message-Id: <9701220254.ZM19656@bitch.reading.sgi.com> Date: Wed, 22 Jan 1997 02:54:56 +0000 In-Reply-To: "SCOTT OFRIEL" "Getting Gouraud Color" (Jan 21, 5:58pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "SCOTT OFRIEL" , info-performer@sgi.com Subject: Re: Getting Gouraud Color Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 08:46:11 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA03762; Wed, 22 Jan 1997 08:45:04 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA03746; Wed, 22 Jan 1997 08:45:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA16957; Wed, 22 Jan 1997 08:44:53 -0800 Received: from hades.sharp.co.uk (hades.sharp.co.uk [193.114.241.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA25620; Wed, 22 Jan 1997 08:44:31 -0800 Received: (from uucp@localhost) by hades.sharp.co.uk (8.6.12/8.6.12) id QAA25344; Wed, 22 Jan 1997 16:48:22 GMT Received: from sharp.co.uk by hades.sharp.co.uk via smap (RMS/1) id sma025342; Wed Jan 22 16:47:53 1997 Received: from inca.sle.sharp.co.uk (aardog) by sharp.co.uk (5.x/SMI-SVR4) id AA08986; Wed, 22 Jan 1997 16:43:14 GMT Message-Id: <32E6430F.259F@sharp.co.uk> Date: Wed, 22 Jan 1997 16:40:47 +0000 From: Graham Jones Reply-To: graham.jones@sharp.co.uk Organization: Sharp Laboratories of Europe X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: Angus Dorbie Cc: info-performer@sgi.com Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component References: <32E4DB77.3D55@sharp.co.uk> <9701210835.ZM8559@jimbo.rtset.co.il> <32E5E5CD.7D68@sharp.co.uk> <9701221151.ZM20307@bitch.reading.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Angus Dorbie wrote: > > On Jan 22, 10:02am, Graham Jones wrote: > > So I wouldn't be able to render the same object three times with > > three different colour matrices without downloading the texture > > three times (I'm trying to avoid all that data flying around the > > place). > > You want to use glColorTableSGI for this kind of thing. Angus, I could be barking up the wrong billboard but from a read of the manual and book on the colour table extension it would appear that I wouldn't be able to map Green to Red (for example), as I would if the colour matrix worked for texturing operations, but only remap, say, Green to a different Green. Useful as the extension may be I don't think I quite does what I need - please correct me if I'm wrong. Presumably if I can get the QUAD_TEXTURE_SELECT extension working for me and it extracts a component as an intensity texture, the extracted texture will render in to R, G and B. Graham. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 08:51:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA03805; Wed, 22 Jan 1997 08:50:11 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA03789; Wed, 22 Jan 1997 08:50:11 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA17453; Wed, 22 Jan 1997 08:50:00 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA26725 for ; Wed, 22 Jan 1997 08:49:55 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA12238; Wed, 22 Jan 97 10:48:05 -0500 Date: Wed, 22 Jan 97 10:48:05 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701221548.AA12238@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: Getting Gouraud Color Status: O On Jan 21, 5:58pm, SCOTT OFRIEL wrote: > Is it possible to get the RGB color value from any place between the two end > points of a Gouraud shaded line? The line is a pfGeoSet. Angus Dorbie replied: > This is a linear interpolation in screen space. > > Problems will arise if you want to calculate this for projected > screen space and the line is in perspective because the colour > interpolation is not perspective correct. This gets real fun > when you clip the line because the colour gets shaded from the > interpolated clipped line end colour. In fact, it's even worse than that - the colour of some point on a gouraud shaded line/polygon can be different on different channels. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 08:53:08 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA03831; Wed, 22 Jan 1997 08:51:04 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA03815; Wed, 22 Jan 1997 08:51:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA17501; Wed, 22 Jan 1997 08:50:52 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA26854; Wed, 22 Jan 1997 08:50:49 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA01228; Wed, 22 Jan 1997 16:50:41 GMT From: "Angus Dorbie" Message-Id: <9701221650.ZM1226@bitch.reading.sgi.com> Date: Wed, 22 Jan 1997 16:50:40 +0000 In-Reply-To: "SCOTT OFRIEL" "Re: Getting Gouraud Color" (Jan 22, 8:35am) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "SCOTT OFRIEL" , info-performer@sgi.com Subject: Re: Getting Gouraud Color Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O An assumption of linear interpolation would probably produce reasonable results for gouraud interpolation but you may want perspective correct interpolation for some viewpoints. The way to achieve perspective correct parameter mapping is to use a 1D texture and map the texture coordinate to the amplitude parameter. This is extremely powerfull when you consider that you can modify the texture image to map any scale in a linear manner to your vertical scale. This could for example include a suitable logaritmic scale markers, and all you have to do is specify texture coords instead of colours. You can band the data or use alpha to isolate a particular height and your still only using a 1D image. If you use a 2D image you could do all the above but map an additional parameter in your data and use alpha to clip to areas of this parameter. Cheers, Angus. On Jan 22, 8:35am, SCOTT OFRIEL wrote: > Subject: Re: Getting Gouraud Color > Perhaps a little more explanation of our situation will help. Thanks for > looking in. > > What I am doing is a 3D type bar graph where each bar represents a radar's > range and/or doppler gate (range (x-axis) vs. doppler (y-axis)). The height > of the gate (z-axis) represents the amplitude of the signal in that particular > gate. I would like to have the amplitude of each gate related to color where > blue is the lowest energy and red is the highest. The line I was referring > to is the z-axis which is the amplitude axis and is Gouraud shaded from blue > to red. > > For example, if a the max signal strength was 80db and a gates value was 80 db > that bar would be Gouraud shaded from blue to red. If the signal strength for > a gate was 40db the bar would have the same color as the z-axis, from blue to > the color of at the mid-point of the z-axis. > ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 09:11:39 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA04057; Wed, 22 Jan 1997 09:10:13 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA04039; Wed, 22 Jan 1997 09:10:12 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA18956; Wed, 22 Jan 1997 09:10:02 -0800 Received: from rainich.dcs.ed.ac.uk (rainich.dcs.ed.ac.uk [129.215.160.105]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00675 for ; Wed, 22 Jan 1997 09:09:57 -0800 Received: from calvay.dcs.ed.ac.uk by rainich.dcs.ed.ac.uk with SMTP (PP); Wed, 22 Jan 1997 17:08:33 +0000 Received: from localhost by calvay.dcs.ed.ac.uk; Wed, 22 Jan 1997 17:06:32 GMT Date: Wed, 22 Jan 1997 17:06:29 +0000 (GMT) From: Martin Reddy To: Peter Ebbesmeyer cc: Daniel Stipe , info-performer@sgi.com Subject: Re: 16mb or 64 mb max tex memory on RE2 In-Reply-To: <9701221721.ZM913@chakotay> Message-ID: Organisation: Department of Computer Science - University of Edinburgh MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O The RealityEngine2 can accommodate up to 4 RMs, so if you have four RM5's then that's 64 MB of texture memory in total. Martin. > > An internal debaate has generated a question (basic) for the group. > > Is the maximum texture memory on a Reality Engine 2 > > 16mb or 64mb? > > To my knowledge the Relity Engine2 graphics supports to kinds of raster > managers: > > RM4 (4 MB texture memory) > RM5 (16 MB texture memory) > > So the maximum amount of texture memory available on the RE2 is 16 MB +============================================================================+ | Martin Reddy Dept. of Computer Science | | University of Edinburgh | | e-mail : M.Reddy@ed.ac.uk Mayfield Road, EH9 3JZ | | http://www.dcs.ed.ac.uk/~mxr/ Tel : +44 131 650 5164 | +============================================================================+ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 09:24:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA04174; Wed, 22 Jan 1997 09:21:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA04158; Wed, 22 Jan 1997 09:21:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA19966; Wed, 22 Jan 1997 09:21:44 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA03087; Wed, 22 Jan 1997 09:21:37 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA01294; Wed, 22 Jan 1997 17:21:31 GMT From: "Angus Dorbie" Message-Id: <9701221721.ZM1292@bitch.reading.sgi.com> Date: Wed, 22 Jan 1997 17:21:31 +0000 In-Reply-To: Graham Jones "Re: Infinite Reality, Colour matrix and pfTexEnv Component" (Jan 22, 4:40pm) References: <32E4DB77.3D55@sharp.co.uk> <9701210835.ZM8559@jimbo.rtset.co.il> <32E5E5CD.7D68@sharp.co.uk> <9701221151.ZM20307@bitch.reading.sgi.com> <32E6430F.259F@sharp.co.uk> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: graham.jones@sharp.co.uk Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 4:40pm, Graham Jones wrote: > Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component > Angus, > > I could be barking up the wrong billboard but from a read of the manual > and book on the colour table extension it would appear that I wouldn't > be able to map Green to Red (for example), as I would if the colour > matrix worked for texturing operations, but only remap, say, Green to a > different Green. > > Useful as the extension may be I don't think I quite does what I need - > please correct me if I'm wrong. > > Presumably if I can get the QUAD_TEXTURE_SELECT extension working for me > and it extracts a component as an intensity texture, the extracted > texture will render in to R, G and B. You want to map a one component texture, which is what you have after the texture selection of a particular component, to an arbitrary colour, and colour tables can do this The table information can hold a complete rgba ramp for your intensity map, and this is without considering the glColorTableParameterSGI call which could probably also do what you need. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 09:54:12 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA04644; Wed, 22 Jan 1997 09:53:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA04626; Wed, 22 Jan 1997 09:53:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA23381; Wed, 22 Jan 1997 09:52:56 -0800 Received: from buitre.madrid.sgi.com ([144.253.243.6]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10703 for ; Wed, 22 Jan 1997 09:52:54 -0800 Received: by buitre.madrid.sgi.com (940816.SGI.8.6.9/930416.SGI) id SAA23700; Wed, 22 Jan 1997 18:50:08 -0100 From: "Luis Ignacio Miranda" Message-Id: <9701221850.ZM23698@buitre.madrid.sgi.com> Date: Wed, 22 Jan 1997 18:50:08 +0100 In-Reply-To: Martin Reddy "Re: 16mb or 64 mb max tex memory on RE2" (Jan 22, 5:06pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Martin Reddy , Peter Ebbesmeyer Subject: Re: 16mb or 64 mb max tex memory on RE2 Cc: Daniel Stipe , info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Martin, When you add RM's to whatever system (RE2 or iR) you increase the pixel fill rate, but NOT the texture memory. It doesn't matter the number of RM's, if you have RM4's you have 4 MB of texture memory and if you have RM5's you have 16 MB. Of course, RM4's and RM5's can not be mixed in a single system. Hope to help Nacho On Jan 22, 5:06pm, Martin Reddy wrote: > Subject: Re: 16mb or 64 mb max tex memory on RE2 > > The RealityEngine2 can accommodate up to 4 RMs, so if you have four RM5's > then that's 64 MB of texture memory in total. > > Martin. > > > > An internal debaate has generated a question (basic) for the group. > > > Is the maximum texture memory on a Reality Engine 2 > > > 16mb or 64mb? > > > > To my knowledge the Relity Engine2 graphics supports to kinds of raster > > managers: > > > > RM4 (4 MB texture memory) > > RM5 (16 MB texture memory) > > > > So the maximum amount of texture memory available on the RE2 is 16 MB > > > +============================================================================+ > | Martin Reddy Dept. of Computer Science | > | University of Edinburgh | > | e-mail : M.Reddy@ed.ac.uk Mayfield Road, EH9 3JZ | > | http://www.dcs.ed.ac.uk/~mxr/ Tel : +44 131 650 5164 | > +============================================================================+ > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Martin Reddy -- ******************************************************************************* * Luis Ignacio Miranda Edificio "Santa Engracia 120" * * Silicon Graphics, S.A. Plaza del Descubridor Diego de Ordas,3 * * Systems Engineering Division 28003 MADRID SPAIN * * e-mail : lmiranda@madrid.sgi.com Telephone ++ 34 1 4429077 * * v-mail : x57598 Fax ++ 34 1 4420150 * ******************************************************************************* ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 09:50:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA04556; Wed, 22 Jan 1997 09:48:24 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA04540; Wed, 22 Jan 1997 09:48:23 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA22913; Wed, 22 Jan 1997 09:48:12 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09607 for ; Wed, 22 Jan 1997 09:48:11 -0800 Received: from q-ryche.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id JAA22909; Wed, 22 Jan 1997 09:48:10 -0800 Received: by q-ryche.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id JAA02088; Wed, 22 Jan 1997 09:48:19 -0800 Date: Wed, 22 Jan 1997 09:48:19 -0800 From: derekj@q-ryche (Derek Jewhurst) Message-Id: <9701220948.ZM2086@q-ryche.csd.sgi.com> In-Reply-To: Martin Reddy "Re: 16mb or 64 mb max tex memory on RE2" (Jan 22, 5:06pm) References: X-Face: >F@N', Peter Ebbesmeyer Subject: Re: 16mb or 64 mb max tex memory on RE2 Cc: Daniel Stipe , info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 5:06pm, Martin Reddy wrote: > Subject: Re: 16mb or 64 mb max tex memory on RE2 > > The RealityEngine2 can accommodate up to 4 RMs, so if you have four RM5's > then that's 64 MB of texture memory in total. Addtional RM's do not mean additional texture memory. Each RM holds a copy of the textures so you are still limited to 4MB on a RM4 and 16MB on a RM5. -Derek -- Derek Jewhurst |\ Member Technical Staff, Global Technology Support | \____oo_ Silicon Graphics Inc. ((__| /___> derekj@csd.sgi.com | // |// ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 09:55:59 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA04679; Wed, 22 Jan 1997 09:54:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA04663; Wed, 22 Jan 1997 09:54:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA23593; Wed, 22 Jan 1997 09:54:44 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11104 for ; Wed, 22 Jan 1997 09:54:43 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA11689; Wed, 22 Jan 1997 12:53:28 -0500 Date: Wed, 22 Jan 1997 12:53:28 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701221253.ZM11688@hotsauce.clubfed.sgi.com> In-Reply-To: Graham Jones "Re: Infinite Reality, Colour matrix and pfTexEnv Component" (Jan 22, 4:40pm) References: <32E4DB77.3D55@sharp.co.uk> <9701210835.ZM8559@jimbo.rtset.co.il> <32E5E5CD.7D68@sharp.co.uk> <9701221151.ZM20307@bitch.reading.sgi.com> <32E6430F.259F@sharp.co.uk> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: graham.jones@sharp.co.uk, Angus Dorbie Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Brian, Someone mentioned to me that the Impact use 4D textures to map one color space into another, but I never got the details of how to do it. That was primarily concerning video and doing RGBA to CMYK conversions. Their is an extension that will read textures as ABGR instead of RGBA. So I suspect what you want to do is possible. In imagevision library this is an easy task you just switch the channels as you copy them. Hold on I found what I was looking for what you want is glPixelTexGenSGIX (3G) the man page states this extension can be used as a very accurate colorspace converter. Brian On Jan 22, 4:40pm, Graham Jones wrote: > Subject: Re: Infinite Reality, Colour matrix and pfTexEnv Component > Angus Dorbie wrote: > > > > On Jan 22, 10:02am, Graham Jones wrote: > > > So I wouldn't be able to render the same object three times with > > > three different colour matrices without downloading the texture > > > three times (I'm trying to avoid all that data flying around the > > > place). > > > > You want to use glColorTableSGI for this kind of thing. > > Angus, > > I could be barking up the wrong billboard but from a read of the manual > and book on the colour table extension it would appear that I wouldn't > be able to map Green to Red (for example), as I would if the colour > matrix worked for texturing operations, but only remap, say, Green to a > different Green. > > Useful as the extension may be I don't think I quite does what I need - > please correct me if I'm wrong. > > Presumably if I can get the QUAD_TEXTURE_SELECT extension working for me > and it extracts a component as an intensity texture, the extracted > texture will render in to R, G and B. > > Graham. > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Graham Jones -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 09:51:36 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA04596; Wed, 22 Jan 1997 09:50:31 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA04580; Wed, 22 Jan 1997 09:50:30 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA23104; Wed, 22 Jan 1997 09:50:20 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10053; Wed, 22 Jan 1997 09:50:17 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA01561; Wed, 22 Jan 1997 17:50:14 GMT From: "Angus Dorbie" Message-Id: <9701221750.ZM1559@bitch.reading.sgi.com> Date: Wed, 22 Jan 1997 17:50:13 +0000 In-Reply-To: steve@mred.bgm.link.com (Steve Baker) "Re: Getting Gouraud Color" (Jan 22, 10:48am) References: <9701221548.AA12238@mred.bgm.link.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: steve@mred.bgm.link.com (Steve Baker), info-performer@sgi.com Subject: Re: Getting Gouraud Color Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 10:48am, Steve Baker wrote: > Subject: Re: Getting Gouraud Color > On Jan 21, 5:58pm, SCOTT OFRIEL wrote: > > > Is it possible to get the RGB color value from any place between the two end > > points of a Gouraud shaded line? The line is a pfGeoSet. > > Angus Dorbie replied: > > > This is a linear interpolation in screen space. > > > > Problems will arise if you want to calculate this for projected > > screen space and the line is in perspective because the colour > > interpolation is not perspective correct. This gets real fun > > when you clip the line because the colour gets shaded from the > > interpolated clipped line end colour. > > In fact, it's even worse than that - the colour of some point > on a gouraud shaded line/polygon can be different on different > channels. Yep, you can experience some shading discontinuities across channels but this is really the result of the same effect. But the worseness is even more worser than the worsening you mention :-). If you have lighting calculations they move around as a result of the clipping and can produce obvious anomalies, especially if you have specular materials. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 10:00:34 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA04743; Wed, 22 Jan 1997 09:58:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA04727; Wed, 22 Jan 1997 09:58:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA23933; Wed, 22 Jan 1997 09:58:44 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12167 for ; Wed, 22 Jan 1997 09:58:43 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA11696; Wed, 22 Jan 1997 12:57:39 -0500 Date: Wed, 22 Jan 1997 12:57:39 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701221257.ZM11695@hotsauce.clubfed.sgi.com> In-Reply-To: Martin Reddy "Re: 16mb or 64 mb max tex memory on RE2" (Jan 22, 5:06pm) References: Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Martin Reddy , Peter Ebbesmeyer Subject: Re: 16mb or 64 mb max tex memory on RE2 Cc: Daniel Stipe , info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O No its still only 16MB of texture memory, you just have 4 RMs doing the texturing of the scene instead of one. The speed changes not the capacity. Brian On Jan 22, 5:06pm, Martin Reddy wrote: > Subject: Re: 16mb or 64 mb max tex memory on RE2 > > The RealityEngine2 can accommodate up to 4 RMs, so if you have four RM5's > then that's 64 MB of texture memory in total. > > Martin. > > > > An internal debaate has generated a question (basic) for the group. > > > Is the maximum texture memory on a Reality Engine 2 > > > 16mb or 64mb? > > > > To my knowledge the Relity Engine2 graphics supports to kinds of raster > > managers: > > > > RM4 (4 MB texture memory) > > RM5 (16 MB texture memory) > > > > So the maximum amount of texture memory available on the RE2 is 16 MB > > > +============================================================================+ > | Martin Reddy Dept. of Computer Science | > | University of Edinburgh | > | e-mail : M.Reddy@ed.ac.uk Mayfield Road, EH9 3JZ | > | http://www.dcs.ed.ac.uk/~mxr/ Tel : +44 131 650 5164 | > +============================================================================+ > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Martin Reddy -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 09:57:27 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA04703; Wed, 22 Jan 1997 09:56:19 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA04687; Wed, 22 Jan 1997 09:56:18 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA23734; Wed, 22 Jan 1997 09:56:02 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11347 for ; Wed, 22 Jan 1997 09:56:01 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id JAA23723; Wed, 22 Jan 1997 09:56:01 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id JAA01907; Wed, 22 Jan 1997 09:56:10 -0800 From: "Rob Jenkins" Message-Id: <9701220956.ZM1905@quid.csd.sgi.com> Date: Wed, 22 Jan 1997 09:56:10 -0800 In-Reply-To: Martin Reddy "Re: 16mb or 64 mb max tex memory on RE2" (Jan 22, 5:06pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Martin Reddy , Peter Ebbesmeyer Subject: Re: 16mb or 64 mb max tex memory on RE2 Cc: Daniel Stipe , info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 5:06pm, Martin Reddy wrote: > Subject: Re: 16mb or 64 mb max tex memory on RE2 > > The RealityEngine2 can accommodate up to 4 RMs, so if you have four RM5's > then that's 64 MB of texture memory in total. > > Martin. That's true although actually more RMs doesn't give you more memory as the textures are duplicated across each RM. The big benefits of more RMs are bigger frame buffer ( deeper pixels ) and greatly increased texture and fill bandwidth. The biggest single physical texture is still limited by the size of a single RM. Each RM is divided into 2 banks so you can load a single texture up to 1xRMsize/2 Cheers Rob -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 10:08:53 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA04829; Wed, 22 Jan 1997 10:07:37 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA04813; Wed, 22 Jan 1997 10:07:36 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA25028; Wed, 22 Jan 1997 10:07:25 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14402 for ; Wed, 22 Jan 1997 10:07:25 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA28766; Wed, 22 Jan 1997 10:07:24 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA10102; Wed, 22 Jan 1997 10:07:22 -0800 From: "Sharon Clay" Message-Id: <9701221007.ZM10100@rose.asd.sgi.com> Date: Wed, 22 Jan 1997 10:07:22 -0800 In-Reply-To: "Nicolas Gauvin" "Re: Putting attr list into geosets" (Jan 22, 10:54am) References: <9701221054.ZM8857@christine.cae.ca> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Nicolas Gauvin" , info-performer@sgi.com Subject: Re: Putting attr list into geosets Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 22, 10:54am, Nicolas Gauvin wrote: > Subject: Re: Putting attr list into geosets ->From guest@holodeck.csd.sgi.com Wed Jan 22 08:50:17 1997 -> ->You shouldn't need to call pfGSetAttr again to put the list back. ->pfGetGSetAttrLists gives you the pointers to the actual list, not a copy of ->them. Once you have the pointer, simply modify its content and thats it. The ->geoset will be aware of the changes. We will use the new data for drawing but we will not automatically compute new isect or culling bboxes cached on the gset. So, You may want to fix a bbox statically that is big enough to hold the possible transformed values with pfGSetBBox (also the safest/most efficient thing to do with the MP cyclebuffer soln.) or else force the bbox to be recomputed with a NULL box to pfGSetBBox() or the full icset cache with pfGSetIsectMask() (yes, we need more direct API for that). src. -> ->However the safest way to do this sort of thing is to use a pfCycleBuffer ->for the attribute list you intend to modify. This way you will be frame ->accurate when multiprocessing. -> ->The man page of pfCycleBuffer contains a simple example for this: -> -> pfVec3 *prevVerts, *curVerts; -> -> pfInit(); -> -> pfMultiprocess(mpMode); -> -> /* -> * This calls pfCBufferConfig() with the number of buffers -> * appropriate to the multiprocessing mode. -> */ -> pfConfig(); -> -> verts = pfNewCBuffer(sizeof(pfVec3) * numVerts, pfGetSharedArena()); -> pfGSetAttr(gset, PFGS_COORD3, PFGS_PER_VERTEX, verts, NULL); -> -> while(!done) -> { -> curVerts = pfGetCurCBufferData(verts); -> -> /* Compute new positions of mass-spring system */ -> for (i=0; i curVerts[i] = prevVerts[i] + netForceVector * deltaTime; -> -> /* Indicate that 'verts' has changed */ -> pfCBufferChanged(verts); -> -> prevVerts = curVerts; -> -> /* This calls pfCBufferFrame() */ -> pfFrame(); -> } -> ->-- ->Nicolas Gauvin CAE Electronics Ltd., 8585 Cote De Liesse ->Software Developer Saint-Laurent, Quebec, Canada, H4L-4X4 ->3-D Graphics Applications tel: +1 514 341 2000 extension 2275 ->nicolas@cae.ca fax: +1 514 340 5496 ->======================================================================= ->List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ -> Submissions: info-performer@sgi.com -> Admin. requests: info-performer-request@sgi.com -> +>---- End of excerpt from Nicolas Gauvin -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 10:26:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA05142; Wed, 22 Jan 1997 10:25:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA05126; Wed, 22 Jan 1997 10:25:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA27019; Wed, 22 Jan 1997 10:25:14 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18872; Wed, 22 Jan 1997 10:25:09 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA01670; Wed, 22 Jan 1997 18:24:49 GMT From: "Angus Dorbie" Message-Id: <9701221824.ZM1668@bitch.reading.sgi.com> Date: Wed, 22 Jan 1997 18:24:49 +0000 In-Reply-To: "Luis Ignacio Miranda" "Re: 16mb or 64 mb max tex memory on RE2" (Jan 22, 6:50pm) References: <9701221850.ZM23698@buitre.madrid.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Luis Ignacio Miranda" , Martin Reddy , Peter Ebbesmeyer Subject: Re: 16mb or 64 mb max tex memory on RE2 Cc: Daniel Stipe , info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 6:50pm, Luis Ignacio Miranda wrote: > ... Of course, RM4's and RM5's can not be mixed in a single system. > Yes they can, the RM5's just behave like RM4's. On iR you cannot mix RM6-16s with RM6-64s. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 14:16:52 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA06651; Wed, 22 Jan 1997 14:13:40 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA06635; Wed, 22 Jan 1997 14:13:39 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA20946; Wed, 22 Jan 1997 14:13:15 -0800 Received: from gauntlet.ht.com (he.ht.com [207.22.119.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA16169 for ; Wed, 22 Jan 1997 14:13:06 -0800 Received: by gauntlet.ht.com; id EAA01602; Fri, 24 Jan 1997 04:46:58 -0500 (EST) Received: from unknown(10.0.100.2) by gauntlet.ht.com via smap (3.2) id xma001596; Fri, 24 Jan 97 04:46:35 -0500 Received: from hf.ht.com by ht.com (950413.SGI.8.6.12/3.1.090690-High Techsplanations) id WAA10275; Wed, 22 Jan 1997 22:11:39 GMT Received: by hf.ht.com (950413.SGI.8.6.12/940406.SGI.AUTO) id RAA04292; Wed, 22 Jan 1997 17:10:06 -0500 From: scott@ht.com (Scott McMillan) Message-Id: <199701222210.RAA04292@hf.ht.com> Subject: Re: Shadow and projected texture To: craig@nvg.aircrew.asu.edu (Craig A. Vrana) Date: Wed, 22 Jan 1997 17:10:06 -0500 (EST) Cc: pere1@cluny.ensam.fr, info-performer@sgi.com In-Reply-To: <9701221048.ZM3222@nvg.aircrew.asu.edu> from "Craig A. Vrana" at Jan 22, 97 10:48:34 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Status: O The two spotlight projected texture demo (uncompiled) can be found at: ftp://ftp.ht.com/outgoing/two_spots.tar.gz I have only compiled and tested it on a High Impact/Irix 6.2/pf2.0.2/O32. Let me know if problems occur, scott -- Scott McMillan | HT Medical, Inc. | Developing virtual environ- scott@ht.com | http://www.ht.com | ment medical and surgical Ph: 301-984-3706 | 6001 Montrose Rd., Ste. 902 | simulations and surgery Fax: 301-984-2104 | Rockville, MD 20852 | simulation creation tools. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 15:15:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA07101; Wed, 22 Jan 1997 15:13:57 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA07085; Wed, 22 Jan 1997 15:13:56 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA26567; Wed, 22 Jan 1997 15:13:25 -0800 Received: from merki0.connect.com.au (merki0.connect.com.au [192.189.54.98]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA00987 for ; Wed, 22 Jan 1997 15:12:50 -0800 Received: (from uucp@localhost) by merki0.connect.com.au id KAA08023 (8.7.6h/IDA-1.6 for info-performer@sgi.com); Thu, 23 Jan 1997 10:12:46 +1100 (EST) >Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA12263 (5.65c/IDA-1.5 for ); Thu, 23 Jan 1997 09:36:27 +1100 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA12263 (5.65c/IDA-1.5 for ); Thu, 23 Jan 1997 09:36:27 +1100 Received: from murad (murad [8.0.0.108]) by aggro with SMTP id IAA14409 (8.6.12/IDA-1.6 for ); Thu, 23 Jan 1997 08:53:59 +1000 Received: from localhost by murad (5.65) id AA23573; Thu, 23 Jan 1997 10:06:51 +1100 Date: Thu, 23 Jan 1997 10:18:03 +1112 (EST) From: Troy Stephen X-Sender: troys@murad To: Performer Subject: Re: Getting Gouraud Color In-Reply-To: <9701221750.ZM1559@bitch.reading.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Wed, 22 Jan 1997, Angus Dorbie wrote: ..snip.. > > Yep, you can experience some shading discontinuities across > channels but this is really the result of the same effect. I think we may be getting an artifact related to this on our sky polygons with a multichannel configuration. So, my question is, when a line is clipped to a viewing frustum how is the color of the resulting clipped line calculated? For example: |<------- within channel ------------->| .----------------.--------------------------------------. white (clipped point) black what color is used for the clipped point when gouraud shading is used? > > But the worseness is even more worser than the worsening you > mention :-). If you have lighting calculations they > move around as a result of the clipping and can produce obvious > anomalies, especially if you have specular materials. > eek. I'm glad my sky polygons aren't lit! Troy Stephen. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 15:25:51 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA07173; Wed, 22 Jan 1997 15:24:13 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA07157; Wed, 22 Jan 1997 15:24:12 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA27349; Wed, 22 Jan 1997 15:24:02 -0800 Received: from octagon.tacom.army.mil (octagon.tacom.army.mil [147.240.16.254]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA03219; Wed, 22 Jan 1997 15:23:56 -0800 From: tidrowd@cc.tacom.army.mil Received: from cc.tacom.army.mil by octagon.tacom.army.mil (8.8.4/8.8.4-kbp) with SMTP id SAA04369; Wed, 22 Jan 1997 18:18:41 -0500 (EST) Received: from ccMail by cc.tacom.army.mil (IMA Internet Exchange 1.04b) id 2e69f600; Wed, 22 Jan 97 18:14:40 -0500 Mime-Version: 1.0 Date: Wed, 22 Jan 1997 18:00:55 -0500 Message-ID: <2e69f600@cc.tacom.army.mil> To: info-performer@sgi.com, brian@sgi.com (Brian Furtaw) Subject: Re[2]: 16mb or 64 mb max tex memory on RE2 Content-Type: multipart/mixed; boundary="IMA.Boundary.088479358" Status: O This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.088479358 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part What's the diff between a RM6 and a RM7? First time I've heard of a RM7. Don Tidrow Visual Simulation Developer US Army TACOM ______________________________ Reply Separator _________________________________ Subject: Re: 16mb or 64 mb max tex memory on RE2 Author: brian@sgi.com (Brian Furtaw) at TWLAN-SMTP Date: 1/22/97 11:36 AM The RM4 RE2 comes with 4megs of texture memory. The RM5 RE2 comes with 16MB of texture memory. 64MB of texture memory is available on the RM6 and RM7 for Infinite Reality graphics. Brian On Jan 22, 7:42am, Daniel Stipe wrote: > Subject: 16mb or 64 mb max tex memory on RE2 > Greetings Performers, > > An internal debaate has generated a question (basic) for the group. > Is the maximum texture memory on a Reality Engine 2 > 16mb or 64mb? > > Thanks, > > Dan > > Dan Stipe - Sr. Staff Member > Tele: (619) 974-6300 ext. 176 > > /\/\/\ GreyStone Technology, Inc. fax: (619) 974-6303 > / /\/\ \ 4950 Murphy Canyon Road e-mail: dstipe@gstone.com > \ \/\/ / San Diego, CA 92123-4325 web: http://www.gstone.com/ > \/\/\/ > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Daniel Stipe -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com --IMA.Boundary.088479358-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 16:01:19 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA07386; Wed, 22 Jan 1997 15:58:57 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA07370; Wed, 22 Jan 1997 15:58:56 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA00911; Wed, 22 Jan 1997 15:58:45 -0800 Received: from blast.minneapolis.sgi.com ([169.238.230.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA11499 for ; Wed, 22 Jan 1997 15:58:44 -0800 Received: by blast.minneapolis.sgi.com (940816.SGI.8.6.9/930416.SGI) for info-performer@sgi.com id RAA09080; Wed, 22 Jan 1997 17:58:25 -0600 Date: Wed, 22 Jan 1997 17:58:25 -0600 From: watters@blast.minneapolis.sgi.com (Sam Watters) Message-Id: <199701222358.RAA09080@blast.minneapolis.sgi.com> Apparently-To: info-performer@sgi.com Status: O unsubsribe watters@minneapolis.sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 17:26:40 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA07962; Wed, 22 Jan 1997 17:24:51 -0800 Return-Path: Received: from kern.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA07946; Wed, 22 Jan 1997 17:24:51 -0800 Received: by kern.csd.sgi.com (940816.SGI.8.6.9/911001.SGI) for info-performer@holodeck.csd.sgi.com id RAA24701; Wed, 22 Jan 1997 17:24:52 -0800 From: indu@kern (Indu Bingham) Message-Id: <199701230124.RAA24701@kern.csd.sgi.com> Subject: test To: info-performer Date: Wed, 22 Jan 1997 17:24:52 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 83 Status: O -- Indu Bingham http://reality.sgi.com/employees/indu_csd/indu.html indu@sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 17:25:34 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA07940; Wed, 22 Jan 1997 17:23:29 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA07924; Wed, 22 Jan 1997 17:23:28 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA07597; Wed, 22 Jan 1997 17:23:19 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA28651 for ; Wed, 22 Jan 1997 17:23:18 -0800 Received: from kern.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for <@rock.csd.sgi.com:info-performer@sgi.com> id RAA07594; Wed, 22 Jan 1997 17:23:18 -0800 Received: by kern.csd.sgi.com (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.com id RAA24687; Wed, 22 Jan 1997 17:23:28 -0800 From: indu@kern (Indu Bingham) Message-Id: <199701230123.RAA24687@kern.csd.sgi.com> Subject: test To: info-performer@sgi.com Date: Wed, 22 Jan 1997 17:23:27 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 83 Status: O -- Indu Bingham http://reality.sgi.com/employees/indu_csd/indu.html indu@sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 18:31:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id SAA08520; Wed, 22 Jan 1997 18:30:07 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id SAA08504; Wed, 22 Jan 1997 18:30:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id SAA11737; Wed, 22 Jan 1997 18:30:00 -0800 Received: from wolfe.net (mail1.wolfe.net [204.157.98.11]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA11361 for ; Wed, 22 Jan 1997 18:29:58 -0800 Received: from gonzo.wolfenet.com (moore@gonzo.wolfenet.com [204.157.98.2]) by wolfe.net (8.8.0/8.8.0) with ESMTP id RAA16013; Wed, 22 Jan 1997 17:33:45 -0800 (PST) From: Timothy Moore Received: (from moore@localhost) by gonzo.wolfenet.com (8.8.3/8.7) id RAA06292; Wed, 22 Jan 1997 17:32:00 -0800 (PST) Date: Wed, 22 Jan 1997 17:32:00 -0800 (PST) Message-Id: <199701230132.RAA06292@gonzo.wolfenet.com> To: troys@wormald.com.au CC: info-performer@sgi.com In-reply-to: Troy Stephen's message of Thu, 23 Jan 1997 10:18:03 +1112 (EST) Subject: Re: Getting Gouraud Color Status: O Date: Thu, 23 Jan 1997 10:18:03 +1112 (EST) From: Troy Stephen On Wed, 22 Jan 1997, Angus Dorbie wrote: ..snip.. > > Yep, you can experience some shading discontinuities across > channels but this is really the result of the same effect. I think we may be getting an artifact related to this on our sky polygons with a multichannel configuration. what color is used for the clipped point when gouraud shading is used? > > But the worseness is even more worser than the worsening you > mention :-). If you have lighting calculations they > move around as a result of the clipping and can produce obvious > anomalies, especially if you have specular materials. > eek. I'm glad my sky polygons aren't lit! Do these artifacts occur in OpenGL? I thought that the spec required shading and lighting calculations be done using the unclipped vertices. Tim ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 22 19:30:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id TAA08735; Wed, 22 Jan 1997 19:29:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id TAA08719; Wed, 22 Jan 1997 19:29:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id TAA14519; Wed, 22 Jan 1997 19:29:30 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA21162; Wed, 22 Jan 1997 19:29:28 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA03339; Wed, 22 Jan 1997 22:28:28 -0500 Date: Wed, 22 Jan 1997 22:28:28 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701222228.ZM3338@hotsauce.clubfed.sgi.com> In-Reply-To: tidrowd@cc.tacom.army.mil "Re[2]: 16mb or 64 mb max tex memory on RE2" (Jan 22, 6:00pm) References: <2e69f600@cc.tacom.army.mil> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: tidrowd@cc.tacom.army.mil, info-performer@sgi.com, brian@sgi.com (Brian Furtaw) Subject: Re: Re[2]: 16mb or 64 mb max tex memory on RE2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 6:00pm, tidrowd@cc.tacom.army.mil wrote: > Subject: Re[2]: 16mb or 64 mb max tex memory on RE2 > > What's the diff between a RM6 and a RM7? First time I've heard of a RM7. > > > Don Tidrow > Visual Simulation Developer > US Army TACOM > > > ______________________________ Reply Separator _________________________________ > Subject: Re: 16mb or 64 mb max tex memory on RE2 > Author: brian@sgi.com (Brian Furtaw) at TWLAN-SMTP > Date: 1/22/97 11:36 AM > > > The RM4 RE2 comes with 4megs of texture memory. The RM5 RE2 comes with 16MB of > texture memory. 64MB of texture memory is available on the RM6 and RM7 for > Infinite Reality graphics. > > Brian > > On Jan 22, 7:42am, Daniel Stipe wrote: > > Subject: 16mb or 64 mb max tex memory on RE2 > > Greetings Performers, > > > > An internal debaate has generated a question (basic) for the group. > > Is the maximum texture memory on a Reality Engine 2 > > 16mb or 64mb? > > > > Thanks, > > > > Dan > > > > Dan Stipe - Sr. Staff Member > > Tele: (619) 974-6300 ext. 176 > > > > /\/\/\ GreyStone Technology, Inc. fax: (619) 974-6303 > > / /\/\ \ 4950 Murphy Canyon Road e-mail: dstipe@gstone.com > > \ \/\/ / San Diego, CA 92123-4325 web: http://www.gstone.com/ > > \/\/\/ > > > > > > ======================================================================= > > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > > Submissions: info-performer@sgi.com > > Admin. requests: info-performer-request@sgi.com > >-- End of excerpt from Daniel Stipe > > > > -- > o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o > > Brian Furtaw (brian@sgi.com) > VisSim Technical Consultant > 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 > Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from tidrowd@cc.tacom.army.mil The RM7 fits in an Onyx2 and an RM6 fits in an Onyx. Take a look at the new kid on the block. http://www.sgi.com/Products/ I want one. Brian -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 01:17:05 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA09772; Thu, 23 Jan 1997 01:15:42 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA09756; Thu, 23 Jan 1997 01:15:41 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA27580; Thu, 23 Jan 1997 01:15:30 -0800 Received: from cluny.ensam.fr (pictel.cluny.ensam.fr [193.50.253.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA06843; Thu, 23 Jan 1997 01:15:21 -0800 From: pere1@cluny.ensam.fr Received: from VIDEO3 by cluny.ensam.fr (SMI-8.6/SMI-SVR4) id KAA16096; Thu, 23 Jan 1997 10:16:10 GMT Received: by VIDEO3 (940816.SGI.8.6.9/930416.SGI) id KAA25176; Thu, 23 Jan 1997 10:15:59 GMT Message-Id: <9701231015.ZM25174@unknown.zmail.host> Date: Thu, 23 Jan 1997 10:15:59 +0000 In-Reply-To: blythe@banshee.asd.sgi.com (David Blythe) "Re: Shadow and projected texture" (Jan 22, 4:00pm) References: <199701230000.QAA14307@banshee.asd.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: blythe@banshee.asd.sgi.com (David Blythe) Subject: Re: Shadow and projected texture Cc: info-performer@sgi.com, PERE@cluny.ensam.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Thanks to you David, You don't cc your mail : if I could > OpenGL example > > http://www.sgi.com/Technology/OpenGL/advanced/tomcat/shadowmap.c > > -db I will try to test this sample : I must install GLUT too, I see. Scott, try this too! The first to win "Battle against shadows" win virtual (french) champagne. See you soon Christian -- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 02:20:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA09971; Thu, 23 Jan 1997 02:18:53 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA09955; Thu, 23 Jan 1997 02:18:53 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA29368; Thu, 23 Jan 1997 02:18:42 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA14946; Thu, 23 Jan 1997 02:18:39 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id KAA03000; Thu, 23 Jan 1997 10:18:35 GMT From: "Angus Dorbie" Message-Id: <9701231018.ZM2998@bitch.reading.sgi.com> Date: Thu, 23 Jan 1997 10:18:34 +0000 In-Reply-To: tidrowd@cc.tacom.army.mil "Re[2]: 16mb or 64 mb max tex memory on RE2" (Jan 22, 6:00pm) References: <2e69f600@cc.tacom.army.mil> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com, tidrowd@cc.tacom.army.mil Subject: Re: 16mb or 64 mb max tex memory on RE2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 22, 6:00pm, tidrowd@cc.tacom.army.mil wrote: > Subject: Re[2]: 16mb or 64 mb max tex memory on RE2 > > What's the diff between a RM6 and a RM7? First time I've heard of a > The RM6 is the ONYX Infinite Reality Raster Manager the RM7 is the ONYX2 Infinite Reality Raster Manager which also has the 16 or 64 Mb texture options and 80Mb framebuffer memory. There's also the RM8 which is a cost reduced Raster Manager for ONYX2 Reality with 40Mb of framebuffer memory and reduced textured fill performance. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 02:43:20 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA10066; Thu, 23 Jan 1997 02:42:01 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA10050; Thu, 23 Jan 1997 02:42:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA29947; Thu, 23 Jan 1997 02:41:50 -0800 Received: from nvsgi1.netvision.net.il (nvsgi1.NetVision.net.il [194.90.1.31]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA17989 for ; Thu, 23 Jan 1997 02:41:43 -0800 Received: from streptacocus (ts013p5.pop9a.netvision.net.il [194.90.11.241]) by nvsgi1.netvision.net.il (8.7.5/8.7.3) with SMTP id MAA28990 for ; Thu, 23 Jan 1997 12:42:26 +0200 (IST) Sender: internet@nvsgi1.netvision.net.il Message-ID: <32E735D7.41C6@netvision.net.il> Date: Thu, 23 Jan 1997 11:57:23 +0200 From: Orad Hi-Tec Systems X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Re: 16mb or 64 mb max tex memory on RE2 References: <9701221850.ZM23698@buitre.madrid.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Luis Ignacio Miranda wrote: From guest Thu Jan 23 04:11:25 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA10244; Thu, 23 Jan 1997 04:09:54 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA10228; Thu, 23 Jan 1997 04:09:53 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA02684; Thu, 23 Jan 1997 04:09:43 -0800 Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA29718 for ; Thu, 23 Jan 1997 04:09:37 -0800 From: inca@public.bta.net.cn Received: (from inca@localhost) by public.bta.net.cn (8.6.8.1/8.6.9) id UAA00676; Thu, 23 Jan 1997 20:09:28 +0800 Date: Thu, 23 Jan 1997 20:09:28 +0800 Message-Id: <199701231209.UAA00676@public.bta.net.cn> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: pfPipeWindows & Texture on iR To: info-performer@sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Thanks for all reply! +>Angus Dorbie wrote: >>Looks great, what is it? It's a simulator of telescope used in space airship. spaceman view earth through it and square away. it has separatory 9 perspectives with fixed relation. >>Why can't you avoid multiple windows? >>A few overlapping channels and the use of arbitrary clip planes >>or maybe just stencil operations would work. >> ... i went astray! the way is Shape Extension's XShapeCombineMask clip in X window level. so i must use three windows: one for center, one for up-down-left-right and one for 4-corners. i'm new in GL/Performer(3 months) and leave stencil out of consideration. The suggestion get me out of trouble, Thank you very much indeed! Brian wrote: >I am impressed it looks like a view out of the bridge of the Millenium Falcon. >You could do this same effect with one viewport (pfChannel,pfPipe) just use a >postdraw callback that applies the light blue mask after the Channel has >rendered. It will give you a lot more graphics bandwidth to do other effects. the snap.rgb shows normal state(hpr=0.0f) only. i don't think can do with one viewport. viewpor1 viewpor2 viewport0 | \ / \ | / \ / \ | / \ / \ | / \ / \ | / \ / \ | / \ / \ | / \ / \|/ ------------------- ------------------- | | | | | |viewpor1|viewpor2| is equal to | viewport0 | ? i say no. | | | | | -------------------- -------------------- and my 9 perspective cones are separatory, but viewports are neighboring. Thanks again. liubin ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 05:54:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA10450; Thu, 23 Jan 1997 05:53:06 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA10434; Thu, 23 Jan 1997 05:53:05 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA06001; Thu, 23 Jan 1997 05:52:54 -0800 Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA12397 for ; Thu, 23 Jan 1997 05:52:50 -0800 Received: from P3.ENZIAN.COM by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id IAA11279; Thu, 23 Jan 1997 08:49:56 -0500 (EST) Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.21); 23 Jan 97 08:45:07 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.30); 23 Jan 97 08:44:49 EST From: "Jude Anthony" Organization: Enzian Technology, Inc. To: info-performer@sgi.com Date: Thu, 23 Jan 1997 08:44:47 EST Subject: Re: Scene Density Requirements X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: <1F7B7E67116@P3.ENZIAN.COM> Status: O > Is this really true? I thought that rendering front to back (on > either an iR or a RE2) would be significantly faster than vice versa. Actually, I tried both ways in my test, just to check. The difference between back-to-front and front-to-back resulted in 0.1ms improvement in draw time for the entire 3000 polygon scene. (According to stats in Vega.) Just for info. Later, Jude Anthony jude@p3.enzian.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 06:29:03 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA10582; Thu, 23 Jan 1997 06:27:48 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA10566; Thu, 23 Jan 1997 06:27:48 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA07500; Thu, 23 Jan 1997 06:27:37 -0800 Received: from hades.sharp.co.uk (hades.sharp.co.uk [193.114.241.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA17590 for ; Thu, 23 Jan 1997 06:27:28 -0800 Received: (from uucp@localhost) by hades.sharp.co.uk (8.6.12/8.6.12) id OAA00891 for ; Thu, 23 Jan 1997 14:31:14 GMT Received: from sharp.co.uk by hades.sharp.co.uk via smap (RMS/1) id sma000885; Thu Jan 23 14:31:01 1997 Received: from inca.sle.sharp.co.uk (aardog) by sharp.co.uk (5.x/SMI-SVR4) id AA18175; Thu, 23 Jan 1997 14:26:19 GMT Message-Id: <32E77460.1F76@sharp.co.uk> Date: Thu, 23 Jan 1997 14:23:37 +0000 From: Graham Jones Reply-To: graham.jones@sharp.co.uk Organization: Sharp Laboratories of Europe X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: info-performer@sgi.com Subject: Re: Infinite Reality, Colour matrix etc References: <32E4DB77.3D55@sharp.co.uk> <9701211753.ZM18615@bitch.reading.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O OK, I'm still having no luck with my textures, maybe an explanation of what I am trying to do would help! I have one channel in which I render a scene, full colour/textured etc. It could be any model which can be loaded into Performer. The rendered image is subloaded into a pfTexture to be used later. I need to hang on to all the colour information. I have a second channel in which I render a simple set of tri-strips as a geoset. These tri-strips are textured with the subloaded texture. When I do this rendering I want to be able to render the R, G and B components of the texture separately (rendering the geoset 3 times) into the Red component of the second channel. I then need to be able to do the same thing but into the Green component, and then into the Blue component. I will arrange that all the data goes to the correct pixels to end up with the required image. I can't get to the individual colour components of the texture. I had hoped to use the colour matrix extension, except that it doesn't act when rendering a texture, only downloading. I had then hoped to use the GL_QUAD_TEXTURE_SELECT extension to select the individual components and use them as Intensity textures but that doesn't want to work either! (I can use the colour mask to restrict rendering to the R, G or B component of the channel). I don't need to process the intensities once thay have been transferred to the other colour components. Maybe a snippet of my, very simple, code would help. Can anybody give any suggestion why this doesn't select a single component of the texture? glDisable( GL_DEPTH_TEST ); glDisable( GL_MULTISAMPLE_SGIS ); pfDisable( PFEN_LIGHTING ); pfEnable( PFEN_TEXTURE ); glTexParameteri( GL_TEXTURE_2D, GL_QUAD_TEXTURE_SELECT_SGIS, 0 /* RED */); tex1->apply(); // tex1 is one of my subloaded pfTextures gSet[0][0]->draw(); pfEnable( PFEN_LIGHTING ); glEnable( GL_DEPTH_TEST ); glEnable( GL_MULTISAMPLE_SGIS ); All I get on screen is the geoset textured with the tex1 texture but in full colour, not just the red component. The texture is a PFTEX_RGBA_8 internal format texture subloaded from the framebuffer. For an extension to this little bit of graphics it is vital that I can use the subloaded textures to give me the image in the second channel so if there are any ideas about how to make this work I would love to hear them. I'm sorry to keep pushing this point but by myself I'm not getting anywhere. The suggestions I have had so far have been interesting but don't actually help me get the image I need on screen! Graham. -- Sharp Laboratories of Europe, Phone: +44-(0)1865-747711 Oxford Science Park, Fax: +44-(0)1865-714217 Oxford, OX4 4GA England Graham.Jones@sharp.co.uk ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 07:01:20 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA10728; Thu, 23 Jan 1997 07:00:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA10712; Thu, 23 Jan 1997 07:00:08 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA09169; Thu, 23 Jan 1997 06:59:57 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA22455; Thu, 23 Jan 1997 06:59:51 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id OAA03390; Thu, 23 Jan 1997 14:59:45 GMT From: "Angus Dorbie" Message-Id: <9701231459.ZM3388@bitch.reading.sgi.com> Date: Thu, 23 Jan 1997 14:59:44 +0000 In-Reply-To: Graham Jones "Re: Infinite Reality, Colour matrix etc" (Jan 23, 2:23pm) References: <32E4DB77.3D55@sharp.co.uk> <9701211753.ZM18615@bitch.reading.sgi.com> <32E77460.1F76@sharp.co.uk> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: graham.jones@sharp.co.uk, info-performer@sgi.com Subject: Re: Infinite Reality, Colour matrix etc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O glColorMask should be enough for this without lookup tables after the component select. You should try GL_QUAD_INTENSITY8_SGIS as the components term in glTexImage2D (the internal format) if you want to use glTexParameter to isolate components. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 06:54:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA10677; Thu, 23 Jan 1997 06:53:09 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA10661; Thu, 23 Jan 1997 06:53:08 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA08846; Thu, 23 Jan 1997 06:52:57 -0800 Received: from philos.philosys.de (philos.philosys.de [193.100.254.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id GAA21391 for ; Thu, 23 Jan 1997 06:52:49 -0800 Received: from indy.philosys.de by philos.philosys.de (4.1/SMI-4.1) id AA14096; Thu, 23 Jan 97 15:27:19 +0100 Received: by indy.philosys.de (950511.SGI.8.6.12.PATCH526/940406.SGI) for info-performer@sgi.com id PAA06520; Thu, 23 Jan 1997 15:25:29 +0100 From: Thomas.Steudten@philosys.de (Thomas Steudten) Message-Id: <199701231425.PAA06520@indy.philosys.de> Subject: no image with pfuSaveImage on iR To: info-performer@sgi.com Date: Thu, 23 Jan 1997 15:25:28 +0100 (MET) Organisation: Philosys Software GmbH, Unterschleissheim, Germany Reply-To: Thomas.Steudten@philosys.de X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 823 Status: O Hello, i've tried to make a snapshot of one channel. On indy IRIX 5.3 Performer 2.0, O2's IRIX 6.3 everything is fine. But the same program fails on iR with Performer 2.1 and IRIX 6.2. Fail means, the image is total black, nothing else seen. Has anyone tried to take a snapshot on iR with pfuSaveImage(..)? Regards, Thomas ================= KERNEL PANIC: /dev/null full ============================= | | | PHILOSYS Software GmbH | Phone: (+49) 89 321407-31 Dipl.-Ing. | Carl von Linde Str. 30a | Fax: (+49) 89 321407-36/12 Thomas Steudten | D-85716 Unterschleissheim | Url: www.philosys.de/~thomas | Germany | Email: thomas@philosys.de ============================================================================= ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 07:11:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA10814; Thu, 23 Jan 1997 07:10:28 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA10796; Thu, 23 Jan 1997 07:10:27 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA09972; Thu, 23 Jan 1997 07:10:15 -0800 Received: from rtset.co.il (oren.rtset.co.il [194.90.96.233]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA24474 for ; Thu, 23 Jan 1997 07:10:08 -0800 Received: (from rany@localhost) by rtset.co.il (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA03953; Thu, 23 Jan 1997 17:06:36 +0200 Date: Thu, 23 Jan 1997 17:06:36 +0200 From: rany@rtset.co.il (Ran Yakir) Message-Id: <9701231706.ZM3951@oren.rtset.co.il> In-Reply-To: Graham Jones "Re: Infinite Reality, Colour matrix etc" (Jan 23, 2:23pm) References: <32E4DB77.3D55@sharp.co.uk> <9701211753.ZM18615@bitch.reading.sgi.com> <32E77460.1F76@sharp.co.uk> X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: graham.jones@sharp.co.uk Subject: Re: Infinite Reality, Colour matrix etc Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 23, 2:23pm, Graham Jones wrote: > Subject: Re: Infinite Reality, Colour matrix etc > I have one channel in which I render a scene, full colour/textured etc. > It could be any model which can be loaded into Performer. The rendered > image is subloaded into a pfTexture to be used later. I need to hang on > to all the colour information. > > I have a second channel in which I render a simple set of tri-strips as > a geoset. These tri-strips are textured with the subloaded texture. When > I do this rendering I want to be able to render the R, G and B > components of the texture separately (rendering the geoset 3 times) into > the Red component of the second channel. I then need to be able to do > the same thing but into the Green component, and then into the Blue > component. I will arrange that all the data goes to the correct pixels > to end up with the required image. > > I can't get to the individual colour components of the texture. > > I had hoped to use the colour matrix extension, except that it doesn't > act when rendering a texture, only downloading. I had then hoped to use > the GL_QUAD_TEXTURE_SELECT extension to select the individual components > and use them as Intensity textures but that doesn't want to work either! > (I can use the colour mask to restrict rendering to the R, G or B > component of the channel). I don't need to process the intensities once > thay have been transferred to the other colour components. > > Maybe a snippet of my, very simple, code would help. Can anybody give > any suggestion why this doesn't select a single component of the > texture? > > glDisable( GL_DEPTH_TEST ); > glDisable( GL_MULTISAMPLE_SGIS ); > pfDisable( PFEN_LIGHTING ); > > pfEnable( PFEN_TEXTURE ); > glTexParameteri( GL_TEXTURE_2D, > GL_QUAD_TEXTURE_SELECT_SGIS, 0 /* RED */); > tex1->apply(); // tex1 is one of my subloaded pfTextures > gSet[0][0]->draw(); > > pfEnable( PFEN_LIGHTING ); > glEnable( GL_DEPTH_TEST ); > glEnable( GL_MULTISAMPLE_SGIS ); > Graham, You should do the following : When you create the pfTexture that is being subtexloaded with the screen, you should give it an internal format of GL_QUAD_LUMINANCE8_SGIS. I think that Performer will eat this argument although it is a GL constant. When you need to use the texture, bind it first (using apply()), and then call glTexParameter with the selection. Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | RT-SET Ltd. / )_ (_(_) ) \/ (_(_/<_(_)( | _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@rtset.co.il Work : 972-9-9552236 | rany@netvision.net.il Res. : 972-9-7489974 | Fax : 972-9-9552239 | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 07:26:42 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA10899; Thu, 23 Jan 1997 07:25:21 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA10883; Thu, 23 Jan 1997 07:25:20 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA10876; Thu, 23 Jan 1997 07:25:09 -0800 Received: from python.tamu.edu (python.tamu.edu [128.194.11.99]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA27233 for ; Thu, 23 Jan 1997 07:25:03 -0800 Received: (from renjye@localhost) by python.tamu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA03593 for info-performer@sgi.com; Thu, 23 Jan 1997 07:25:58 -0800 From: "Ren-Jye Yu" Message-Id: <9701230725.ZM3592@python.tamu.edu> Date: Thu, 23 Jan 1997 07:25:58 -0800 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Frame rate drop down seriously!!!! Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19701230725.ZM3592.tamu.edu" Status: O -- --PART-BOUNDARY=.19701230725.ZM3592.tamu.edu Content-Type: text/plain; charset=us-ascii Hi, I have a serious frame rate problem when I create three channels on one pipeline. When I run my program in three channels, frame rate will drop down form 72Hz to 36 Hz. If I close one channel and remain two of them, the frame rate will repeatly jump from 72Hz to 36Hz and back to 72Hz. My question are : 1. Why the frame rate drop down seriously? I follow the example in the programmer's guide. I attach my code with this mail. 2. Why the frame rate have only two values : 72Hz and 36Hz? Why the values of frame rate between these two values will not appear? 3. I use draw callback function to draw HUD. But after that the statistics diagram diappear. Why? For the time being, there have only a rectangular 150x8600 with texture applied in the enviourement. I run my program on ONYX RE2. This problem trouble me for long time. Hope you can help me. Thanks. -- _______________________________________________________________________________ ("`-''-/").___..--''"`-._ Ren-Jye Yu `6_ 6 ) `-. ( ).`-.__.`) Email :renjye@python.tamu.edu (_Y_.)' ._ ) `._ `. ``-..-' Phone(O) :(409) 845-0729 _..`--'_..-_/ /--'_.' ,' (H) :(409) 691-8570 (il),-'' (li),' ((!.-' Address :Aerospace Engineering Department H.R. Bright Building Texas A&M University College Station 77840-3141 _______________________________________________________________________________ --PART-BOUNDARY=.19701230725.ZM3592.tamu.edu X-Zm-Content-Name: main Content-Description: Text Content-Type: text/plain ; name="main" ; charset=us-ascii void drawFunc(pfChannel *chan, void *data) { PassData *pd = (PassData*)data; pfClearChan(chan); pfDraw(); HUD(pd); } void scenehierachy(pfScene *scene) { pfDCS *dcs; pfSCS *scs; pfLayer *layer; pfCoord location; pfMatrix dst; pfSetVec3(location.xyz, 0.0f, 0.0f, 470.0f); pfSetVec3(location.hpr, 0.0f, 0.0f, 0.0f); pfMakeCoordMat(dst, &location); dcs = pfNewDCS(); scs = pfNewSCS(dst); layer = pfNewLayer(); pfAddChild(layer, seventeenLbase()); pfAddChild(layer, seventeenLmarking()); pfAddChild(scs, layer); pfAddChild(scene, scs); } int main (int argc, char *argv[]) { double t = 0.; pfScene *scene; pfPipe *p; pfPipeWindow *pw; pfChannel *chan[3]; pfCoord view; pfEarthSky *esky; pfVec3 hprOffsets; pfVec3 xyzOffsets; int index = 1; int j=0; int test=0; float time=0; PassData *pd; /* Initialize Performer */ pfInit(); /* Use default multiprocessing mode based on number of * processors. */ pfMultiprocess(PFMP_DEFAULT); pfFrameRate(60.0f); /* Configure multiprocessing mode and start parallel * processes. */ pfConfig(); pfFilePath(".:/usr/poeple/renjye/Performer/Texture:~/Performer/graphic_objects"); scene = pfNewScene(); scenehierachy(scene); /*Create Earth and Sky*/ esky = pfNewESky(); pfESkyMode(esky, PFES_BUFFER_CLEAR, PFES_SKY_GRND); pfESkyAttr(esky, PFES_GRND_HT, -1.0f); pfESkyColor(esky, PFES_GRND_FAR, 0.0f, 100.0f/255.0f, 0.0f, 1.0f); pfESkyColor(esky, PFES_GRND_NEAR, 0.0f, 1.0f, 0.0f, 1.0f); /* Config and open GL window */ p = pfGetPipe(0); pw = pfNewPWin(p); pfPWinName(pw, "View"); pfPWinOriginSize(pw, 0, 0, 1280, 1504); pfOpenPWin(pw); pfConfigPWin(pw); for(j=0;j<=2;j++) chan[j]=pfNewChan(p); /* initializing channels for using the Multi-Channel Option */ pfuConfigMCO(chan, 3); /* Form channel group with middle as the "master" */ pfAttachChan(chan[1], chan[0]); pfAttachChan(chan[1], chan[2]); /* Set FOV of all channels */ pfMakeSimpleChan(chan[1], 45.0f); pfChanAutoAspect(chan[1], PFFRUST_CALC_VERT); /* Set clipping planes of all channels */ hprOffsets[PF_P] = 0.0f; hprOffsets[PF_R] = 0.0f; pfSetVec3(xyzOffsets, 0.0f, -5500.0f, 0.0f); /* Set up viewport and viewing offets */ /* Note that these are not shared by default */ pfChanViewport(chan[0], 0.0f, 0.5f, 0.0f, .319f); hprOffsets[PF_H] = 45.0f; pfChanViewOffsets(chan[0], xyzOffsets, hprOffsets); pfChanViewport(chan[1], 0.0f, 1.0f, 0.39f, 1.0f); hprOffsets[PF_H] = 0.0f; pfChanViewOffsets(chan[1], xyzOffsets, hprOffsets); pfChanViewport(chan[2], 0.5f, 1.0f, 0.0f, .319f); hprOffsets[PF_H] = -45.0f; pfChanViewOffsets(chan[2], xyzOffsets, hprOffsets); pfAddChan(pw, chan[0]); pfAddChan(pw, chan[1]); pfAddChan(pw, chan[2]); pfSetVec3(view.xyz, 0.0f, 0.0f, 471.0f); pfSetVec3(view.hpr, 0.0f, 0.0f, 0.0f); pfChanScene(chan[1], scene); pfChanNearFar(chan[1], 1.0f, 25000); pfChanFOV(chan[1], 45.0f, -1.0f); pfChanESky(chan[1], esky); pfChanView(chan[1], view.xyz, view.hpr); make_objects(); /* Make symbology for HUD by display list */ /* Setup channel 1 passthrough data */ pd = (PassData*)pfAllocChanData(chan[1], sizeof(PassData)); /* Bind craw callback functions to channel */ pfChanTravFunc(chan[1], PFTRAV_DRAW, drawFunc); /* Initialize font */ pfuMakeRasterXFont("-*-screen-medium-r-normal--7-*-*-*-m-60-iso8859-1", &x_font1); /* Sets the current X Window font to x_font1 */ pfuSetXFont(&x_font1); pd->var = 1547; pfPassChanData(chan[1]); do{ pfFrame(); pfDrawChanStats(chan[0]); view.xyz[PF_X] = 0; view.xyz[PF_Y] = time*100; view.xyz[PF_Z] = 600.0; view.hpr[PF_H] = 0; view.hpr[PF_P] = 0.0; view.hpr[PF_R] = time/4; time +=1; pfChanView(chan[1], view.xyz, view.hpr); }while(time<400.0); /* Terminate parallel processes and exit. */ pfExit(); return 0; } --PART-BOUNDARY=.19701230725.ZM3592.tamu.edu-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 08:24:29 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA11218; Thu, 23 Jan 1997 08:23:04 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA11202; Thu, 23 Jan 1997 08:23:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA15382; Thu, 23 Jan 1997 08:22:52 -0800 Received: from hades.sharp.co.uk (hades.sharp.co.uk [193.114.241.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA08703 for ; Thu, 23 Jan 1997 08:22:48 -0800 Received: (from uucp@localhost) by hades.sharp.co.uk (8.6.12/8.6.12) id QAA01759; Thu, 23 Jan 1997 16:26:43 GMT Received: from sharp.co.uk by hades.sharp.co.uk via smap (RMS/1) id sma001755; Thu Jan 23 16:26:38 1997 Received: from inca.sle.sharp.co.uk (aardog) by sharp.co.uk (5.x/SMI-SVR4) id AA19644; Thu, 23 Jan 1997 16:21:54 GMT Message-Id: <32E78F82.35E6@sharp.co.uk> Date: Thu, 23 Jan 1997 16:19:14 +0000 From: Graham Jones Reply-To: graham.jones@sharp.co.uk Organization: Sharp Laboratories of Europe X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: Thomas.Steudten@philosys.de Cc: info-performer@sgi.com Subject: Re: no image with pfuSaveImage on iR References: <199701231425.PAA06520@indy.philosys.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Thomas Steudten wrote: > > Hello, > > i've tried to make a snapshot of one channel. On indy IRIX 5.3 Performer 2.0, > O2's IRIX 6.3 everything is fine. > > But the same program fails on iR with Performer 2.1 and IRIX 6.2. > Fail means, the image is total black, nothing else seen. > > Has anyone tried to take a snapshot on iR with pfuSaveImage(..)? Thomas, I've taken many snapshots of channels with pfuSaveImage on iR so I can confirm that it works. I didn't have to do anything special to make it work either. You could try loading a model into perfly and pressing 'x' to save an image - that uses pfuSaveImage. If that test doesn't work then you really do have a problem. Sorry I can't help you any further. Graham. -- Sharp Laboratories of Europe, Phone: +44-(0)1865-747711 Oxford Science Park, Fax: +44-(0)1865-714217 Oxford, OX4 4GA England Graham.Jones@sharp.co.uk ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 08:51:35 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA11309; Thu, 23 Jan 1997 08:49:37 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA11293; Thu, 23 Jan 1997 08:49:33 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA17731; Thu, 23 Jan 1997 08:49:14 -0800 Received: from xr1.atlas.fr (xr1.atlas.fr [194.51.9.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA14072 for ; Thu, 23 Jan 1997 08:48:10 -0800 Message-Id: <199701231648.IAA14072@sgi.sgi.com> X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Thu, 23 Jan 1997 17:44:59 +0100 X400-Received: by mta xr1.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Thu, 23 Jan 1997 17:44:59 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; converted (ia5-text,iso (1) (0) (10021) (7) (1) (0) (1),iso (1) (0) (10021) (7) (1) (0) (6),iso (1) (0) (10021) (7) (1) (0) (100)); Relayed; Thu, 23 Jan 1997 17:44:57 +0100 X400-Received: by /PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/; Relayed; Thu, 23 Jan 1997 17:01:26 +0100 Date: Thu, 23 Jan 1997 17:01:26 +0100 X400-Originator: MICHAEL.BOCCARA@siege.aerospatiale.fr X400-Recipients: info-performer@sgi.com X400-MTS-Identifier: [/PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/;970123160126] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: CSI NC V3.0 From: BOCCARA Michael To: Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: RE: no image with pfuSaveImage on iR MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Status: O =0C Hi Thomas, I had exactly the same problem, not on an iR IRIX 6.2 with performer= 2.1, but with an Onyx RE2 IRIX 5.3 with Performer 2.0.1. The image was not black but totally aberrated, with only the red can= al, when a chunk of image appears. Bref, pfuSaveImage didn't work. BUT, I found an alternative : I use a system call to the unix comman= d "scrsave" The only problem is that you better not cover a part of your Perform= er pipewindow with another window, because my method is to make a snaps= hot of a part of the screen cropped according to the dimensions of the pipewi= ndow. Apart from this the result is OK (a rgb image file in the current di= rectory). I dont think that this method will depend on the SGI platform. void snapImage(void) < ostrstream ost; static int count =3D 0; pfPipe* cpipe =3D Shared->chan->getPipe(); int id =3D pfGetId(cpipe)*10 + count++; int ox, oy, sx, sy; Shared->pw->getCurScreenOriginSize(&ox, &oy, &sx, &sy); ost << "scrsave " << "Photo." << id << ".rgb " << ox << " " << (ox+sx) << " " << oy << " " << (oy+sy) << " ;"= ; pfNotify(PFNFY_ALWAYS, PFNFY_PRINT, "Saving pipe %d image : %s?n",= pfGetId(cpipe), ost.str()); // // NO MORE !!! /* pfuSaveImage(ost.str(), 0, 0, Shared->mouse.winSizeX, Shared->mouse.winSizeY, 0); */ // // BUT : // system(ost.str()); pfNotify(PFNFY_ALWAYS, PFNFY_PRINT, "Done?n"); > ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 08:51:28 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA11291; Thu, 23 Jan 1997 08:49:07 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA11275; Thu, 23 Jan 1997 08:49:06 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA17714; Thu, 23 Jan 1997 08:48:55 -0800 Received: from hades.sharp.co.uk (hades.sharp.co.uk [193.114.241.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA14167 for ; Thu, 23 Jan 1997 08:48:52 -0800 Received: (from uucp@localhost) by hades.sharp.co.uk (8.6.12/8.6.12) id QAA01867 for ; Thu, 23 Jan 1997 16:52:43 GMT Received: from sharp.co.uk by hades.sharp.co.uk via smap (RMS/1) id sma001865; Thu Jan 23 16:52:40 1997 Received: from inca.sle.sharp.co.uk (aardog) by sharp.co.uk (5.x/SMI-SVR4) id AA19910; Thu, 23 Jan 1997 16:47:58 GMT Message-Id: <32E7959B.6686@sharp.co.uk> Date: Thu, 23 Jan 1997 16:45:15 +0000 From: Graham Jones Reply-To: graham.jones@sharp.co.uk Organization: Sharp Laboratories of Europe X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: info-performer@sgi.com Subject: Re: Infinite Reality, Colour matrix etc References: <32E4DB77.3D55@sharp.co.uk> <9701211753.ZM18615@bitch.reading.sgi.com> <32E77460.1F76@sharp.co.uk> <9701231706.ZM3951@oren.rtset.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Angus Dorbie wrote: > glColorMask should be enough for this without lookup tables > after the component select. It certainly is, no problem there. > You should try GL_QUAD_INTENSITY8_SGIS as the components term > in glTexImage2D (the internal format) if you want to use > glTexParameter to isolate components. Ran Yakir wrote: > You should do the following : > > When you create the pfTexture that is being subtexloaded with the > screen, you should give it an internal format of > GL_QUAD_LUMINANCE8_SGIS. I think that > Performer will eat this argument although it is a GL constant. Now I'm getting somewhere - I thought about doing this almost simultanously with the arrival of your mail. I have found that the format needs to be GL_QUAD_INTENSITY8_SGIS, as Angus suggested, rather then the LUMINANCE version but otherwise that is the method that works. > When you need to use the texture, bind it first (using apply()), and > then call glTexParameter with the selection. Now I do get an intensity texture drawn on my tri-strips. That leaves me with only (!) 2 problems. 1) The texture extracted by the glTexParameter setting seems to taking 4 bits out of the 8 in the particular colour component selected. The top 4 bits of the 8 are duplicated into the bottom 4 to make the full 8 bit grey level. So a pixel value in hex of 39 would show on screen as hex 33 (in R, G, B and A). It's better than it not happening at all but can I get the full 8 bits? 2) The other problem is that intermittently (always the worst problems) my stencil mask is not written to the screen and then nothing appears. It looks like some state or position is being left over from the rendering of the previous channels causing the origin not to be where I expect and the glDrawPixels call fails. Is there any way of guaranteeing the geometry state at the start of a draw callback? Of course I could just set it explicitly. Thanks again for all your help, I seem to be on the road to sanity at last. Graham. -- Sharp Laboratories of Europe, Phone: +44-(0)1865-747711 Oxford Science Park, Fax: +44-(0)1865-714217 Oxford, OX4 4GA England Graham.Jones@sharp.co.uk ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 08:58:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA11346; Thu, 23 Jan 1997 08:57:15 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA11330; Thu, 23 Jan 1997 08:57:14 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA18275; Thu, 23 Jan 1997 08:57:03 -0800 Received: from rainich.dcs.ed.ac.uk (rainich.dcs.ed.ac.uk [129.215.160.105]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA16217 for ; Thu, 23 Jan 1997 08:56:59 -0800 Received: from calvay.dcs.ed.ac.uk by rainich.dcs.ed.ac.uk with SMTP (PP); Thu, 23 Jan 1997 16:55:45 +0000 Received: from localhost by calvay.dcs.ed.ac.uk; Thu, 23 Jan 1997 16:44:04 GMT Date: Thu, 23 Jan 1997 16:44:01 +0000 (GMT) From: Martin Reddy To: Ren-Jye Yu cc: info-performer@sgi.com Subject: Re: Frame rate drop down seriously!!!! In-Reply-To: <9701230725.ZM3592@python.tamu.edu> Message-ID: Organisation: Department of Computer Science - University of Edinburgh MIME-Version: 1.0 Content-ID: Content-type: MULTIPART/MIXED; boundary="PART-BOUNDARY=.19701230725.ZM3592.tamu.edu" Status: O --PART-BOUNDARY=.19701230725.ZM3592.tamu.edu Content-ID: Content-type: TEXT/PLAIN; CHARSET="us-ascii" Under the current implementation of IRIS Performer, the frame rate is constrained to be an integer multiple of the video refresh rate. Your video refresh rate is 72 Hz and so if the simulation is unable to run at 72 Hz, then it will drop down to the next integer multiple of 72, i.e. 72 / 2 = 36 Hz. > I have a serious frame rate problem when I create three channels on one > pipeline. When I run my program in three channels, frame rate will drop down > form 72Hz to 36 Hz. If I close one channel and remain two of them, the frame > rate will repeatly jump from 72Hz to 36Hz and back to 72Hz. +============================================================================+ | Martin Reddy Dept. of Computer Science | | University of Edinburgh | | e-mail : mxr@dcs.ed.ac.uk Mayfield Road, EH9 3JZ | | http://www.dcs.ed.ac.uk/home/mxr/ Tel : (0131) 650 5164 | +============================================================================+ --PART-BOUNDARY=.19701230725.ZM3592.tamu.edu-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 09:37:48 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA11665; Thu, 23 Jan 1997 09:36:29 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA11649; Thu, 23 Jan 1997 09:36:28 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA22192; Thu, 23 Jan 1997 09:36:18 -0800 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA25537 for ; Thu, 23 Jan 1997 09:36:16 -0800 Received: from vivid.autometric.com by relay3.UU.NET with SMTP (peer crosschecked as: vivid.autometric.com [198.49.5.66]) id QQbztm09645; Thu, 23 Jan 1997 12:36:14 -0500 (EST) Received: from torus by vivid.autometric.com via ESMTP (950215.SGI.8.6.10/920502.SGI) for <@vivid.autometric.com:info-performer@sgi.com> id MAA02305; Thu, 23 Jan 1997 12:36:13 -0500 Received: (from cowling@localhost) by torus (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA01613 for info-performer@sgi.com; Thu, 23 Jan 1997 12:36:13 -0500 From: "Bob Cowling" Message-Id: <9701231236.ZM1612@torus.autometric.com> Date: Thu, 23 Jan 1997 12:36:12 -0500 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Seeking Hardware Advice Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O A customer of ours wants to configure an Onyx/Onyx2 for two stereo views and of course he doesn't want to spend too much money. We assume that the views will be fairly the same (i.e., reuse the same texture). Does anyone have any advice as far as whether we should load all of the RMs into a single graphics pipe, or split them up into two separate graphics pipes? Specifically, is the texture downloaded separately for each pipe, and if so, does that outweigh the benefit of isolated graphics pipelines? Does anyone have any lessons learned for generating two separate (but almost the same) stereo views? Our application repeatedly updates the scene graph and downloads/updates new texture. Thanks for any advice, Bob -- -------------------------------------------------------------------- Robert Cowling cowling@autometric.com Director, Product Engineering (703) 658-4035 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 09:45:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA11743; Thu, 23 Jan 1997 09:44:36 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA11727; Thu, 23 Jan 1997 09:44:35 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA22792; Thu, 23 Jan 1997 09:44:24 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27371; Thu, 23 Jan 1997 09:44:15 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA03757; Thu, 23 Jan 1997 17:43:56 GMT From: "Angus Dorbie" Message-Id: <9701231743.ZM3755@bitch.reading.sgi.com> Date: Thu, 23 Jan 1997 17:43:56 +0000 In-Reply-To: Martin Reddy "Re: Frame rate drop down seriously!!!!" (Jan 23, 4:44pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Martin Reddy , Ren-Jye Yu Subject: Re: Frame rate drop down seriously!!!! Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 23, 4:44pm, Martin Reddy wrote: > Subject: Re: Frame rate drop down seriously!!!! > > > Under the current implementation of IRIS Performer, the frame rate is ^^^^^^^ And always will be, this is very desirable since you'd see the image breaking up if Performer didn't wait for the video to refresh between swaps. This is one of the fundamental rules of real-time animation. > constrained to be an integer multiple of the video refresh rate. Your > video refresh rate is 72 Hz and so if the simulation is unable to run at > 72 Hz, then it will drop down to the next integer multiple of 72, i.e. > 72 / 2 = 36 Hz. > > > I have a serious frame rate problem when I create three channels on one > > pipeline. When I run my program in three channels, frame rate will drop down > > form 72Hz to 36 Hz. If I close one channel and remain two of them, the frame > > rate will repeatly jump from 72Hz to 36Hz and back to 72Hz. > > +============================================================================+ > | Martin Reddy Dept. of Computer Science | > | University of Edinburgh | > | e-mail : mxr@dcs.ed.ac.uk Mayfield Road, EH9 3JZ | > | http://www.dcs.ed.ac.uk/home/mxr/ Tel : (0131) 650 5164 | > +============================================================================+ >-- End of excerpt from Martin Reddy ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 11:29:39 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA12257; Thu, 23 Jan 1997 11:27:41 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA12241; Thu, 23 Jan 1997 11:27:40 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA02891; Thu, 23 Jan 1997 11:27:29 -0800 Received: from ait.nrl.navy.mil (ait.nrl.navy.mil [132.250.128.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22733; Thu, 23 Jan 1997 11:27:27 -0800 Received: from stiletto.ait.nrl.navy.mil (stiletto [132.250.128.59]) by ait.nrl.navy.mil (8.8.3/8.8.3) with ESMTP id OAA28168; Thu, 23 Jan 1997 14:27:24 -0500 (EST) Received: (from durbin@localhost) by stiletto.ait.nrl.navy.mil (8.7.5/8.7.3) id OAA02643; Thu, 23 Jan 1997 14:27:23 -0500 (EST) Date: Thu, 23 Jan 1997 14:27:23 -0500 (EST) Message-Id: <199701231927.OAA02643@stiletto.ait.nrl.navy.mil> From: Jim Durbin To: info-performer@sgi.com CC: doyle@ait.nrl.navy.mil, bcolbert@ait.nrl.navy.mil, dolson@sgi.com, singer@sgi.com Subject: Clip map blues... Reply-To: durbin@ait.nrl.navy.mil Status: O We, like everybody else these days, are working with large terrain databases created from dted and high-res imagry. We are currently using a 8k by 8k clip-map texture pyramid. When the application is running, we notice that the bottom left corner (cooresponding to the origin of our world) has a high-res texture tile loaded. Moving out from that corner along the x and y axes, the texture tiles displayed are from progressively lower-res levels of the pyramid. No matter where we move the viewpt, the resolution of the clip map displayed for a given tile does not change. The same behavior is observed when the textured object is moved and the viewpt is held constant. Also, in one of our applications, the high-res texture in the bottom left corner was replaced when the texture model was scaled up with a stale texture that was from another application that was run 4 days prior. We were finally succesfull at flushing that texture by rebooting the machine. Has anyone else seen this type of behavior? However, when we load the same model into perfly, the clipmap behavior works perfectly. What am I missing? Is there an extra step that I need to take to inform Performer to recalculate the clipmap? Should I be able to move the textured model and leave the viewpt constant (position and hpr with respect to world coordinates) and get the same affect as moving the viewpt and holding the textured model constant? We have an Onyx w/ 4 R10000s, one IR pipe with a single RM6/16, running Performer 2.1 internal version number 1234000053. ======================================================================= To make story more interesting: We know that the clip mapping worked in one of our applications (where the view point was changed) last week. The only known change made to the machine between success and failure of clip mapping is the application of: Patch SG0001422: IGLOO (IrisGL On OpenGL) patch for O2, Impact and InfiniteReality Patch SG0001572: 6.2 streams rollup patch Patch SG0001601: mediad rollup patch Patch SG0001625: dmedia rollup patch Patch SG0001650: All platform kernel rollup patch Patch SG0001667: XFS rollup #6 for 6.2 Patch SG0001679: Special rollup for NFS locking FailSafe enhancements Patch SG0001692: fix kernel memory consumption on cachefs during find Removal of those patches has not corrected the situation. It is my guess that the patches are irrelevant, but I include here for completness. Any suggestions would be greatly appreciated! Thanks! -Jim -- _________________________________________________________________________ | Jim Durbin durbin@nrl.navy.mil | | ITD Virtual Reality Lab (202) 767-6025 | | Naval Research Laboratory (202) 767-1122 (fax) | | http://www.ait.nrl.navy.mil/people/durbin | | | | "It is much easier to criticize an idea than it is to conceive it." | | anonymous | | Lack of brains hinders research - The Columbus Dispatch, April 16 | _________________________________________________________________________ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 11:50:11 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA12325; Thu, 23 Jan 1997 11:47:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA12309; Thu, 23 Jan 1997 11:47:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA04853; Thu, 23 Jan 1997 11:47:47 -0800 Received: from ren.paradigmsim.com (ren.paradigmsim.com [206.7.114.138]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27643 for ; Thu, 23 Jan 1997 11:47:44 -0800 Received: (from doug@localhost) by ren.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA22365 for info-performer@sgi.com; Thu, 23 Jan 1997 13:46:08 -0600 From: "Doug Price" Message-Id: <9701231346.ZM22363@ren.paradigmsim.com> Date: Thu, 23 Jan 1997 13:46:07 -0600 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: pfStats Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I have an application which uses pfFrameStats (obtained from the pfChannel) to gather pfFrameStats. This works fine. In the man pages it says that the pfStats can also be gathered using the pfFrameStats and even shows examples to this effect. When I try this, the values I get back seem to be reasonable, but I get the following warning every frame: => warn pfOpenStats(pfStats*) for 0x18ca86e0 ignored Already have a different opened pfStats=0x18ba3d20 mask=0x1. ( Error 0 ) I, however, have not created any pfStats instances. Is there a default pfStats created by performer that I need to close to avoid getting this message? -- ********************************************************************** Doug Price Phone: (972) 960 - 2301 Software Engineer Fax: (972) 960 - 9049 Paradigm Simulation Email: doug@paradigmsim.com ********************************************************************** ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 12:07:42 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA12510; Thu, 23 Jan 1997 12:06:06 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA12494; Thu, 23 Jan 1997 12:06:05 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA06705; Thu, 23 Jan 1997 12:05:54 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA02011 for ; Thu, 23 Jan 1997 12:05:53 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id MAA15325; Thu, 23 Jan 1997 12:05:51 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id MAA25452; Thu, 23 Jan 1997 12:05:49 -0800 From: "Sharon Clay" Message-Id: <9701231205.ZM25450@rose.asd.sgi.com> Date: Thu, 23 Jan 1997 12:05:49 -0800 In-Reply-To: "Angus Dorbie" "Re: 16mb or 64 mb max tex memory on RE2" (Jan 23, 10:18am) References: <2e69f600@cc.tacom.army.mil> <9701231018.ZM2998@bitch.reading.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Angus Dorbie" , info-performer@sgi.com, tidrowd@cc.tacom.army.mil Subject: Re: 16mb or 64 mb max tex memory on RE2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 23, 10:18am, Angus Dorbie wrote: > Subject: Re: 16mb or 64 mb max tex memory on RE2 ->From guest@holodeck.csd.sgi.com Thu Jan 23 02:35:27 1997 -> ->On Jan 22, 6:00pm, tidrowd@cc.tacom.army.mil wrote: ->> Subject: Re[2]: 16mb or 64 mb max tex memory on RE2 ->> ->> What's the diff between a RM6 and a RM7? First time I've heard of a ->> -> ->The RM6 is the ONYX Infinite Reality Raster Manager the ->RM7 is the ONYX2 Infinite Reality Raster Manager which ->also has the 16 or 64 Mb texture options and 80Mb framebuffer ->memory. -> ->There's also the RM8 which is a cost reduced Raster Manager ->for ONYX2 Reality with 40Mb of framebuffer memory and reduced ->textured fill performance. -> Minor correction here: the texture fill performance is the same. What is reduced is both the number of multisamples you can have (4) and the multisampled fill performance (peak is around 100 MPixels/sec as opposed to 180). So texture fill is the same unless limited by being combined with multisampling. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 12:26:46 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA12729; Thu, 23 Jan 1997 12:25:09 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA12713; Thu, 23 Jan 1997 12:25:08 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA08124; Thu, 23 Jan 1997 12:24:57 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06616 for ; Thu, 23 Jan 1997 12:24:56 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id MAA08119; Thu, 23 Jan 1997 12:24:55 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id MAA04977; Thu, 23 Jan 1997 12:25:05 -0800 From: "Rob Jenkins" Message-Id: <9701231225.ZM4975@quid.csd.sgi.com> Date: Thu, 23 Jan 1997 12:25:05 -0800 In-Reply-To: BOCCARA Michael "RE: no image with pfuSaveImage on iR" (Jan 23, 5:01pm) References: <199701231648.IAA14072@sgi.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: BOCCARA Michael , Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: Re: no image with pfuSaveImage on iR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Those with problems using pfuSaveImage on iR - is this within your own app ? Please could you test with perfly ( hit the 'snap screen' GUI button ). pfuSaveImage does different things depending if your rendering with Iris or OpenGL: #ifdef IRISGL lrectread((short)xorg, (short)yorg, (short)(xorg+xsize-1), (short)(yorg+ysize-1), scrbuf); #else /* OPENGL */ glReadPixels((short)xorg, (short)yorg, (short)xsize, (short)ysize, GL_RGBA, GL_UNSIGNED_BYTE, scrbuf); I saw the note about using scrsave, that uses Iris GL so would do lrectread. If perfly and perfly_ogl snap screen OK then you have an app problem. If one or the other doesn't work please let me know. Cheers Rob -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 12:28:52 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA12773; Thu, 23 Jan 1997 12:27:39 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA12757; Thu, 23 Jan 1997 12:27:39 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA08319; Thu, 23 Jan 1997 12:27:28 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA07278; Thu, 23 Jan 1997 12:27:20 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA05919; Thu, 23 Jan 1997 15:25:26 -0500 Date: Thu, 23 Jan 1997 15:25:26 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701231525.ZM5918@hotsauce.clubfed.sgi.com> In-Reply-To: Jim Durbin "Clip map blues..." (Jan 23, 2:27pm) References: <199701231927.OAA02643@stiletto.ait.nrl.navy.mil> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: durbin@ait.nrl.navy.mil, info-performer@sgi.com Subject: Re: Clip map blues... Cc: bcolbert@ait.nrl.navy.mil, doyle@ait.nrl.navy.mil, singer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Jim, You have described clipmapping perfectly except. Your application is not telling the clipmapping routines, man pfClipTexture, what the closest point on the terrain to the observer is, man pfuGetClosestPoint. This is my guess as to what you can do to fix this, after you update the position of the observer, in the updatesim routine, call pfuGetClosestPoint(...) then call pfClipTexture::setCenter(...) to move the center of resolution on the clipmap. I guess you may have to do some work to translate between the closest point and the texture coordinates. Brian On Jan 23, 2:27pm, Jim Durbin wrote: > Subject: Clip map blues... > > We, like everybody else these days, are working with large terrain > databases created from dted and high-res imagry. > > We are currently using a 8k by 8k clip-map texture pyramid. When the > application is running, we notice that the bottom left corner > (cooresponding to the origin of our world) has a high-res texture tile > loaded. Moving out from that corner along the x and y axes, the > texture tiles displayed are from progressively lower-res levels of the > pyramid. > > No matter where we move the viewpt, the resolution of the clip map > displayed for a given tile does not change. The same behavior is > observed when the textured object is moved and the viewpt is held > constant. > > Also, in one of our applications, the high-res texture in the bottom > left corner was replaced when the texture model was scaled up with a > stale texture that was from another application that was run 4 days > prior. We were finally succesfull at flushing that texture by > rebooting the machine. Has anyone else seen this type of behavior? > > However, when we load the same model into perfly, the clipmap behavior > works perfectly. > > What am I missing? Is there an extra step that I need to take to > inform Performer to recalculate the clipmap? > > Should I be able to move the textured model and leave the viewpt > constant (position and hpr with respect to world coordinates) and get > the same affect as moving the viewpt and holding the textured model > constant? > > We have an Onyx w/ 4 R10000s, one IR pipe with a single RM6/16, > running Performer 2.1 internal version number 1234000053. > > ======================================================================= > > To make story more interesting: > > We know that the clip mapping worked in one of our applications (where > the view point was changed) last week. The only known change made to > the machine between success and failure of clip mapping is the > application of: > > Patch SG0001422: IGLOO (IrisGL On OpenGL) patch for O2, Impact > and InfiniteReality > Patch SG0001572: 6.2 streams rollup patch > Patch SG0001601: mediad rollup patch > Patch SG0001625: dmedia rollup patch > Patch SG0001650: All platform kernel rollup patch > Patch SG0001667: XFS rollup #6 for 6.2 > Patch SG0001679: Special rollup for NFS locking FailSafe enhancements > Patch SG0001692: fix kernel memory consumption on cachefs during find > > Removal of those patches has not corrected the situation. It is my > guess that the patches are irrelevant, but I include here for > completness. > > Any suggestions would be greatly appreciated! > > Thanks! > > -Jim > > -- > _________________________________________________________________________ > | Jim Durbin durbin@nrl.navy.mil | > | ITD Virtual Reality Lab (202) 767-6025 | > | Naval Research Laboratory (202) 767-1122 (fax) | > | http://www.ait.nrl.navy.mil/people/durbin | > | | > | "It is much easier to criticize an idea than it is to conceive it." | > | anonymous | > | Lack of brains hinders research - The Columbus Dispatch, April 16 | > _________________________________________________________________________ > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Jim Durbin -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 12:44:51 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA12898; Thu, 23 Jan 1997 12:43:06 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA12882; Thu, 23 Jan 1997 12:43:05 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA09569; Thu, 23 Jan 1997 12:42:54 -0800 Received: from ishtar.paradigmsim.com (ishtar.paradigmsim.com [206.7.114.152]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10842 for ; Thu, 23 Jan 1997 12:42:50 -0800 Received: from ishtar.paradigmsim.com (ishtar.paradigmsim.com [206.7.114.152]) by ishtar.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA08782 for ; Thu, 23 Jan 1997 14:41:40 -0600 Sender: chuck@paradigmsim.com Message-ID: <32E7CD03.15FB@paradigmsim.com> Date: Thu, 23 Jan 1997 14:41:39 -0600 From: Charles Walters X-Mailer: Mozilla 3.0 (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: info-performer@sgi.com Subject: MultiGen texture problem. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hello! I have an interesting texture problem running MultiGen (14.1, 14.2, and Series II) on a high impact. The problem started when I upgraded to IRIX 6.2 - basically, some textures (usually with 2:1, 4:1, 1:4, or 1:2 aspect ratio) appear as broad bands of color on the MultiGen desktop but behave correctly in perfly and vega. (The textures show up correctly in the texture editor and also on the series II texture palette.) The impact has one TRAM and most of the recommended patches from SGI. We have one other machine like this one and it exhibits the same problem. I've tried it on two other impacts, both with 4 TRAMS, and the texture appeared fine on one but not on the other. I've compared patches with the 4TRAM impact which works, but haven't been able to find out what's causing the problem. Has anyone heard of anything like this? I'm including a sample texture cliffx2.rgb, and a screen capture of what it looks like on the MultiGen desktop - snap.rgb. Thanks, Charles. P.S. (All the 6.2 impacts at MultiGen have 4TRAMS - they have not seen this problem.) -- ================================================================= Charles Walters Database Engineering 14900 Landmark Blvd. #400 chuck@paradigmsim.com Dallas, TX 75240 www.paradigmsim.com ================================================================= ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 13:09:24 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA13167; Thu, 23 Jan 1997 13:07:01 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA13151; Thu, 23 Jan 1997 13:07:00 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA11624; Thu, 23 Jan 1997 13:06:50 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA16460 for ; Thu, 23 Jan 1997 13:06:37 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA21551; Thu, 23 Jan 97 15:04:39 -0500 Date: Thu, 23 Jan 97 15:04:39 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701232004.AA21551@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: pfStats Status: O Doug Price said: > I have an application which uses pfFrameStats (obtained from the > pfChannel) to gather pfFrameStats. This works fine. In the man pages it says > that the pfStats can also be gathered using the pfFrameStats and even shows > examples to this effect. When I try this, the values I get back seem to be > reasonable, but I get the following warning every frame: > > => warn pfOpenStats(pfStats*) for 0x18ca86e0 ignored > Already have a different opened pfStats=0x18ba3d20 mask=0x1. ( Error 0) > > I, however, have not created any pfStats instances. Is there a default pfStats > created by performer that I need to close to avoid getting this message? Me too - I'm using OpenGL/Perf 2.2 (recent beta)/iR and also IrisGL/Perf 2.0.2/RE2 and I recollect that both seem to say the same thing as Doug is getting - although I only get the message once whenever I turn stats on. Since stats are not a "real issue" - in that they are turned off during real simulation, I hadn't worried too much about it. If (as Doug sees), they appear every frame though, you are going to get bad timings because of the time it takes to print the message itself. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 13:07:25 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA13114; Thu, 23 Jan 1997 13:04:07 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA13098; Thu, 23 Jan 1997 13:04:06 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA11385; Thu, 23 Jan 1997 13:03:55 -0800 Received: from indy3.gstone.com (indy3.gstone.com [199.35.226.23]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA15649 for ; Thu, 23 Jan 1997 13:03:54 -0800 Received: from [199.35.226.167] (dstipe.gstone.com [199.35.226.167]) by indy3.gstone.com (8.8.3/8.8.3) with SMTP id NAA02155 for ; Thu, 23 Jan 1997 13:02:51 -0800 (PST) Date: Thu, 23 Jan 1997 13:02:51 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.com From: dstipe@indy3.gstone.com (Daniel Stipe) Subject: ERDAS Imagine Format Status: O Greetings, I am about to receive data in the ERDAS Imagine format. Can anyone tell me about the format, vector me to a performer loader, or tell me how to get the data into MultiGen so that I can use it in a Performer-based application? Thanks Dan Stipe Dan Stipe - Sr. Staff Member Tele: (619) 974-6300 ext. 176 /\/\/\ GreyStone Technology, Inc. fax: (619) 974-6303 / /\/\ \ 4950 Murphy Canyon Road e-mail: dstipe@gstone.com \ \/\/ / San Diego, CA 92123-4325 web: http://www.gstone.com/ \/\/\/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 13:31:48 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA13359; Thu, 23 Jan 1997 13:28:22 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA13343; Thu, 23 Jan 1997 13:28:21 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA13587; Thu, 23 Jan 1997 13:28:11 -0800 Received: from ishtar.paradigmsim.com (ishtar.paradigmsim.com [206.7.114.152]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA21472 for ; Thu, 23 Jan 1997 13:28:09 -0800 Received: from ishtar.paradigmsim.com (ishtar.paradigmsim.com [206.7.114.152]) by ishtar.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA08916 for ; Thu, 23 Jan 1997 15:26:58 -0600 Sender: chuck@paradigmsim.com Message-ID: <32E7D7A2.59E2@paradigmsim.com> Date: Thu, 23 Jan 1997 15:26:58 -0600 From: Charles Walters X-Mailer: Mozilla 3.0 (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Re: MultiGen texture problem. References: <32E7CD03.15FB@paradigmsim.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Uhhh... Never mind! Never mind! The problem seems to be igloo - the ogl version works fine. If at some point a patch is generated for the problem with older versions of MultiGen (which are not open_gl) I will pass it along. Regards, Charles. Charles Walters wrote: > > Hello! > > I have an interesting texture problem running MultiGen (14.1, 14.2, and > Series II) on a high impact. The problem started when I upgraded to > IRIX 6.2 - basically, some textures (usually with 2:1, 4:1, 1:4, or 1:2 > aspect ratio) appear as broad bands of color on the MultiGen desktop but > behave correctly in perfly and vega. (The textures show up correctly in > the texture editor and also on the series II texture palette.) > > The impact has one TRAM and most of the recommended patches from SGI. > We have one other machine like this one and it exhibits the same > problem. I've tried it on two other impacts, both with 4 TRAMS, and the > texture appeared fine on one but not on the other. > > I've compared patches with the 4TRAM impact which works, but haven't > been able to find out what's causing the problem. Has anyone heard of > anything like this? > > I'm including a sample texture cliffx2.rgb, and a screen capture of what > it looks like on the MultiGen desktop - snap.rgb. > > Thanks, > > Charles. > > P.S. (All the 6.2 impacts at MultiGen have 4TRAMS - they have not seen > this problem.) > -- > ================================================================= > Charles Walters > Database Engineering > 14900 Landmark Blvd. #400 chuck@paradigmsim.com > Dallas, TX 75240 www.paradigmsim.com > ================================================================= > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com -- ================================================================= Charles Walters Database Engineering 14900 Landmark Blvd. #400 chuck@paradigmsim.com Dallas, TX 75240 www.paradigmsim.com ================================================================= ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 14:16:15 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA13691; Thu, 23 Jan 1997 14:13:59 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA13675; Thu, 23 Jan 1997 14:13:58 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA17940; Thu, 23 Jan 1997 14:13:45 -0800 Received: from bur.visidyne.com (netsafe-outer.bur.visidyne.com [204.180.72.4]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA02685 for ; Thu, 23 Jan 1997 14:13:42 -0800 Received: from spock.hsv.visidyne.com (spock.hsv.visidyne.com [207.60.194.10]) by bur.visidyne.com (8.6.11/8.6.6) with SMTP id RAA01597 for ; Thu, 23 Jan 1997 17:13:17 -0500 Organization: Visidyne Inc. Message-Id: <2.2.32.19970123221553.006ae730@mail.bur.visidyne.com> X-Sender: sartor@mail.bur.visidyne.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jan 1997 16:15:53 -0600 To: info-performer@sgi.com From: ken sartor Subject: very bright lights Status: O Greetings, For an effect that i am trying to achieve, it would be very nice to have *EXTREMELY* bright lights... But, when i just naively crank up the light, i do not get the effect i want. What happens is that all the geometry is affected in the way i want (when the light is sufficiently bright, it turns white) but the texture is clamped to some value (objects that are textured and already on white geometry are unaffected by brightning the light source above 1). The effect i want is for all objects to be brightened by the extremely bright light source and, if it is sufficiently bright, to turn white. Is there some way to achieve this effect? Note that i want a method that will do this generally for various databases (i.e., i don't want to depend on custom made databases). Thanks in advance! ken ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 15:27:08 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA14379; Thu, 23 Jan 1997 15:25:03 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA14363; Thu, 23 Jan 1997 15:25:02 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA24395; Thu, 23 Jan 1997 15:24:49 -0800 Received: from sd.cts.com (sd.cts.com [192.188.72.28]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA19862 for ; Thu, 23 Jan 1997 15:24:43 -0800 Received: by sd.cts.com (Smail3.1.29.1 #5) id m0vnYSs-0000Q8C; Thu, 23 Jan 97 15:21 PST Date: Thu, 23 Jan 1997 15:21:43 -0800 (PST) From: Gerard Tyra - SA Technology To: ken sartor cc: info-performer@sgi.com Subject: Re: very bright lights In-Reply-To: <2.2.32.19970123221553.006ae730@mail.bur.visidyne.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Ken, You have hit a problem that I have seen in everything from flight simulators to animation systems, ie. lights/color values are clamped to 1.0. So here is my open wish list: 1) Allow values greater than 1.0 to be input and used in the computation. After all, even a dark grey surface will look white if you pump enough light into it. 2) Give me 10/12 bit DACs on the IR. Then I can render a moon lit night scene with values below 128 (or 0.5) but still "spike" the display with values over 3000 for light sources. Is anyone from ASD out there listening? Gerry ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 00:05:14 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id AAA16711; Fri, 24 Jan 1997 00:03:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id AAA16695; Fri, 24 Jan 1997 00:03:50 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA21113; Fri, 24 Jan 1997 00:03:39 -0800 Received: from sgiger.munich.sgi.com ([144.253.192.129]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA10340 for ; Fri, 24 Jan 1997 00:03:38 -0800 Received: from sgihan.hannover.sgi.com by sgiger.munich.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/940406.SGI) id JAA22284; Fri, 24 Jan 1997 09:03:28 +0100 Received: from elwood.hannover.sgi.com by sgihan.hannover.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/930416.SGI) id JAA16976; Fri, 24 Jan 1997 09:02:42 +0100 Received: by elwood.hannover.sgi.com (950413.SGI.8.6.12/930416.SGI) id JAA13286; Fri, 24 Jan 1997 09:02:05 +0100 Date: Fri, 24 Jan 1997 09:02:05 +0100 From: axel@elwood.hannover.sgi.com (Axel Sammet) Message-Id: <9701240902.ZM13284@elwood.hannover.sgi.com> In-Reply-To: ken sartor "very bright lights" (Jan 23, 16:15) References: <2.2.32.19970123221553.006ae730@mail.bur.visidyne.com> X-Face: )4zw8$b8#wp^oSG2'O`ro}5!0,`Eva\CCV;-:WZqI5p?yE_i)S^|OJHS3MZ*51G])5VD]2< W|;c`-$RB#fhJyqOqzxMj;$,G\])yHwzuz?[XfMC{=DB+#,~tN58SWzXz.3~r!/@Q X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: ken sartor , info-performer@sgi.com Subject: Re: very bright lights Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Ken The problem with commonly available diplays is, that they give every pixel the same amount of time. Therefore the intensity is physically limited and you need a longer drawing time for the Cathod Ray for the bright lights sources to become REALLY bright. This is commonly referred to as calligraphic lights and performer in Infinite Reality supports the control of a calligraphic lights board from EIS. All the bright lights are drawn in the vertical retrace phase of the drawing phase and allows you to place quite a number(several thousand) of calligraphic lights in this period. However, it reduces the time available to draw the initial frame. Be sure you really need these bright lights, since the board and the Diplays/Projectors are pretty expensive. Let me know if you need more details/contacts. Axel On Jan 23, 16:15, ken sartor wrote: > Subject: very bright lights > > Greetings, > > For an effect that i am trying to achieve, it would be > very nice to have *EXTREMELY* bright lights... But, when > i just naively crank up the light, i do not get the > effect i want. What happens is that all the geometry > is affected in the way i want (when the light is sufficiently > bright, it turns white) but the texture is clamped to some > value (objects that are textured and already on white > geometry are unaffected by brightning the light source > above 1). > > The effect i want is for all objects to be brightened by > the extremely bright light source and, if it is sufficiently > bright, to turn white. Is there some way to achieve this > effect? Note that i want a method that will do this generally > for various databases (i.e., i don't want to depend on > custom made databases). > > Thanks in advance! > > ken > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from ken sartor -- _____________________________________________________________________ Axel Sammet, SE Visual Simulation Silicon Graphics GmbH | Tel: +49 511 90172-29 Ahrensburger Strasse 3 | Fax: +49 511 6138-115 30659 Hannover | VM #: 59191 M/S: IDE-3140 Germany | E-Mail: axel@hannover.sgi.com _____________________________________________________________________ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 23 23:41:27 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id XAA16513; Thu, 23 Jan 1997 23:40:10 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id XAA16497; Thu, 23 Jan 1997 23:40:09 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA18955; Thu, 23 Jan 1997 23:39:57 -0800 Received: from cesit1.unifi.it (cesit1.unifi.it [150.217.1.31]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA07151 for ; Thu, 23 Jan 1997 23:39:53 -0800 Received: from INGFI1.ING.UNIFI.IT by CESIT1.UNIFI.IT (PMDF V5.0-4 #3688) id <01IEL2MVNC68000O1K@CESIT1.UNIFI.IT> for info-performer@sgi.com; Fri, 24 Jan 1997 08:39:30 +0100 (MET) Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Fri, 24 Jan 1997 08:40:08 +0100 (MET) Received: from vesna.dsi.unifi.it by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA10147; Fri, 24 Jan 1997 08:39:17 +0100 Received: by vesna.dsi.unifi.it (950413.SGI.8.6.12) id IAA09442; Fri, 24 Jan 1997 08:39:05 +0100 Date: Fri, 24 Jan 1997 08:39:05 +0100 From: Luigi Rella Subject: Re: Terrain To: renjye@python.tamu.edu, info-performer@sgi.com Message-id: <9701240839.ZM9440@vesna.dsi.unifi.it> MIME-version: 1.0 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Status: O I use my software (the cheapest). I write a sort of importer that read elevation data file and texture image file and build a 3D representation of the terrain. I have some problems in with the textures management (see Angus's Reply) but I can give you my sw and we can work together to resolve the remaining problems. See you later. -- ----------------------------------------------------------------------- | | | Luigi Rella | | | | Visual Information Processing Lab. | | CS Dept. - University of Florence | | e-mail: rella@aguirre.ing.unifi.it | | tel: +39.55.4796365 | ! | ----------------------------------------------------------------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 03:09:39 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA17181; Fri, 24 Jan 1997 03:08:28 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA17162; Fri, 24 Jan 1997 03:08:27 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA26400; Fri, 24 Jan 1997 03:06:59 -0800 Received: from logrus.rada.kiev.ua (logrus.rada.kiev.ua [194.44.144.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA02780; Fri, 24 Jan 1997 03:05:56 -0800 Received: from polytech.kiev.ua ([194.44.128.5]) by logrus.rada.kiev.ua (8.6.12/0418) with ESMTP id NAA07245; Fri, 24 Jan 1997 13:58:32 +0200 Received: from rr.UUCP by polytech.kiev.ua with UUCP id LAA02339; (8.6.12/zah/1.1) Fri, 24 Jan 1997 11:20:36 +0200 Received: by rr.polytech.kiev.ua (UUPC/@ v6.14g, 06Jun95) id AA29127; Thu, 23 Jan 1997 20:21:24 +0300 (MSK) To: info-performer-request@sgi.com Cc: info-performer@sgi.com Message-Id: Organization: home From: "Roman Rolinksy" Date: Thu, 23 Jan 97 20:21:24 +0300 X-Mailer: BML [MS/DOS Beauty Mail v1.36h] Subject: admin request Lines: 2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 38 Status: O unsubscribe roma@rr.polytech.kiev.ua ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 03:28:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA17248; Fri, 24 Jan 1997 03:26:48 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA17232; Fri, 24 Jan 1997 03:26:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA26800; Fri, 24 Jan 1997 03:26:35 -0800 Received: from sys4.cambridge.uk.psi.net (sys4.cambridge.uk.psi.net [154.32.106.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA06784; Fri, 24 Jan 1997 03:26:31 -0800 Received: from hegel.UUCP by sys4.cambridge.uk.psi.net (8.7.5/SMI-5.5-UKPSINet) id JAA23437; Fri, 24 Jan 1997 09:20:53 GMT Received: from tswl (cookstown) by tswl.co.uk (4.1/SMI-4.1) id AA02024; Fri, 24 Jan 97 09:23:31 GMT Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="BeyondBoundary_1_Fri_Jan_24_09:17:39_1997__29" To: axel@elwood.hannover.sgi.com (Axel Sammet), info-performer@sgi.com, ken sartor From: Roger Morris Subject: Re: very bright lights Date: Fri, 24 Jan 1997 09:17:35 -0800 X-Beyondmail-Priority: 1 Message-Id: Conversation-Id: <9701240902.ZM13284@elwood.hannover.sgi.com> In-Reply-To: <9701240902.ZM13284@elwood.hannover.sgi.com> Reply-To: Roger Morris Status: O --BeyondBoundary_1_Fri_Jan_24_09:17:39_1997__29 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7Bit X-Mailer: BeyondMail for Windows/SMTP 2.2 Ken & Axel, Don't get confused between light SOURCES (which is what Ken is talking about) and light POINTS (which can be drawn calligraphically, as Axel describes, but don't illuminate the scene, no matter how bright they get!). Ken, are you using DECAL textures? These are unaffected by shading. You should use modulated textures on a white polygon, instead. > From: axel@elwood.hannover.sgi.com (Axel Sammet), on 24/01/97 09:02: > Hi Ken > > The problem with commonly available diplays is, that they give every pixel > the same amount of time. Therefore the intensity is physically limited and > you need a longer drawing time for the Cathod Ray for the bright lights > sources to become REALLY bright. > This is commonly referred to as calligraphic lights and performer in > Infinite Reality supports the control of a calligraphic lights board from > EIS. > All the bright lights are drawn in the vertical retrace phase of the > drawing phase and allows you to place quite a number(several thousand) of > calligraphic lights in this period. However, it reduces the time available > to draw the initial frame. > Be sure you really need these bright lights, since the board and the > Diplays/Projectors are pretty expensive. > > Let me know if you need more details/contacts. > > Axel > > On Jan 23, 16:15, ken sartor wrote: > > Subject: very bright lights > > > > Greetings, > > > > For an effect that i am trying to achieve, it would be > > very nice to have *EXTREMELY* bright lights... But, when > > i just naively crank up the light, i do not get the > > effect i want. What happens is that all the geometry > > is affected in the way i want (when the light is sufficiently > > bright, it turns white) but the texture is clamped to some > > value (objects that are textured and already on white > > geometry are unaffected by brightning the light source > > above 1). > > > > The effect i want is for all objects to be brightened by > > the extremely bright light source and, if it is sufficiently > > bright, to turn white. Is there some way to achieve this > > effect? Note that i want a method that will do this generally > > for various databases (i.e., i don't want to depend on > > custom made databases). > > > > Thanks in advance! > > > > ken > > > > ======================================================================= > > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > > Submissions: info-performer@sgi.com > > Admin. requests: info-performer-request@sgi.com > >-- End of excerpt from ken sartor > > > > -- > > _____________________________________________________________________ > > Axel Sammet, SE > Visual Simulation > > Silicon Graphics GmbH | Tel: +49 511 90172-29 > Ahrensburger Strasse 3 | Fax: +49 511 6138-115 > 30659 Hannover | VM #: 59191 M/S: IDE-3140 > Germany | E-Mail: axel@hannover.sgi.com > _____________________________________________________________________ > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > > ========================== Roger Morris TRANSFORMATION SOFTWARE Applications Engineer Thame Park Road TEL: 01844 261456 Thame FAX: 01844 260056 Oxon, OX9 3UQ E-mail: rmorris@tswl.co.uk ========================== --BeyondBoundary_1_Fri_Jan_24_09:17:39_1997__29 Content-Type: application/octet-stream; name="ATTRIBS.BND" Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="ATTRIBS.BND" QmV5b25kIFBhY2tlZCBBdHRyaWJ1dGVzADMtABUAKAAAAAAAUmU6IHZlcnkg YnJpZ2h0IGxpZ2h0cwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHJtb3JyaXMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8Qk1TTVRQODU0MTI2MDA1MnJt b3JyaXMAQmV5b25kIFByb3ByaWV0YXJ5IERhdGEaAAAAAAQAAAAAAAAADwAt AAAAAAAAAAAAAAAAAAAAAAAAAAAAQ29udmVyc2F0aW9uIElkLDw5NzAxMjQw OTAyLlpNMTMyODRAZWx3b29kLmhhbm5vdmVyLnNnaS5jb20+BAAAAAAAAAAQ AAkAAAAAAAAAAAAAAAAAAAAAAAAAAABNZXNzYWdlIEVuY29kaW5nCElTTy04 ODU5AQAAAAAAAAAVAAMAAAAAAAAAAAAAAAAAAAAAAAAAAABVc2UgUHJvcG9y dGlvbmFsIEZvbnQBAAEJAAAAAAAAAA0AKwAAAAAAAAAAAAAAAAAAAAAAAAAA AFByZXZpb3VzIEZyb20qYXhlbEBlbHdvb2QuaGFubm92ZXIuc2dpLmNvbSAo QXhlbCBTYW1tZXQpDQAAAAAAAAALAE8AAAAAAAAAAAAAAAAAAAAAAAAAAABQ cmV2aW91cyBUb00AzgcCAAkA//8lAAAAAiUAJGtlbiBzYXJ0b3IgPHNhcnRv ckBidXIudmlzaWR5bmUuY29tPhcAFmluZm8tcGVyZm9ybWVyQHNnaS5jb20R AAAAAAAAAA0ABgAAAAAAAAAAAAAAAAAAAAAAAAAAAE9yaWdpbmFsIHRleHQA AAAAAAARAAAAAAAAAAQAChEAAAAAAAAAAAAAAAAAAAAAAAAAAFRleHT3DUtl biAmIEF4ZWwsCgpEb24ndCBnZXQgY29uZnVzZWQgYmV0d2VlbiBsaWdodCBT T1VSQ0VTICh3aGljaCBpcyB3aGF0IEtlbiBpcyB0YWxraW5nIGFib3V0KQph bmQgbGlnaHQgUE9JTlRTICh3aGljaCBjYW4gYmUgZHJhd24gY2FsbGlncmFw aGljYWxseSwgYXMgQXhlbCBkZXNjcmliZXMsIGJ1dApkb24ndCBpbGx1bWlu YXRlIHRoZSBzY2VuZSwgbm8gbWF0dGVyIGhvdyBicmlnaHQgdGhleSBnZXQh KS4KCktlbiwgIGFyZSB5b3UgdXNpbmcgREVDQUwgdGV4dHVyZXM/ICBUaGVz ZSBhcmUgdW5hZmZlY3RlZCBieSBzaGFkaW5nLiAgWW91IHNob3VsZAp1c2Ug bW9kdWxhdGVkIHRleHR1cmVzIG9uIGEgd2hpdGUgcG9seWdvbiwgaW5zdGVh ZC4KCj4gIEZyb206IGF4ZWxAZWx3b29kLmhhbm5vdmVyLnNnaS5jb20gKEF4 ZWwgU2FtbWV0KSwgb24gMjQvMDEvOTcgMDk6MDI6Cj4gIEhpIEtlbgo+ICAK PiAgVGhlIHByb2JsZW0gd2l0aCBjb21tb25seSBhdmFpbGFibGUgZGlwbGF5 cyBpcywgdGhhdCB0aGV5IGdpdmUgZXZlcnkgcGl4ZWwKPiAgdGhlIHNhbWUg YW1vdW50IG9mIHRpbWUuIFRoZXJlZm9yZSB0aGUgaW50ZW5zaXR5IGlzIHBo eXNpY2FsbHkgbGltaXRlZCBhbmQKPiAgeW91IG5lZWQgYSBsb25nZXIgZHJh d2luZyB0aW1lIGZvciB0aGUgQ2F0aG9kIFJheSBmb3IgdGhlIGJyaWdodCBs aWdodHMKPiAgc291cmNlcyB0byBiZWNvbWUgUkVBTExZIGJyaWdodC4KPiAg VGhpcyBpcyBjb21tb25seSByZWZlcnJlZCB0byBhcyBjYWxsaWdyYXBoaWMg bGlnaHRzIGFuZCBwZXJmb3JtZXIgaW4KPiAgSW5maW5pdGUgUmVhbGl0eSBz dXBwb3J0cyB0aGUgY29udHJvbCBvZiBhIGNhbGxpZ3JhcGhpYyBsaWdodHMg Ym9hcmQgZnJvbQo+ICBFSVMuCj4gIEFsbCB0aGUgYnJpZ2h0IGxpZ2h0cyBh cmUgZHJhd24gaW4gdGhlIHZlcnRpY2FsIHJldHJhY2UgcGhhc2Ugb2YgdGhl Cj4gIGRyYXdpbmcgcGhhc2UgYW5kIGFsbG93cyB5b3UgdG8gcGxhY2UgcXVp dGUgYSBudW1iZXIoc2V2ZXJhbCB0aG91c2FuZCkgb2YKPiAgY2FsbGlncmFw aGljIGxpZ2h0cyBpbiB0aGlzIHBlcmlvZC4gSG93ZXZlciwgaXQgcmVkdWNl cyB0aGUgdGltZSBhdmFpbGFibGUKPiAgdG8gZHJhdyB0aGUgaW5pdGlhbCBm cmFtZS4KPiAgQmUgc3VyZSB5b3UgcmVhbGx5IG5lZWQgdGhlc2UgYnJpZ2h0 IGxpZ2h0cywgc2luY2UgdGhlIGJvYXJkIGFuZCB0aGUKPiAgRGlwbGF5cy9Q cm9qZWN0b3JzIGFyZSBwcmV0dHkgZXhwZW5zaXZlLgo+ICAKPiAgTGV0IG1l IGtub3cgaWYgeW91IG5lZWQgbW9yZSBkZXRhaWxzL2NvbnRhY3RzLgo+ICAK PiAgQXhlbAo+ICAKPiAgT24gSmFuIDIzLCAxNjoxNSwga2VuIHNhcnRvciB3 cm90ZToKPiAgPiBTdWJqZWN0OiB2ZXJ5IGJyaWdodCBsaWdodHMKPiAgPgo+ ICA+IEdyZWV0aW5ncywKPiAgPgo+ICA+IEZvciBhbiBlZmZlY3QgdGhhdCBp IGFtIHRyeWluZyB0byBhY2hpZXZlLCBpdCB3b3VsZCBiZQo+ICA+IHZlcnkg bmljZSB0byBoYXZlICpFWFRSRU1FTFkqIGJyaWdodCBsaWdodHMuLi4gQnV0 LCB3aGVuCj4gID4gaSBqdXN0IG5haXZlbHkgY3JhbmsgdXAgdGhlIGxpZ2h0 LCBpIGRvIG5vdCBnZXQgdGhlCj4gID4gZWZmZWN0IGkgd2FudC4gIFdoYXQg aGFwcGVucyBpcyB0aGF0IGFsbCB0aGUgZ2VvbWV0cnkKPiAgPiBpcyBhZmZl Y3RlZCBpbiB0aGUgd2F5IGkgd2FudCAod2hlbiB0aGUgbGlnaHQgaXMgc3Vm ZmljaWVudGx5Cj4gID4gYnJpZ2h0LCBpdCB0dXJucyB3aGl0ZSkgYnV0IHRo ZSB0ZXh0dXJlIGlzIGNsYW1wZWQgdG8gc29tZQo+ICA+IHZhbHVlIChvYmpl Y3RzIHRoYXQgYXJlIHRleHR1cmVkIGFuZCBhbHJlYWR5IG9uIHdoaXRlCj4g ID4gZ2VvbWV0cnkgYXJlIHVuYWZmZWN0ZWQgYnkgYnJpZ2h0bmluZyB0aGUg bGlnaHQgc291cmNlCj4gID4gYWJvdmUgMSkuCj4gID4KPiAgPiBUaGUgZWZm ZWN0IGkgd2FudCBpcyBmb3IgYWxsIG9iamVjdHMgdG8gYmUgYnJpZ2h0ZW5l ZCBieQo+ICA+IHRoZSBleHRyZW1lbHkgYnJpZ2h0IGxpZ2h0IHNvdXJjZSBh bmQsIGlmIGl0IGlzIHN1ZmZpY2llbnRseQo+ICA+IGJyaWdodCwgdG8gdHVy biB3aGl0ZS4gIElzIHRoZXJlIHNvbWUgd2F5IHRvIGFjaGlldmUgdGhpcwo+ ICA+IGVmZmVjdD8gIE5vdGUgdGhhdCBpIHdhbnQgYSBtZXRob2QgdGhhdCB3 aWxsIGRvIHRoaXMgZ2VuZXJhbGx5Cj4gID4gZm9yIHZhcmlvdXMgZGF0YWJh c2VzIChpLmUuLCBpIGRvbid0IHdhbnQgdG8gZGVwZW5kIG9uCj4gID4gY3Vz dG9tIG1hZGUgZGF0YWJhc2VzKS4KPiAgPgo+ICA+IFRoYW5rcyBpbiBhZHZh bmNlIQo+ICA+Cj4gID4ga2VuCj4gID4KPiAgPiA9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQo+ICA+IExpc3QgQXJjaGl2ZXMsIEZBUSwgRlRQOiAgaHR0 cDovL3d3dy5zZ2kuY29tL1RlY2hub2xvZ3kvUGVyZm9ybWVyLwo+ICA+ICAg ICAgICAgICAgIFN1Ym1pc3Npb25zOiAgaW5mby1wZXJmb3JtZXJAc2dpLmNv bQo+ICA+ICAgICAgICAgQWRtaW4uIHJlcXVlc3RzOiAgaW5mby1wZXJmb3Jt ZXItcmVxdWVzdEBzZ2kuY29tCj4gID4tLSBFbmQgb2YgZXhjZXJwdCBmcm9t IGtlbiBzYXJ0b3IKPiAgCj4gIAo+ICAKPiAgLS0gCj4gIAo+ICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPiAgCj4gIEF4ZWwgU2FtbWV0LCBTRQo+ICBW aXN1YWwgU2ltdWxhdGlvbgo+ICAKPiAgU2lsaWNvbiBHcmFwaGljcyBHbWJI ICAgICAgICAgfCBUZWw6ICAgICs0OSA1MTEgOTAxNzItMjkKPiAgQWhyZW5z YnVyZ2VyIFN0cmFzc2UgMyAgICAgICAgfCBGYXg6ICAgICs0OSA1MTEgNjEz OC0xMTUKPiAgMzA2NTkgSGFubm92ZXIgICAgICAgICAgICAgICAgfCBWTSAj OiAgIDU5MTkxICBNL1M6IElERS0zMTQwCj4gIEdlcm1hbnkgICAgICAgICAg ICAgICAgICAgICAgIHwgRS1NYWlsOiBheGVsQGhhbm5vdmVyLnNnaS5jb20K PiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gID09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Cj4gIExpc3QgQXJjaGl2ZXMsIEZBUSwgRlRQOiAgaHR0 cDovL3d3dy5zZ2kuY29tL1RlY2hub2xvZ3kvUGVyZm9ybWVyLwo+ICAgICAg ICAgICAgICBTdWJtaXNzaW9uczogIGluZm8tcGVyZm9ybWVyQHNnaS5jb20K PiAgICAgICAgICBBZG1pbi4gcmVxdWVzdHM6ICBpbmZvLXBlcmZvcm1lci1y ZXF1ZXN0QHNnaS5jb20KPiAgCj4gIAoKPT09PT09PT09PT09PT09PT09PT09 PT09PT0KUm9nZXIgTW9ycmlzCQkJCVRSQU5TRk9STUFUSU9OIFNPRlRXQVJF CkFwcGxpY2F0aW9ucyBFbmdpbmVlcgkJVGhhbWUgUGFyayBSb2FkClRFTDog MDE4NDQgMjYxNDU2CQkJVGhhbWUKRkFYOiAwMTg0NCAyNjAwNTYJCQlPeG9u LCBPWDkgM1VRCkUtbWFpbDogcm1vcnJpc0B0c3dsLmNvLnVrCj09PT09PT09 PT09PT09PT09PT09PT09PT09DQMDAPcNBgMFAAIAAABaAAEAAQABAH0JAAAA AAAAAgB+CSgAAAAAAAAAAQCmCdUCAAAAAAAAAgB7DCgAAAAAAAAAAQCjDFUB AAAAAAAAOP8AAAAAAACQAQAAAAAAAAAATVMgU2FucyBTZXJpZgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAOP8AAAAAAAC8AgABAAAAAAAATVMgU2FucyBTZXJp ZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAwAAQANAA0AAQAOAFsAAQBc AKkAAQCqAOYAAQDnAOcAAQDoADkBAQA6AW0BAQBuAW4BAQBvAbYBAQC3AcAB AQDBAcQBAQDFARICAQATAmACAQBhAqsCAQCsAs8CAQDQAhcDAQAYA2QDAQBl A2wDAQBtA7QDAQC1AwEEAQACBE8EAQBQBG0EAQBuBLUEAQC2BOEEAQDiBOUE AQDmBBcFAQAYBRsFAQAcBSMFAQAkBScFAQAoBU4FAQBPBW8FAQBwBXQFAQB1 BYQFAQCFBYkFAQCKBcUFAQDGBQMGAQAEBjwGAQA9BncGAQB4BroGAQC7BvoG AQD7BjUHAQA2B3EHAQByB4AHAQCBB4UHAQCGB8MHAQDEBwUIAQAGCEQIAQBF CIgIAQCJCMQIAQDFCOEIAQDiCOYIAQDnCP4IAQD/CAMJAQAECQwJAQANCREJ AQASCV4JAQBfCaYJAQCnCdwJAQDdCRoKAQAbCkAKAQBBCkQKAQBFCkgKAQBJ CkwKAQBNClMKAQBUClcKAQBYCqAKAQChCqQKAQClCrcKAQC4CswKAQDNCtAK AQDRCgwLAQANC0gLAQBJC4gLAQCJC8kLAQDKCxIMAQATDF0MAQBeDKMMAQCk DNcMAQDYDBMNAQAUDRcNAQAYDRsNAQAcDRwNAQAdDTcNAQA4DV8NAQBgDYYN AQCHDaANAQChDcINAQDDDd0NAQDeDfgNAAAAAAAAAAAAAAAAZAABpAEBSAMB 7AQBkAYBNAgB2AkBfAsBIA0BxA4BaBABDBIBsBMBVBUB+BZyAAAAAAAAAAAA ABAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAEF0dGFjaG1lbnQgQ291bnQEAAAA AAA= --BeyondBoundary_1_Fri_Jan_24_09:17:39_1997__29-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 03:40:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA17298; Fri, 24 Jan 1997 03:39:19 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA17282; Fri, 24 Jan 1997 03:39:18 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA27176; Fri, 24 Jan 1997 03:39:07 -0800 Received: from sgiger.munich.sgi.com ([144.253.192.129]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA08194 for ; Fri, 24 Jan 1997 03:39:05 -0800 Received: from sgihan.hannover.sgi.com by sgiger.munich.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/940406.SGI) id MAA25042; Fri, 24 Jan 1997 12:38:55 +0100 Received: from elwood.hannover.sgi.com by sgihan.hannover.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/930416.SGI) id MAA18919; Fri, 24 Jan 1997 12:38:11 +0100 Received: by elwood.hannover.sgi.com (950413.SGI.8.6.12/930416.SGI) id MAA13761; Fri, 24 Jan 1997 12:37:37 +0100 Date: Fri, 24 Jan 1997 12:37:37 +0100 From: axel@elwood.hannover.sgi.com (Axel Sammet) Message-Id: <9701241237.ZM13759@elwood.hannover.sgi.com> In-Reply-To: Roger Morris "Re: very bright lights" (Jan 24, 9:17) References: X-Face: )4zw8$b8#wp^oSG2'O`ro}5!0,`Eva\CCV;-:WZqI5p?yE_i)S^|OJHS3MZ*51G])5VD]2< W|;c`-$RB#fhJyqOqzxMj;$,G\])yHwzuz?[XfMC{=DB+#,~tN58SWzXz.3~r!/@Q X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Roger Morris , info-performer@sgi.com, ken sartor Subject: Re: very bright lights Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Roger You're absolutly right! Of course, Calligraphic lights do not illuminate the scene. I didn't read careful enough ;-) Axel On Jan 24, 9:17, Roger Morris wrote: > Subject: Re: very bright lights > > Ken & Axel, > > Don't get confused between light SOURCES (which is what Ken is talking about) > and light POINTS (which can be drawn calligraphically, as Axel describes, but > don't illuminate the scene, no matter how bright they get!). > > Ken, are you using DECAL textures? These are unaffected by shading. You > should > use modulated textures on a white polygon, instead. > > > From: axel@elwood.hannover.sgi.com (Axel Sammet), on 24/01/97 09:02: > > Hi Ken > > > > The problem with commonly available diplays is, that they give every pixel > > the same amount of time. Therefore the intensity is physically limited and > > you need a longer drawing time for the Cathod Ray for the bright lights > > sources to become REALLY bright. > > This is commonly referred to as calligraphic lights and performer in > > Infinite Reality supports the control of a calligraphic lights board from > > EIS. > > All the bright lights are drawn in the vertical retrace phase of the > > drawing phase and allows you to place quite a number(several thousand) of > > calligraphic lights in this period. However, it reduces the time available > > to draw the initial frame. > > Be sure you really need these bright lights, since the board and the > > Diplays/Projectors are pretty expensive. > > > > Let me know if you need more details/contacts. > > > > Axel > > > > On Jan 23, 16:15, ken sartor wrote: > > > Subject: very bright lights > > > > > > Greetings, > > > > > > For an effect that i am trying to achieve, it would be > > > very nice to have *EXTREMELY* bright lights... But, when > > > i just naively crank up the light, i do not get the > > > effect i want. What happens is that all the geometry > > > is affected in the way i want (when the light is sufficiently > > > bright, it turns white) but the texture is clamped to some > > > value (objects that are textured and already on white > > > geometry are unaffected by brightning the light source > > > above 1). > > > > > > The effect i want is for all objects to be brightened by > > > the extremely bright light source and, if it is sufficiently > > > bright, to turn white. Is there some way to achieve this > > > effect? Note that i want a method that will do this generally > > > for various databases (i.e., i don't want to depend on > > > custom made databases). > > > > > > Thanks in advance! > > > > > > ken > > > > > > ======================================================================= > > > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > > > Submissions: info-performer@sgi.com > > > Admin. requests: info-performer-request@sgi.com > > >-- End of excerpt from ken sartor > > > > > > > > -- > > > > _____________________________________________________________________ > > > > Axel Sammet, SE > > Visual Simulation > > > > Silicon Graphics GmbH | Tel: +49 511 90172-29 > > Ahrensburger Strasse 3 | Fax: +49 511 6138-115 > > 30659 Hannover | VM #: 59191 M/S: IDE-3140 > > Germany | E-Mail: axel@hannover.sgi.com > > _____________________________________________________________________ > > ======================================================================= > > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > > Submissions: info-performer@sgi.com > > Admin. requests: info-performer-request@sgi.com > > > > > > ========================== > Roger Morris TRANSFORMATION SOFTWARE > Applications Engineer Thame Park Road > TEL: 01844 261456 Thame > FAX: 01844 260056 Oxon, OX9 3UQ > E-mail: rmorris@tswl.co.uk > ========================== > > [ Attachment (application/octet-stream): "ATTRIBS.BND" 7020 bytes > Encoded with "base64" ] >-- End of excerpt from Roger Morris -- _____________________________________________________________________ Axel Sammet, SE Visual Simulation Silicon Graphics GmbH | Tel: +49 511 90172-29 Ahrensburger Strasse 3 | Fax: +49 511 6138-115 30659 Hannover | VM #: 59191 M/S: IDE-3140 Germany | E-Mail: axel@hannover.sgi.com _____________________________________________________________________ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 06:10:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA17667; Fri, 24 Jan 1997 06:09:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA17651; Fri, 24 Jan 1997 06:09:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA04224; Fri, 24 Jan 1997 06:09:06 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id GAA26287 for ; Fri, 24 Jan 1997 06:09:04 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA23813; Fri, 24 Jan 97 08:07:14 -0500 Date: Fri, 24 Jan 97 08:07:14 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701241307.AA23813@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: very bright lights Status: O Gerard Tyra - SA Technology said: > You have hit a problem that I have seen in everything from flight > simulators to animation systems, ie. lights/color values are clamped to 1.0. > > So here is my open wish list: > > 1) Allow values greater than 1.0 to be input and used in the > computation. After all, even a dark grey surface will look white if you > pump enough light into it. Woaaa - be very careful what you wish for. Suppose they did compute things the way you suggest. What would happen to a red surface with RGB values like (1.0,0.1,0.1) - presuming that the colour calculations are done indepenantly in RED, GREEN and BLUE - what would happen? The answer is that all three colour components could go over 1.0 and (presumably) be clamped to 1.0 for display. This would mean that the predominantly red surface would show up as white - but real-world diffuse reflectors don't change colours like that. (Don't get confused with specular reflectors - which are a different matter). > 2) Give me 10/12 bit DACs on the IR. Then I can render a moon lit night > scene with values below 128 (or 0.5) but still "spike" the display with > values over 3000 for light sources. Building DAC's with high precision *and* high speed is a non-trivial problem. There is a real problem with lighting - and some fixes could be attempted, but you have to be really careful. One obvious area is penetration through fog - really bright lights should show through fog better than they do right now, for example. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 06:05:02 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA17642; Fri, 24 Jan 1997 06:03:29 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA17626; Fri, 24 Jan 1997 06:03:29 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA03932; Fri, 24 Jan 1997 06:03:17 -0800 Received: from orange.interpia.net (orange.interpia.net [203.236.128.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA25507 for ; Fri, 24 Jan 1997 06:03:13 -0800 Received: from kossa.soongsil.ac.kr ([203.253.23.98]) by orange.interpia.net (8.8.4/8.8.4) with SMTP id XAA08313 for ; Fri, 24 Jan 1997 23:02:48 +0900 (KST) Message-Id: <3.0.1.32.19970124225821.0078c670@interpia.net> X-Sender: myidisid@interpia.net X-Mailer: Windows Eudora Light Version 3.0.1 beta 4 (32) Date: Fri, 24 Jan 1997 22:58:22 +0900 To: info-performer@sgi.com From: Gil-won Park Subject: How to use performer on Window95/NT in IBM PC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: O Greetings, I have a account on Indy and I can use performer. but Indy is located distant from me about 40KM. Fortunately, I can use network of T1. So, I use exceed 5.0 & Windows95 Pls give me a answer for using IRIX 5.3 remotely in Windows95/NT. Thnks for reading. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 07:16:29 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA17881; Fri, 24 Jan 1997 07:15:00 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA17865; Fri, 24 Jan 1997 07:14:59 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA07698; Fri, 24 Jan 1997 07:14:48 -0800 Received: from despair.paradigmsim.com (despair.paradigmsim.com [206.7.114.164]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA06558 for ; Fri, 24 Jan 1997 07:14:46 -0800 Received: (from angus@localhost) by despair.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA00118 for info-performer@sgi.com; Fri, 24 Jan 1997 09:13:31 -0600 From: "Angus W.S. Henderson" Message-Id: <9701240913.ZM116@despair.paradigmsim.com> Date: Fri, 24 Jan 1997 09:13:31 -0600 In-Reply-To: steve@mred.bgm.link.com (Steve Baker) "Re: very bright lights" (Jan 24, 8:07am) References: <9701241307.AA23813@mred.bgm.link.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Re: very bright lights Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O >What would happen to a red surface with > RGB values like (1.0,0.1,0.1) - presuming that the colour calculations > are done indepenantly in RED, GREEN and BLUE - what would happen? The > answer is that all three colour components could go over 1.0 and (presumably) > be clamped to 1.0 for display. This would mean that the predominantly red > surface would show up as white - but real-world diffuse reflectors don't > change colours like that. (Don't get confused with specular reflectors - > which are a different matter). I disagree. As I understand it the original request was for VERY bright lights, i.e to emulate the effects of overexposure, blinding lights at night etc. In these circumstances the original colour of the database is secondary you just want to burn the light colour onto everything, and as Ken said it's the textured surfaces that limit the effect. I bet the only answer he gets is "use a multi-pass technique" I hate multi pass techniques. ANgus ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 07:26:29 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA17928; Fri, 24 Jan 1997 07:25:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA17912; Fri, 24 Jan 1997 07:25:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA08394; Fri, 24 Jan 1997 07:24:56 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA08325; Fri, 24 Jan 1997 07:24:51 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id PAA05104; Fri, 24 Jan 1997 15:24:47 GMT From: "Angus Dorbie" Message-Id: <9701241524.ZM5102@bitch.reading.sgi.com> Date: Fri, 24 Jan 1997 15:24:47 +0000 In-Reply-To: ken sartor "very bright lights" (Jan 23, 4:15pm) References: <2.2.32.19970123221553.006ae730@mail.bur.visidyne.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: ken sartor , info-performer@sgi.com Subject: Re: very bright lights Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O The problem you describe is caused by OpenGL. Pixel colours are clamped to 1.0 prior to texturing. If you didn't do this you'd see all sorts of banding when you applied dark textures to a bright surface because you simply don't have the precision in the image. The whole problem boils down to precision if you consider that you could use colour tables to apply gain to the image on the screen, so one solution might be to darken everything so that colours are never actually clamped and then use a colour table to apply gain. But expect problems due to lack of sufficient precision. Cheers, Angus. On Jan 23, 4:15pm, ken sartor wrote: > Subject: very bright lights > > Greetings, > > For an effect that i am trying to achieve, it would be > very nice to have *EXTREMELY* bright lights... But, when > i just naively crank up the light, i do not get the > effect i want. What happens is that all the geometry > is affected in the way i want (when the light is sufficiently > bright, it turns white) but the texture is clamped to some > value (objects that are textured and already on white > geometry are unaffected by brightning the light source > above 1). > > The effect i want is for all objects to be brightened by > the extremely bright light source and, if it is sufficiently > bright, to turn white. Is there some way to achieve this > effect? Note that i want a method that will do this generally > for various databases (i.e., i don't want to depend on > custom made databases). > > Thanks in advance! > > ken > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from ken sartor ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 08:59:46 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA18229; Fri, 24 Jan 1997 08:58:29 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA18213; Fri, 24 Jan 1997 08:58:28 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAB14870; Fri, 24 Jan 1997 08:58:17 -0800 Received: from centaure.worldnet.net (centaure.worldnet.net [194.2.128.249]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA26458 for ; Fri, 24 Jan 1997 08:58:10 -0800 Received: from nantes0-007.sct.fr (nantes0-007.sct.fr [194.206.158.7]) by centaure.worldnet.net (8.6.12/8.6.12) with SMTP id RAA05306 for ; Fri, 24 Jan 1997 17:58:07 +0100 Message-Id: <199701241658.RAA05306@centaure.worldnet.net> X-Sender: ceti@worldnet.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jan 1997 17:58:44 +0000 To: info-performer@sgi.com From: ceti@worldnet.net (ceti) Subject: more openGL than perf Status: O Hello, this far from performer and closer to OpenGL, but I've noticed that here there are several OpenGL kings !!! Well, Here's my problem. I used to work under Performer with objects and scenes described with Inventor format. Now I have an application that needs to run on PC ( don'thow me stones ..). So I've done a loader that allows me to load Open Inventor scenes or objects and render under OpenGL. Everything is working fine but not the lighting. If I'm close to the object, color and material are quiet good and if I'm further, the object is "burnt", its color is white overall. So what is good standard lighting model for an OpenGL scene? What is basic material conversion or tricks from Open IV to Open GL ? ================================================================== _/_/ _/ _/_/_/ _/ _/ _/_/_/ _/_/_/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/_/_/ _/_/_/ _/ _/_/_/ _/_/_/ _/ _/ BILLARD Olivier - Ingineer R&D - C&I Software 1 avenue de la mer - 44380 PORNICHET - FRANCE Tel: +33 2 40 11 68 72 Fax: +33 2 40 61 68 14 Email: ceti@worldnet.net URL:http://www.worldnet.net/~ceti ================================================================= \\\|||/// \\ - - // ( @ @ ) +----------------oOOo-(_)-oOOo----------------------+ | " We don't inherit the world from our ancestors, | | it's only a loan from our children ." | | Antoine de Saint Exupery. | +-------------------------Oooo----------------------+ oooO ( ) ( ) ) / \ ( (_/ \_) ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 09:05:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA18264; Fri, 24 Jan 1997 09:04:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA18248; Fri, 24 Jan 1997 09:04:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA15506; Fri, 24 Jan 1997 09:04:43 -0800 Received: from crdems.ge.com (crdems.GE.COM [192.35.44.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA27678 for ; Fri, 24 Jan 1997 09:04:11 -0800 Received: from bart.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA00472; Fri, 24 Jan 97 11:54:23 -0500 Received: from bart by bart.crd.ge.com (SMI-8.6/GE-CRD Standard Sendmail Version S1.5)id JAA06394; Fri, 24 Jan 1997 09:35:53 -0500 Sender: volpe@ash.crd.ge.com Message-Id: <32E8C8C9.1321@ash.crd.ge.com> Date: Fri, 24 Jan 1997 09:35:53 -0500 From: Christopher R Volpe Organization: GE Corporate Research & Development, Schenectady, NY X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: info-performer@sgi.com Subject: viewports? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O inca@public.bta.net.cn wrote: > > Sharon Clay wrote: > >Yes :-( - this bug is fixed in 2.2. > > Thanks for the reply. i'm doing a difficult project that > has 9 non-rectangular viewports with real-time responding. I thought viewports were, by definition, rectangular. Am I missing something? > i know multi-windows is bad thing, but can't avoid it. -- Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr@crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 09:31:09 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA18394; Fri, 24 Jan 1997 09:28:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA18378; Fri, 24 Jan 1997 09:28:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA18434; Fri, 24 Jan 1997 09:28:46 -0800 Received: from sgi600.msd.lmsc.lockheed.com ([129.197.11.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA03496 for ; Fri, 24 Jan 1997 09:28:44 -0800 Received: by sgi600.msd.lmsc.lockheed.com (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id JAA29796; Fri, 24 Jan 1997 09:28:04 -0800 Date: Fri, 24 Jan 1997 09:28:04 -0800 From: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) Message-Id: <199701241728.JAA29796@sgi600.msd.lmsc.lockheed.com> To: info-performer@sgi.com Subject: ONYX2 and graphics performance. Status: O Fellow Performers, We are in the process of upgrading our "old" ONYX RE2 to InfiniteReality graphics. One option is to retrofit the IR graphics subsytem with 2-RM6-64 with R10000's replacing our R4400's, The other, significantly more expensive option is to get a totally new ONYX2 IR system and surplus our "old" ONYX to another project. The question that I have is just how much of a performance increase graphics-wise will the ONYX2 system have over the upgraded ONYX system? Will the lack of ONYX2 XBOW for instance greatly limit my texture loading rates for instance? Just how much does the ONYX2 architecture do for graphics? I would be grateful for any inputs. Thanks, Kenneth N. Sakai Lockheed Martin Missiles & Space Research Specialist/3-D Computer Graphics P.O. Box 3504 Email: sakai@lmsc.lockheed.com Sunnyvale, CA 94088-3504 Phone: (408) 756-0682 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 10:14:26 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA18702; Fri, 24 Jan 1997 10:13:10 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA18686; Fri, 24 Jan 1997 10:13:10 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA23653; Fri, 24 Jan 1997 10:12:59 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA14604 for ; Fri, 24 Jan 1997 10:12:54 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA25895; Fri, 24 Jan 97 12:11:05 -0500 Date: Fri, 24 Jan 97 12:11:05 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701241711.AA25895@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: very bright lights Status: O I said: >> What would happen to a red surface with >> RGB values like (1.0,0.1,0.1) - presuming that the colour calculations >> are done indepenantly in RED, GREEN and BLUE - what would happen? The >> answer is that all three colour components could go over 1.0 and (presumably) >> be clamped to 1.0 for display. This would mean that the predominantly red >> surface would show up as white - but real-world diffuse reflectors don't >> change colours like that. (Don't get confused with specular reflectors - >> which are a different matter). Angus W.S. Henderson replied: > I disagree. As I understand it the original request was for VERY bright lights, > i.e to emulate the effects of overexposure, blinding lights at night etc. > > In these circumstances the original colour of the database is secondary you > just want to burn the light colour onto everything, and as Ken said it's the > textured surfaces that limit the effect. Well, I suppose the effect of extremely bright lights depends on what exactly you are trying to display. If (as simulation usually requires), you are simulating the effect of light from the real world hitting your eyes directly, then the red surface will presumably absorb the same percentages of the red, gren and blue parts of the spectrum when the light is bright as it would when the light is dim. I'm no physicist - but I'd bet that this would be true until the light gets bright enough to vaporize whatever the red surface is. That would suggest that the light reflected from the surface is still in the same 1.0,0.1,0.1 proportions. When this hits the receptors in your eye, you should *presumably* still see the same proportions of red, green and blue - unless your red receptors saturate completely and cease to detect the amount of incoming light correctly. It would have to be an EXTREMELY bright light to do that. Once the light gets that bright, what dominates what you see are some of the effects detailed in James Arvo's excellent paper at SigGraph 95 ("Physically-based Glare Effects for Digital Images") Things would be different if you were trying so simulate photographic media, in that case, the film may well exhibit effects that are different from your eyes. This comes down to simulating what people *expect* an effect to look like (because they see it on TV or whatever) - which is often a different matter from what the effect *really* looks like. > I bet the only answer he gets is "use a multi-pass technique" > > I hate multi pass techniques. I agree. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 10:22:34 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA18754; Fri, 24 Jan 1997 10:21:30 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA18738; Fri, 24 Jan 1997 10:21:30 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA24459; Fri, 24 Jan 1997 10:21:19 -0800 Received: from sgi600.msd.lmsc.lockheed.com ([129.197.11.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16414 for ; Fri, 24 Jan 1997 10:21:17 -0800 Received: by sgi600.msd.lmsc.lockheed.com (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id KAA29979; Fri, 24 Jan 1997 10:20:47 -0800 Date: Fri, 24 Jan 1997 10:20:47 -0800 From: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) Message-Id: <199701241820.KAA29979@sgi600.msd.lmsc.lockheed.com> To: info-performer@sgi.com Subject: pfDirtCheck problems Status: O Fellow Performers, I have been trying to track down a persistant bug problem that is resulting in intermittant "_pfDirtCheck" core problems. I have tried both dmalloc and Purify but have been unsuccessful in tracking down the problem. I was wondering if anyone could tell me just what sort of problem is implied by _pfDirtCheck. Does this always imply corrupted "pfMalloc'ed" memory? What sort of mistakes can lead to these types of problems? (By the way, we are not doing pfDBase things). We are still using Performer 2.0 (rather than Performer 2.01. Were there _pfDirtCheck-type problems with Performer 2.0? Thanks, Kenneth N. Sakai Lockheed Martin Missiles & Space Research Specialist/3-D Computer Graphics P.O. Box 3504 Email: sakai@lmsc.lockheed.com Sunnyvale, CA 94088-3504 Phone: (408) 756-0682 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 11:26:24 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA19069; Fri, 24 Jan 1997 11:24:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA19053; Fri, 24 Jan 1997 11:24:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA00726; Fri, 24 Jan 1997 11:24:44 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA02639 for ; Fri, 24 Jan 1997 11:24:43 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA23384; Fri, 24 Jan 1997 11:24:40 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA08365; Fri, 24 Jan 1997 11:24:35 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701241924.LAA08365@remi.asd.sgi.com> Subject: Re: How to use performer on Window95/NT in IBM PC To: myidisid@interpia.net (Gil-won Park) Date: Fri, 24 Jan 1997 11:24:35 -0800 (PST) Cc: info-performer@sgi.com In-Reply-To: <3.0.1.32.19970124225821.0078c670@interpia.net> from "Gil-won Park" at Jan 24, 97 10:58:22 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 621 Status: O Gil-won Park wrote: > > Greetings, > > I have a account on Indy and I can use performer. but Indy is located > distant from me about 40KM. > > Fortunately, I can use network of T1. So, I use exceed 5.0 & Windows95 > > Pls give me a answer for using IRIX 5.3 remotely in Windows95/NT. > > Thnks for reading. > I don't think exceed is compatible with opengl. It is surely not compatible with IrisGL. Please contact your exceed support for confirmation. _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 11:58:08 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA19255; Fri, 24 Jan 1997 11:56:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA19239; Fri, 24 Jan 1997 11:56:51 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA04084; Fri, 24 Jan 1997 11:56:39 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10690; Fri, 24 Jan 1997 11:56:32 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id TAA05470; Fri, 24 Jan 1997 19:56:12 GMT From: "Angus Dorbie" Message-Id: <9701241956.ZM5468@bitch.reading.sgi.com> Date: Fri, 24 Jan 1997 19:56:12 +0000 In-Reply-To: steve@mred.bgm.link.com (Steve Baker) "Re: very bright lights" (Jan 24, 12:11pm) References: <9701241711.AA25895@mred.bgm.link.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: steve@mred.bgm.link.com (Steve Baker), info-performer@sgi.com Subject: Re: very bright lights Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 24, 12:11pm, Steve Baker wrote: > Subject: Re: very bright lights > > That would suggest that the light reflected from the surface is still in > the same 1.0,0.1,0.1 proportions. When this hits the receptors in your > eye, you should *presumably* still see the same proportions of red, green > and blue - unless your red receptors saturate completely and cease to detect > the amount of incoming light correctly. It would have to be an EXTREMELY > bright light to do that. Once the light gets that bright, what dominates > what you see are some of the effects detailed in James Arvo's excellent paper > at ("Physically-based Glare Effects for Digital Images") > If your'e interested in the perception of brightness & colour in computer graphics you should read the SigGraph 96 paper "A Model of Visual Adaptation for Realistic Image Synthesis" by Ferwerda, Pattanaik, Shirley and Greenberg. It covers colour, spatial and temporal effects. Cheers, Angus. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 12:37:32 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA19523; Fri, 24 Jan 1997 12:32:02 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA19507; Fri, 24 Jan 1997 12:32:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA07066; Fri, 24 Jan 1997 12:31:50 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA17612 for ; Fri, 24 Jan 1997 12:31:42 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Fri, 24 Jan 1997 15:17:53 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Fri, 24 Jan 1997 15:17:52 Eastern Standard Time Message-ID: <32E91E36.280A@ivex3d.com> Date: Fri, 24 Jan 1997 15:40:22 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Makedepend : No locks available !!!! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi : This is more of a compilation problem than a Perf. problem. I am trying to compile sample perf. code (/usr/share/Perfomer... & and also Perfly sample code) on an NFS dir and I keep getting this message FATAL : Makedepend : No locks available .... When I try the same on a local FS, it seems to work fine. Is this an NFS permissions problem ? Thanks Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 13:43:59 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA19792; Fri, 24 Jan 1997 13:42:05 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA19776; Fri, 24 Jan 1997 13:42:04 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA12281; Fri, 24 Jan 1997 13:41:53 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA03717 for ; Fri, 24 Jan 1997 13:41:53 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for <@rock.csd.sgi.com:info-performer@sgi.com> id NAA12276; Fri, 24 Jan 1997 13:41:52 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer@sgi.com id NAA07964; Fri, 24 Jan 1997 13:42:03 -0800 From: "Rob Jenkins" Message-Id: <9701241342.ZM7962@quid.csd.sgi.com> Date: Fri, 24 Jan 1997 13:42:02 -0800 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: re: Makedepend : No locks available !!! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I only did a quick search - the problem may be more complex than this but it's worth checking that the chkconfig flag lockd is 'on' Cheers Rob -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 13:55:12 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA19821; Fri, 24 Jan 1997 13:53:29 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA19805; Fri, 24 Jan 1997 13:53:28 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA13211; Fri, 24 Jan 1997 13:53:17 -0800 Received: from server.rtset.co.il ([194.90.96.254]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA05430 for ; Fri, 24 Jan 1997 13:51:51 -0800 Received: from dialup.netvision.net.il (ts013p10.pop9a.netvision.net.il [194.90.11.246]) by server.rtset.co.il (8.6.12/8.6.9) with SMTP id XAA05210; Thu, 25 Jan 1996 23:43:34 +0200 Message-ID: <32EA0089.7752@rtset.co.il> Date: Sat, 25 Jan 1997 04:46:01 -0800 From: Ran Yakir Reply-To: rany@rtset.co.il Organization: RT-SET X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: ceti CC: info-performer@sgi.com Subject: Re: more openGL than perf References: <199701241658.RAA05306@centaure.worldnet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O ceti wrote: > > Hello, > > this far from performer and closer to OpenGL, but I've noticed that > here there are several OpenGL kings !!! > > Well, > Here's my problem. > I used to work under Performer with objects and scenes > described with Inventor format. Now I have an application > that needs to run on PC ( don'thow me stones ..). > So I've done a loader that allows me to load Open Inventor scenes or objects > and render under OpenGL. > > Everything is working fine but not the lighting. > > If I'm close to the object, color and material > are quiet good and if I'm further, the object is > "burnt", its color is white overall. > > So what is good standard lighting model for an OpenGL scene? > What is basic material conversion or tricks from Open IV to Open GL ? 1. There may be bugs in the PC implementation of OpenGL, that cause this behaviour - or - 2. You might be running into a lighting condition in which the specular reflection, which depends also on viewer position causes the object to be very bright - or - 3. You may have very thick white fog that makes the object white as you get further. Whiy don't you try disabling fog (glDisable (GL_FOG) ), and turning off speculat lighting with glLightfv. Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | 28 Ben Gurion St. / )_ (_(_) ) \/ (_(_/<_(_)( | Hod Hasharon 54200 _/ | Israel -------------------------------------+-------------------------------- At Home : | At Work : | RT-SET Voice : +972-9-989974 | Voice : +972-9-552236 Fax : +972-9-422149 | Fax : +972-9-552239 E-mail : rany@netvision.net.il | E-mail : rany@rtset.co.il ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 13:57:50 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA19848; Fri, 24 Jan 1997 13:56:48 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA19832; Fri, 24 Jan 1997 13:56:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA13442; Fri, 24 Jan 1997 13:56:36 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA06493 for ; Fri, 24 Jan 1997 13:56:30 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Fri, 24 Jan 1997 16:42:55 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Fri, 24 Jan 1997 16:42:54 Eastern Standard Time Message-ID: <32E93225.3188@ivex3d.com> Date: Fri, 24 Jan 1997 17:05:25 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com Subject: pfuTraverser() printing pfLPointState info !!! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi : I am using pfuTraverser() utility to print the nodeInfo into a file. I am able to print the node info of all pfGeodes / pfGeoSet. The callback "cbPrintNodeInfo" in .../libpfutil/trav.c prints this info. But when I added this simple piece of code if(node == pfGetLPStateClassType()) { print("\n LPState found \n"); ...... } and recompiled the lib and tried on database with lightpoints only, this is never set to true to print the message. But the *.flt loader (15.3b7) prints the summary and counts the LPStates. Do I need to add any tokens to trav.c to recognize this ClassType ? Thanks Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 14:53:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA20460; Fri, 24 Jan 1997 14:52:06 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA20444; Fri, 24 Jan 1997 14:52:05 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA19081; Fri, 24 Jan 1997 14:51:55 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA19019 for ; Fri, 24 Jan 1997 14:51:52 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Fri, 24 Jan 1997 17:31:15 Eastern Standard Time Received: by gateway.ivex3d.com from gateway (192.168.1.17::mail daemon; unverified,SLMAIL95 V2.2); Fri, 24 Jan 1997 17:31:14 Eastern Standard Time Received: by gateway with Microsoft Mail id <01BC0A1E.0AA16FE0@gateway>; Fri, 24 Jan 1997 17:43:00 -0500 Message-ID: <01BC0A1E.0AA16FE0@gateway> From: "Hudson Holmes" To: "'Gil-won Park'" , "'info-performer'" Subject: RE: How to use performer on Window95/NT in IBM PC Date: Fri, 24 Jan 1997 17:42:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: O Hello, I have used Exceed 5 to remotely login with IRIX 6.2. It requires Windows NT and a add-on product to Exceed 5 called Exceed 3D for Windows NT V5.1 and will only run on NT. It supports some OpenGL but there are some calls which are not supported. I was able to use software manager and other IRIX graphics utilities. It worked with the Lynx panel from Vega but failed when I ran a Vega app that I had written. If you have Exceed 5 already the Exceed 3D was not very expensive so maybe it's worth a try for you. Good Luck, Hudson Holmes, Software Engineering Manager IVEX Inc. 4355 International Blvd. Norcross, GA 30093 voice 770-564-1148 fax 770-381-0622 holmes@ivex3d.com ---------- From: Gil-won Park Sent: Friday, January 24, 1997 8:58 AM To: info-performer@sgi.com Subject: How to use performer on Window95/NT in IBM PC Greetings, I have a account on Indy and I can use performer. but Indy is located distant from me about 40KM. Fortunately, I can use network of T1. So, I use exceed 5.0 & Windows95 Pls give me a answer for using IRIX 5.3 remotely in Windows95/NT. Thnks for reading. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 14:51:44 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA20441; Fri, 24 Jan 1997 14:49:34 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA20425; Fri, 24 Jan 1997 14:49:33 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA18825; Fri, 24 Jan 1997 14:49:21 -0800 Received: from mailhost.multigen.com (mailhost.multigen.com [204.119.69.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA18013 for ; Fri, 24 Jan 1997 14:49:15 -0800 Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [204.119.70.10]) by mailhost.multigen.com (8.6.11/8.6.12) with ESMTP id OAA14571 for ; Fri, 24 Jan 1997 14:54:33 -0800 Received: from vaisyas.engr.multigen.com (vaisyas.engr.multigen.com [204.119.70.76]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id WAA28201 for ; Fri, 24 Jan 1997 22:45:44 GMT Received: (from marcus@localhost) by vaisyas.engr.multigen.com (950413.SGI.8.6.12/8.6.12) id OAA23086 for info-performer@sgi.com; Fri, 24 Jan 1997 14:53:21 -0800 From: "Marcus Barnes" Message-Id: <9701241453.ZM23085@vaisyas.engr.multigen.com> Date: Fri, 24 Jan 1997 14:53:21 -0800 In-Reply-To: "Rambabu" "pfuTraverser() printing pfLPointState info !!!" (Jan 24, 5:05pm) References: <32E93225.3188@ivex3d.com> Organization: MultiGen Inc. X-Phones: 1-408-556-2654 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Re: pfuTraverser() printing pfLPointState info !!! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 24, 5:05pm, Rambabu wrote: > Subject: pfuTraverser() printing pfLPointState info !!! > Hi : > > I am using pfuTraverser() utility to print the nodeInfo into a file. > I am able to print the node info of all pfGeodes / pfGeoSet. [munch] > Do I need to add any tokens to trav.c to recognize this ClassType ? pfLPointState is an attribute of a pfGeoState which is an attribute of a pfGeoSet. You need to modify your traversal to perform this extended lookup. Regards. -- + Marcus Barnes, Technical Staff mailto:marcus@multigen.com + + Multigen Inc. http://www.multigen.com + + 550 S. Winchester Blvd. phoneto:1-408-556-2654 + + Suite 500 San Jose CA 95128 faxto:1-408-261-4102 + ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 14:59:26 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA20526; Fri, 24 Jan 1997 14:58:12 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA20510; Fri, 24 Jan 1997 14:58:11 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA19524; Fri, 24 Jan 1997 14:58:00 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20510 for ; Fri, 24 Jan 1997 14:58:00 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id OAA10820; Fri, 24 Jan 1997 14:57:55 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id OAA09389; Fri, 24 Jan 1997 14:57:53 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701242257.OAA09389@remi.asd.sgi.com> Subject: Re: pfuTraverser() printing pfLPointState info !!! To: ram@ivex3d.com (Rambabu) Date: Fri, 24 Jan 1997 14:57:53 -0800 (PST) Cc: info-performer@sgi.com In-Reply-To: <32E93225.3188@ivex3d.com> from "Rambabu" at Jan 24, 97 05:05:25 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 916 Status: O Rambabu wrote: > > Hi : > > I am using pfuTraverser() utility to print the nodeInfo into a file. > I am able to print the node info of all pfGeodes / pfGeoSet. The > callback "cbPrintNodeInfo" in .../libpfutil/trav.c prints > this info. But when I added this simple piece of code > > if(node == pfGetLPStateClassType()) > { > print("\n LPState found \n"); > ...... > } > and recompiled the lib and tried on database with lightpoints only, > this is never set to true to print the message. But the *.flt loader > (15.3b7) prints the summary and counts the LPStates. > Do I need to add any tokens to trav.c to recognize this ClassType ? The pfLPointState node is not directly attached to the database. It is attached to a pfGeoState. _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 16:50:35 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id QAA01105; Fri, 24 Jan 1997 16:48:48 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA01089; Fri, 24 Jan 1997 16:48:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id QAA28571; Fri, 24 Jan 1997 16:48:36 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA12415 for ; Fri, 24 Jan 1997 16:48:35 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id QAA17480; Fri, 24 Jan 1997 16:31:00 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id QAA09654; Fri, 24 Jan 1997 16:30:59 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701250030.QAA09654@remi.asd.sgi.com> Subject: Re: ONYX2 and graphics performance. To: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) Date: Fri, 24 Jan 1997 16:30:59 -0800 (PST) Cc: info-performer@sgi.com In-Reply-To: <199701241728.JAA29796@sgi600.msd.lmsc.lockheed.com> from "Ken Sakai" at Jan 24, 97 09:28:04 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1376 Status: O Ken Sakai wrote: > > > Fellow Performers, > > We are in the process of upgrading our "old" ONYX RE2 to InfiniteReality > graphics. One option is to retrofit the IR graphics subsytem with 2-RM6-64 > with R10000's replacing our R4400's, The other, significantly more > expensive option is to get a totally new ONYX2 IR system and surplus our > "old" ONYX to another project. The question that I have is just how much > of a performance increase graphics-wise will the ONYX2 system have over the > upgraded ONYX system? Will the lack of ONYX2 XBOW for instance greatly > limit my texture loading rates for instance? Just how much does the ONYX2 > architecture do for graphics? I would be grateful for any inputs. > Onyx2 will provide you 2x the speed for downloading textures and display lists to the gfx. ClipMapping for example works a lot better on Onyx2. Independantly, some applicaton have a 10% increase of Pixel Fill. Evrything else is the almost the same for graphic, but dont forget that the bandwith between Cpu and Main memory is greatly improved on Onyx2, so that may help also for the other part of your applications. Also, I thought that Onyx2 IR was less expensibe that Onyx IR ? _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 24 22:18:20 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id WAA02533; Fri, 24 Jan 1997 22:16:49 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id WAA02517; Fri, 24 Jan 1997 22:16:48 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id WAA10737; Fri, 24 Jan 1997 22:16:37 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA26774 for ; Fri, 24 Jan 1997 22:16:36 -0800 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id WAA28948; Fri, 24 Jan 1997 22:16:31 -0800 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA24998; Fri, 24 Jan 1997 22:16:29 -0800 From: "Javier Castellar" Message-Id: <9701242216.ZM24996@sixty.asd.sgi.com> Date: Fri, 24 Jan 1997 22:16:28 -0800 In-Reply-To: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) "ONYX2 and graphics performance." (Jan 24, 9:28am) References: <199701241728.JAA29796@sgi600.msd.lmsc.lockheed.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai), info-performer@sgi.com Subject: Re: ONYX2 and graphics performance. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, Speaking in general terms, all the imediate mode performance has been greatly increased due the new bandwidth host - Gfx, although the internal graphics pipeline architecture/speeds is nearly identical. If your application was host limited (bandwidth in/out the pipe), CPU limited (processing of the delivery for OpenGL calls) or if you performed large pixel transfers (glDrawPixels/glReadPixels) - texture paging then Onyx2 IR should boost your application. I don't know which numbers we have been published but I have seen over 337 MB/s (glDrawPixels) on Onyx2 IR for 1kx1k about four weeks ago. I think that this is also the number for texture paging. On Onyx (1) it was 180MB/s, now it is over 300MB/s, in fact I think that the latest number is probably 340 MB/s. Off course if your texture transfers were very small (set up limited) then you might not see so huge numbers. Also on the CPU side, I have seen very impressive improvements, since very few applications fit on any secundary CPU cache (now 4MB); therefore the new amazing bandwidth in/out main memory (independent of the number of CPUs !!!!) helps a lot. Regarding hardware display list mode, you will see the same performance that before if you where using the display list memory cache in IR. (!!!). Regards. -Javier On Jan 24, 9:28am, Ken Sakai wrote: > Subject: ONYX2 and graphics performance. > > Fellow Performers, > > We are in the process of upgrading our "old" ONYX RE2 to InfiniteReality > graphics. One option is to retrofit the IR graphics subsytem with 2-RM6-64 > with R10000's replacing our R4400's, The other, significantly more > expensive option is to get a totally new ONYX2 IR system and surplus our > "old" ONYX to another project. The question that I have is just how much > of a performance increase graphics-wise will the ONYX2 system have over the > upgraded ONYX system? Will the lack of ONYX2 XBOW for instance greatly > limit my texture loading rates for instance? Just how much does the ONYX2 > architecture do for graphics? I would be grateful for any inputs. > > Thanks, > > Kenneth N. Sakai Lockheed Martin Missiles & Space > Research Specialist/3-D Computer Graphics P.O. Box 3504 > Email: sakai@lmsc.lockheed.com Sunnyvale, CA 94088-3504 > Phone: (408) 756-0682 > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Ken Sakai -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: 415-933-1589 / 2108 (lab) * * Core Design - Applied Engineering * Fax: 415-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetent" Hardin Seldon ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 25 13:43:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA03714; Sat, 25 Jan 1997 13:33:33 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA03698; Sat, 25 Jan 1997 13:33:32 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA02544; Sat, 25 Jan 1997 13:33:21 -0800 Received: from sd.cts.com (sd.cts.com [192.188.72.28]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA27963 for ; Sat, 25 Jan 1997 13:33:20 -0800 Received: by sd.cts.com (Smail3.1.29.1 #5) id m0voFio-0000FdC; Sat, 25 Jan 97 13:33 PST Date: Sat, 25 Jan 1997 13:33:10 -0800 (PST) From: Gerard Tyra - SA Technology To: Steve Baker cc: info-performer@sgi.com Subject: Re: very bright lights In-Reply-To: <9701241307.AA23813@mred.bgm.link.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Fri, 24 Jan 1997, Steve Baker wrote: > > Gerard Tyra - SA Technology said: > > > You have hit a problem that I have seen in everything from flight > > simulators to animation systems, ie. lights/color values are clamped to 1.0. > > > > So here is my open wish list: > > > > 1) Allow values greater than 1.0 to be input and used in the > > computation. After all, even a dark grey surface will look white if you > > pump enough light into it. > > Woaaa - be very careful what you wish for. Suppose they did compute > things the way you suggest. What would happen to a red surface with > RGB values like (1.0,0.1,0.1) - presuming that the colour calculations > are done indepenantly in RED, GREEN and BLUE - what would happen? The > answer is that all three colour components could go over 1.0 and (presumably) > be clamped to 1.0 for display. This would mean that the predominantly red > surface would show up as white - but real-world diffuse reflectors don't > change colours like that. (Don't get confused with specular reflectors - > which are a different matter). > Here I beg to differ. Once the staurates, color starts to drop out of the equation. And if the light only has a red component, you would still get a red object, as long as the object has any red in its surface color. > > 2) Give me 10/12 bit DACs on the IR. Then I can render a moon lit night > > scene with values below 128 (or 0.5) but still "spike" the display with > > values over 3000 for light sources. > > Building DAC's with high precision *and* high speed is a non-trivial problem. True, but the same could be said of the DACs we are using right now. I am currently aware of two commercial sources for such DACs. The business issue for SGI is if enough people are willing to pay more to get the extra dynamic range. I also know a lot of people in the pre-press business who would love to have the better gamma correction of 12 bit color. Gerry ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Sat Jan 25 23:15:54 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id XAA04535; Sat, 25 Jan 1997 23:09:37 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id XAA04519; Sat, 25 Jan 1997 23:09:37 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA16067; Sat, 25 Jan 1997 23:09:22 -0800 Received: from rivafw.rivatech.com (rivatech.com [206.26.248.129]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA28341; Sat, 25 Jan 1997 23:09:12 -0800 Received: by rivafw.rivatech.com (940816.SGI.8.6.9/940406.SGI) id BAA15919; Sun, 26 Jan 1997 01:07:13 -0600 Received: from linus.rivatech.com(192.168.1.3) by rivafw.rivatech.com via smap (V1.3) id smaa15911; Sun Jan 26 01:07:03 1997 Received: from franklin.rivatech.com (franklin.rivatech.com [192.168.1.226]) by linus.rivatech.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id VAA14277; Sat, 25 Jan 1997 21:18:26 -0600 Message-ID: <32EACD55.BA@rivatech.com> Date: Sat, 25 Jan 1997 21:19:49 -0600 From: "G.W. Estep II" Organization: RIVA Technologies, Inc. X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: Rémi Arnaud CC: Gil-won Park , info-performer@sgi.com Subject: Re: How to use performer on Window95/NT in IBM PC References: <199701241924.LAA08365@remi.asd.sgi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Status: O Gil-won, I have an eval copy of Exceed 5 (Version 5.1.3) that does OpenGL. It also runs the OpenInventor viewer, ivview. There are also some examples programs that run local under Exceed that you might be interested in. However, I have not been successful at getting even the simplest Performer apps to run due to non-support of the GLX widget for some reason. I get messages that report bad opcodes related to GLX and X_GLXQueryVersion and the program dies. Hope this helps, G.W. Rémi Arnaud wrote: > > Gil-won Park wrote: > > > > Greetings, > > > > I have a account on Indy and I can use performer. but Indy is located > > distant from me about 40KM. > > > > Fortunately, I can use network of T1. So, I use exceed 5.0 & Windows95 > > > > Pls give me a answer for using IRIX 5.3 remotely in Windows95/NT. > > > > Thnks for reading. > > > > I don't think exceed is compatible with opengl. It is surely not compatible > with IrisGL. Please contact your exceed support for confirmation. > > _ / _ _ > |_) _ ._ _ o /\ |_)|\ | /\ | || \ > | \(/_| | || /--\| \| \|/--\|_||_/ > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 05:26:14 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA06455; Mon, 27 Jan 1997 05:24:59 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA06439; Mon, 27 Jan 1997 05:24:58 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA29354; Mon, 27 Jan 1997 05:24:47 -0800 Received: from ns1.sara.nl (ns1.sara.nl [192.16.188.198]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA16537 for ; Mon, 27 Jan 1997 05:24:37 -0800 Received: from isis.sp.sara.nl (isis-s114.sp.sara.nl [145.100.13.46]) by ns1.sara.nl (8.8.3/8.7.1) with ESMTP id OAA13421; Mon, 27 Jan 1997 14:26:45 +0100 (MET) Received: from isis-s115 by isis.sp.sara.nl (8.8.3/4.04) id NAA58662; Mon, 27 Jan 1997 13:23:38 GMT Sender: wilfred@sara.nl Message-ID: <32ECAC5A.167E@sara.nl> Date: Mon, 27 Jan 1997 14:23:38 +0100 From: Wilfred Janssen Organization: SARA X-Mailer: Mozilla 3.01Gold (X11; I; AIX 1) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Stereo version of perfly Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O In order to demonstrate the power of our new Onyx2 RealityMonster (4 iR-pipes !) we need a good demo. I know that there's a stereo-version of the perfly demo named sfly, I've seen it be mentioned here on this list a few times. Does someone know where I can find this program. Many thanks, Wilfred Janssen -- =================================================================== | Wilfred Janssen SARA | | P.O. Box 94613 | | Consultant Scientific Computing 1090 GP Amsterdam | | Academic Computing Services Amsterdam The Netherlands | | | | Phone: 020-592 3000 e-mail: wilfred@sara.nl | =================================================================== ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 06:24:58 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA06599; Mon, 27 Jan 1997 06:23:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA06583; Mon, 27 Jan 1997 06:23:46 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA01772; Mon, 27 Jan 1997 06:23:34 -0800 Received: from puth.demeern.sgi.com ([144.253.208.50]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA25284 for ; Mon, 27 Jan 1997 06:23:32 -0800 Received: by puth.demeern.sgi.com (950413.SGI.8.6.12/940406.SGI) id PAA01152; Mon, 27 Jan 1997 15:23:03 +0100 Date: Mon, 27 Jan 1997 15:23:03 +0100 From: dick@demeern.sgi.com (Dick Rous) Message-Id: <9701271523.ZM1150@puth.demeern.sgi.com> In-Reply-To: Wilfred Janssen "Stereo version of perfly" (Jan 27, 2:23pm) References: <32ECAC5A.167E@sara.nl> X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Wilfred Janssen , info-performer@sgi.com Subject: Re: Stereo version of perfly Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Wilfred, There is a tar-archive of sfly at sgigate.sgi.com/pub/Performer/src/pf1.2/sfly.tar.Z However, this is a Performer1.2 program, so you have to convert it to 2.1 and OpenGL in order to be useful for your InfiniteReality system. Anybody aware of an OpenGL 2.x version? Regards, -- ------------------------------------------------------------ Dick Rous email....: dick@demeern.sgi.com Systems Engineer voicemail: 5-8160 Graphics Technology phone....: (31) 30-6696868 Silicon Graphics BV phone....: (31) 30-6696777 Veldzigt 2 fax......: (31) 30-6696799 3454 PW De Meern The Netherlands ------------------------------------------------------------ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 07:41:38 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA06777; Mon, 27 Jan 1997 07:40:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA06761; Mon, 27 Jan 1997 07:40:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA05638; Mon, 27 Jan 1997 07:40:14 -0800 Received: from huey.ntsc.navy.mil (huey.ntsc.navy.mil [192.44.253.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id HAA08962 for ; Mon, 27 Jan 1997 07:40:12 -0800 From: WILLIAM_MARINELLI@ntsc.navy.mil Received: from CCMAIL.NTSC.NAVY.MIL ([192.44.253.30]) by huey.ntsc.navy.mil (4.1/SMI-4.1) id AA06072; Mon, 27 Jan 97 10:38:54 EST Received: from ccMail by CCMAIL.NTSC.NAVY.MIL (SMTPLINK V2.11) id AA854390415; Mon, 27 Jan 97 10:35:27 EST Date: Mon, 27 Jan 97 10:35:27 EST Message-Id: <9700278543.AA854390415@CCMAIL.NTSC.NAVY.MIL> To: info-performer@sgi.com Subject: Performer/OpenGL Status: O "Performer is layered over OpenGL" Is that a generalization or is it an absolute. I recall hearing way back that while Performer was laid on top of Iris GL, it could access some graphics hardware that GL could not. Don't recall the context. Just curious. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 09:08:03 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA07023; Mon, 27 Jan 1997 09:06:42 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA07007; Mon, 27 Jan 1997 09:06:41 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA12317; Mon, 27 Jan 1997 09:06:30 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29055 for ; Mon, 27 Jan 1997 09:06:26 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Mon, 27 Jan 1997 11:52:39 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Mon, 27 Jan 1997 11:52:38 Eastern Standard Time Message-ID: <32ECE2BC.71EE@ivex3d.com> Date: Mon, 27 Jan 1997 12:15:40 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com Subject: pfChannels under MCO ?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi : I lost the figure on pfChannels supported by pfPipe(). The Pguide, most of the time says a "multiple number of channels", but under the MCO, it supports upto 6-channels. So, is MCO a default option with Onyx iR/Onyx2 ? What is actual figure on the number of channels with/without MCO on an iR ? Also, what is cost stretching upto the maximum number of channels (whatever that number is) in terms of resolution/throughput ? Just getting our figures right for a technical writeup ? Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 09:31:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA07185; Mon, 27 Jan 1997 09:30:25 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA07169; Mon, 27 Jan 1997 09:30:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA14860; Mon, 27 Jan 1997 09:30:14 -0800 Received: from centaure.worldnet.net (centaure.worldnet.net [194.2.128.249]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA05125 for ; Mon, 27 Jan 1997 09:29:36 -0800 Received: from nantes0-016.sct.fr (nantes0-016.sct.fr [194.206.158.16]) by centaure.worldnet.net (8.6.12/8.6.12) with SMTP id SAA04384 for ; Mon, 27 Jan 1997 18:29:31 +0100 Message-Id: <199701271729.SAA04384@centaure.worldnet.net> X-Sender: ceti@worldnet.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Jan 1997 18:30:09 +0000 To: info-performer@sgi.com From: ceti@worldnet.net (ceti) Subject: thank you all for OpenGL trick ! Status: O First, I'd like to thank you for the answers I got on my OpenGL problem and particulary - Ran Yakir - Dirk reiners - Steve Baker Second, I make a small sumary of answers : There may be bugs in the PC implementation of OpenGL -> Sorry, but not because my own indy behaves the same way. You might be running into a lighting condition in which the specular reflection causes the object to be very bright -> That was my only track of solutions but I had already tried a lot of combinations but with no solution. You may have very thick white fog that makes the object white as you get further -> Surprised because it was just set by default but I've tried a glDisable (GL_FOG) to be sure. Finally, Did you glEnable(GL_NORMALIZE)? -> Woaaaaw! it's working !!!! Well done !! ================================================================== _/_/ _/ _/_/_/ _/ _/ _/_/_/ _/_/_/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/_/_/ _/_/_/ _/ _/_/_/ _/_/_/ _/ _/ BILLARD Olivier - Ingineer R&D - C&I Software 1 avenue de la mer - 44380 PORNICHET - FRANCE Tel: +33 2 40 11 68 72 Fax: +33 2 40 61 68 14 Email: ceti@worldnet.net URL:http://www.worldnet.net/~ceti ================================================================= \\\|||/// \\ - - // ( @ @ ) +----------------oOOo-(_)-oOOo----------------------+ | " We don't inherit the world from our ancestors, | | it's only a loan from our children ." | | Antoine de Saint Exupery. | +-------------------------Oooo----------------------+ oooO ( ) ( ) ) / \ ( (_/ \_) ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 10:32:34 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA07548; Mon, 27 Jan 1997 10:30:04 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA07532; Mon, 27 Jan 1997 10:30:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA21070; Mon, 27 Jan 1997 10:29:52 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA21036 for ; Mon, 27 Jan 1997 10:29:51 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA13039; Mon, 27 Jan 1997 10:29:50 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA14107; Mon, 27 Jan 1997 10:29:45 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701271829.KAA14107@remi.asd.sgi.com> Subject: Re: pfChannels under MCO ?? To: ram@ivex3d.com (Rambabu) Date: Mon, 27 Jan 1997 10:29:45 -0800 (PST) Cc: info-performer@sgi.com In-Reply-To: <32ECE2BC.71EE@ivex3d.com> from "Rambabu" at Jan 27, 97 12:15:40 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1080 Status: O Rambabu wrote: > > Hi : > > I lost the figure on pfChannels supported by pfPipe(). The Pguide, > most of the time says a "multiple number of channels", but under the > MCO, it supports upto 6-channels. So, is MCO a default option > with Onyx iR/Onyx2 ? What is actual figure on the number of channels > with/without MCO on an iR ? There are to videos as a standard on iR, and 8 as an option. > > Also, what is cost stretching upto the maximum number of channels > (whatever that number is) in terms of resolution/throughput ? The maximum bandwith is 300 MHz , shared by the 8 videos. The fill given by the number of RM on the pipe is shared between all the channels on that pipe. A minimum of memory is needed to have antialiasing with more than 1 video. therefore there is a minimum of # of RMs. use ircombine with a simulated target hardware to check if you are OK for the configuration you want. _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 10:37:22 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA07579; Mon, 27 Jan 1997 10:35:27 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA07563; Mon, 27 Jan 1997 10:35:26 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA21581; Mon, 27 Jan 1997 10:35:15 -0800 Received: from gatekeeper.rayva.org (gatekeeper.rayva.org [204.254.244.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22264 for ; Mon, 27 Jan 1997 10:33:55 -0800 Received: (from mail@localhost) by gatekeeper.rayva.org (8.6.12/8.6.12) id NAA21242 for ; Mon, 27 Jan 1997 13:38:36 -0500 Received: from jpsds14e(192.168.5.103) by gatekeeper via smap (V1.3) id sma021238; Mon Jan 27 13:38:12 1997 Received: from tdecarlo (ppp225 [192.168.5.225]) by jpsds14e.rayva.org (8.6.12/8.6.12) with ESMTP id NAA04630 for ; Mon, 27 Jan 1997 13:27:42 -0500 Message-ID: <32ECF44A.727D@rayva.org> Date: Mon, 27 Jan 1997 13:30:34 -0500 From: Thom DeCarlo Reply-To: tdecarlo@rayva.org Organization: TASC, Inc. X-Sender: Thom DeCarlo X-Mailer: Mozilla 4.0b1 (Win95; I) MIME-Version: 1.0 To: info-performer Subject: Looking for MultiGen's Performer Loader. X-Priority: Normal Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Status: O Hi, I've been trying for the better part of a week to download the latest version of MultiGen's Performer loader from their ftp site. I don't understand why, but after about the first minute the download stops and after around 10-30 minutes the connection closes itself. Are there any other places that I can find their loader files? (that is, Performer_Loader_202.tar.Z) TIA, Thom -- ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ Thom DeCarlo * Off-site contact info TASC * JPSD/IEC, US Army TEC 12100 Sunset Hills Rd. * 7701 Telegraph Rd., Bldg 2592 Reston, VA 22090 * Alexandria, VA 22315 phone: 703/834-5000 * phone: 703/428-7034 fax: 703/318-7900 * fax: 703/428-7054 mailto:trdecarlo@tasc.com * mailto:tdecarlo@rayva.org ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ There was a time when religion ruled the world. It is known as the Dark Ages. -Ruth Hurmence Green "The Born-again Skeptic's Guide to the Bible" ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 11:04:52 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA07817; Mon, 27 Jan 1997 11:03:09 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA07801; Mon, 27 Jan 1997 11:03:08 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA24573; Mon, 27 Jan 1997 11:02:57 -0800 Received: from amelnx.advmar.com (amelnx.advmar.com [152.136.205.23]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA00290 for ; Mon, 27 Jan 1997 11:02:49 -0800 From: Hill_Brian@amelnx.advmar.com Received: from cc:Mail by amelnx.advmar.com id AA854229864; Mon, 27 Jan 97 13:55:55 EST Date: Mon, 27 Jan 97 13:55:55 EST Encoding: 62 Text Message-Id: <9700258542.AA854229864@amelnx.advmar.com> To: info-performer@sgi.com Subject: Re: pfChannels under MCO ?? Status: O Ram, MCO doesn't apply to IR it applies to RE/RE2. The IR comes with 2 channels and can be upgraded to 8 channels per pipe. The base 2 channel product is call a DG4-2 Two Channel Display and the upgrade product is a DG4-8 Eight Channel Display. Resolution/throughput is limited by two components: 1) Number of RMs per pipe for pixel processing and frame buffer memory 200 Mpixels/sec/RM 80 Mbytes/RM framebuffer memory Max resolution will be related to number of channels and the frame buffer configuration (resolution, pixel depth (color res, Z, stencil, accum, dbl buff, subsamples)). 2) Framebuffer to display generator bandwidth (210-290 Mpixels/sec) I think these are ONYX IR and I don't know about ONYX2. The IR provides a huge range of flexibility in configuring your channels and displays. I would recommend you contact your sales rep and get the product info on how to configure a system based on guestimates of an applications requirements. It will really help your write up if you have a basic understanding of what the system is capable of. Brian Hill hill_brian@advmar.com ______________________________ Reply Separator _________________________________ Subject: pfChannels under MCO ?? Author: "Rambabu" at Internet Date: 1/26/97 12:12 PM Hi : I lost the figure on pfChannels supported by pfPipe(). The Pguide, most of the time says a "multiple number of channels", but under the MCO, it supports upto 6-channels. So, is MCO a default option with Onyx iR/Onyx2 ? What is actual figure on the number of channels with/without MCO on an iR ? Also, what is cost stretching upto the maximum number of channels (whatever that number is) in terms of resolution/throughput ? Just getting our figures right for a technical writeup ? Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 11:13:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA07892; Mon, 27 Jan 1997 11:11:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA07876; Mon, 27 Jan 1997 11:11:58 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA25455; Mon, 27 Jan 1997 11:11:46 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA02788 for ; Mon, 27 Jan 1997 11:11:46 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA17358; Mon, 27 Jan 1997 11:11:44 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA14312; Mon, 27 Jan 1997 11:11:43 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701271911.LAA14312@remi.asd.sgi.com> Subject: Re: Performer/OpenGL To: WILLIAM_MARINELLI@ntsc.navy.mil Date: Mon, 27 Jan 1997 11:11:43 -0800 (PST) Cc: info-performer@sgi.com In-Reply-To: <9700278543.AA854390415@CCMAIL.NTSC.NAVY.MIL> from "WILLIAM_MARINELLI@ntsc.navy.mil" at Jan 27, 97 10:35:27 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1002 Status: O WILLIAM_MARINELLI@ntsc.navy.mil wrote: > > "Performer is layered over OpenGL" > > Is that a generalization or is it an absolute. I recall hearing way > back that while Performer was laid on top of Iris GL, it could access > some graphics hardware that GL could not. Don't recall the context. > Performer is 100% layered over OpenGL, there are no back doors of any kind. Performer uses SGI OpenGL extensions and GLX functions that are all available. Performer is still compatible with IrisGL (mainly for RE2), but there will be no new fonctionality for IrisGL. There are no more IrisGL based hardware available from SGI. All IrisGL implementation are now through the IGLOO library, that is not very usefull for Performer applications as IGLOO is a layer on top of OpenGL. Best regards _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 12:00:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA08188; Mon, 27 Jan 1997 11:59:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA08172; Mon, 27 Jan 1997 11:59:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA00430; Mon, 27 Jan 1997 11:59:14 -0800 Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA15099 for ; Mon, 27 Jan 1997 11:59:11 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-5.mail.demon.net id aa516760; 27 Jan 97 17:39 GMT From: Mark Baranowski To: info-performer@sgi.com Subject: Re: pfChannels under MCO ?? Date: Mon, 27 Jan 1997 17:39:57 GMT Organization: Pera Message-ID: <32ece70a.32765759@post.demon.co.uk> References: <32ECE2BC.71EE@ivex3d.com> In-Reply-To: <32ECE2BC.71EE@ivex3d.com> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O On Mon, 27 Jan 1997 12:15:40 -0500, you wrote: >Hi :=20 > >I lost the figure on pfChannels supported by pfPipe(). The Pguide, >most of the time says a "multiple number of channels", but under the=20 >MCO, it supports upto 6-channels. So, is MCO a default option >with Onyx iR/Onyx2 ? What is actual figure on the number of channels >with/without MCO on an iR ? The basic iR configuration supports 2 channels, with an option (called DG8 I think) to provide 8 output channels. --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leicestershire. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 14:35:44 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA08984; Mon, 27 Jan 1997 14:33:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA08968; Mon, 27 Jan 1997 14:33:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA15592; Mon, 27 Jan 1997 14:33:13 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA21871 for ; Mon, 27 Jan 1997 14:33:06 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Mon, 27 Jan 1997 17:19:25 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Mon, 27 Jan 1997 17:19:25 Eastern Standard Time Message-ID: <32ED2F54.7356@ivex3d.com> Date: Mon, 27 Jan 1997 17:42:28 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Pixel Size of pfLPointState() !! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi : Has anybody tried changing the pixel_size() of pfLPointState on the fly ? I want to map this variations to some keyboard input ? for that mater any such attribute of the pfLPointState(). Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 15:17:26 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA09397; Mon, 27 Jan 1997 15:15:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA09381; Mon, 27 Jan 1997 15:15:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA20077; Mon, 27 Jan 1997 15:15:23 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA02099 for ; Mon, 27 Jan 1997 15:15:22 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id PAA06307; Mon, 27 Jan 1997 15:15:17 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id PAA17371; Mon, 27 Jan 1997 15:15:15 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701272315.PAA17371@remi.asd.sgi.com> Subject: Re: Pixel Size of pfLPointState() !! To: ram@ivex3d.com (Rambabu) Date: Mon, 27 Jan 1997 15:15:15 -0800 (PST) Cc: info-performer@sgi.com In-Reply-To: <32ED2F54.7356@ivex3d.com> from "Rambabu" at Jan 27, 97 05:42:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 799 Status: O Rambabu wrote: > > Hi : > > Has anybody tried changing the pixel_size() of pfLPointState on the fly > ? I want to map this variations to some keyboard input ? for that mater > any such attribute of the pfLPointState(). The size of the point is in the geoset get->setPntSize or pfGSetPntSize. this value is NOT used if the PFLPS_SIZE_MODE is enabled in the LPState in that case the value used is PFLPS_SIZE_ACTUAL, wich is not the value in screen space, but the size in world space. The resulting value (projection of the actual size) is clipped by PFLPS_SIZE_MIN_PIXEL and PFLPS_SIZE_MAX_PIXEL in screnn space. Best Regard _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Mon Jan 27 16:14:42 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id QAA10027; Mon, 27 Jan 1997 16:13:04 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA10011; Mon, 27 Jan 1997 16:13:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id QAA25299; Mon, 27 Jan 1997 16:12:52 -0800 Received: from silver.anu.edu.au (silver.anu.edu.au [150.203.162.26]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15071 for ; Mon, 27 Jan 1997 16:12:46 -0800 Received: from silver (bcorrie@localhost [127.0.0.1]) by silver.anu.edu.au (8.8.2/8.8.2) with ESMTP id LAA09323; Tue, 28 Jan 1997 11:12:36 +1100 (EST) Message-Id: <199701280012.LAA09323@silver.anu.edu.au> X-Mailer: exmh version 1.6.7 5/3/96 To: info-performer@sgi.com cc: bcorrie@silver.anu.edu.au Subject: [Q] Onyx2 Reality for VR??? Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 28 Jan 1997 11:12:34 +1100 From: Brian Corrie Status: O G'day all, I have what may seem like a silly question, but I am a bit of a newbie to high end SGI graphics systems and this seems like the place to clarify some things. Sorry about the length of this email, but I thought it best to give as much info as possible to avoid confusion. We are looking at purchasing an Immersadesk VR system and an Onyx2 Reality Deskside system to drive it. The Immersadesk is a drafting sized immersive VR system with stereo viewing and both head and hand tracking. Up until recently, these devices were typically driven by a Onyx RE or Onyx IR system, usually with 1 pipe. Given the previous statement, it appears obvious that the Onyx2 Reality Deskside system would be more than capable of driving the Immersadesk. The problem (and my question) arises from the fact that the Onyx2 Reality is a scaled down version of the Onyx2 IR and I am not familiar enough with high end SGI hardware (nor familiar enough with the VR requirements imposed on these machines) to determine whether or not this 'scaling down' is going to impact drastically on opearting the Immersadesk... I am unfortunately in the position that I have to advise the powers that be on whether the machine will be capable of driving the Immeradesk successfully, so I need to find these things out... The main potential problem is the configuartion of the frame buffer. The Onyx2 Reality has an RM8 with 40 MB of frame buffer as standard, which is half the frame buffer of what the IR RM7s have (80 MB). To drive the Immersadesk, we require 1280x1024 stereo, double buffered rendering. With 40 MB of frame buffer at 1280x1024 pixels, this gives us 256 bits/pixel. My problem is that I do not know enough about the frame buffer modes of the IR pipes to be sure that we are not going to lose some capabability that we require due to having "only" 256 bits/pixel. If we are using 12bit RGBA pixels with stereo double buffering my calculations tell me that we need 4 x 48 bits (for left/front, right/front, left/back, and right/back images) and we will say 23 bits for depth. This leaves us with just over 40 bits/pxel remaining, which seems like more than enough... So my question is, am I missing anything here???? Our SGI reps here in Canberra have expressed some concern that this may not be enough. Specifically, they have stated that there will be no anti-aliasing available (only 1 sample per pixel). I have the Onyx2 Technical Report and it mentions the Accumulation Buffer, stencils, overlays, tags, and things like LA32, LA16, and MS Color (see page 20 of the Onyx2 Tech Report) without really defining what they are and how they are used. What I need to know in what circumstances are they used and how many of my valuable bits/pixel are they going to chew up? I am also interested in finding out if any of these are essential in driving a system like the Immersadesk and if so, will my 40 MB of frame buffer be enough... (Gee, I am really starting to sound possesive about that good ol' Onyx2 Reality box, I wonder if they will let me have it in my office 8-) I am hoping that someone on this list is both an Onyx2 and an Immersadesk user, as that is really what I need to answer my questions. Of course any input from anyone would be HUGELY appreciated!!!! Thanks in advance, Brian Corrie. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 02:33:38 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA01211; Tue, 28 Jan 1997 02:32:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA01195; Tue, 28 Jan 1997 02:32:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA23273; Tue, 28 Jan 1997 02:32:05 -0800 Received: from xr1.atlas.fr (xr1.atlas.fr [194.51.9.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA17678 for ; Tue, 28 Jan 1997 02:32:02 -0800 Message-Id: <199701281032.CAA17678@sgi.sgi.com> X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 28 Jan 1997 11:31:50 +0100 X400-Received: by mta xr1.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 28 Jan 1997 11:31:50 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; converted (ia5-text,iso (1) (0) (10021) (7) (1) (0) (1),iso (1) (0) (10021) (7) (1) (0) (6),iso (1) (0) (10021) (7) (1) (0) (100)); Relayed; Tue, 28 Jan 1997 11:31:35 +0100 X400-Received: by /PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/; Relayed; Tue, 28 Jan 1997 11:29:14 +0100 Date: Tue, 28 Jan 1997 11:29:14 +0100 X400-Originator: MICHAEL.BOCCARA@siege.aerospatiale.fr X400-Recipients: info-performer@sgi.com X400-MTS-Identifier: [/PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/;970128102914] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: CSI NC V3.0 From: BOCCARA Michael To: Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: pfLayer & spheres MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Status: O =0C Hi, I am using 2 concentric spheres with almost-equal radiuses. When I a= m far away from those spheres, there is a problem of flickering between almost-coplanar polygons coming from the 2 spheric layers. In order to give a priority to the biggest-radius-sphere, I have use= d a pfLayer node above the 2 nodes associated to the 2 spheres, like thi= s : layer(pfLayer) !____________ ! ! sphere_1 sphere_2 It doesnot work ; the flickering has not moved away. Do I have to understand that pfLayer works only with planar objects = ? My 2 spheres are facettized exactly the same way, ie one is the exac= t homothety of the other, so each polygon of one sphere is parallel an= d decaled from one polygon of the other sphere. That's why I expected that pfL= ayer would work. What advice would you give me to resolve this problem of priority be= tween 2 concentric spheres ? I dont want to switch off the little sphere when I am outside the bi= g one, because the big sphere is semi-transparent, to see the texture of th= e little one. Hope to have been clear enough, Cheers, Mike ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 07:31:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA01686; Tue, 28 Jan 1997 07:30:09 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA01670; Tue, 28 Jan 1997 07:30:08 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA04925; Tue, 28 Jan 1997 07:29:57 -0800 Received: from ns.calvacom.fr (ns.calvacom.fr [194.2.168.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA29592 for ; Tue, 28 Jan 1997 07:29:43 -0800 Received: from sirrah (par27.calvacom.fr [194.206.190.59]) by ns.calvacom.fr (8.7.3/8.6.9) with SMTP id QAA07234 for ; Tue, 28 Jan 1997 16:29:38 +0100 (MET) Sender: guy@ns.calvacom.fr Message-ID: <32EE1B1E.41C6@calva.net> Date: Tue, 28 Jan 1997 16:28:30 +0100 From: Guy Premont Organization: Silicon Worlds S.A. X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: Info-Performer Mailing List Subject: Video Texturing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi, I work currently on using video as texture and I think I need some help. I'm using an Onyx, 2 cpus, 2 Sirius cards, Irix 5.3 and Performer 2.0. There was a short discussion about this a couple of month ago, and it was pointed out that movietex.c was a good demo to begin with if you could make it run. I did make it run, easily. Now, I have set-up my own application to be able to use video texturing on any object. It works, but only if I turn off multiprocessing by doing pfMultiprocess(0). If I run it with multiprocessing on it core dumps the first time it tries to load the video into texture memory. I know it looks like something that hasn't been put correctly into shared memory BUT as far as I can tell every data structure involved was created from the shared arena. The pointer to the pfTexture used with pfLoadTex() comes from pfGetGStateAttr(gstate,PFSTATE_TEXTURE) and the initialisation of this pointer and pfLoadTex are all in the same process (APP). I'm beginning to wonder if there are known bugs when using video texturing in a multiprocess environment. Somebody can help? Guy Premont =========================================== Silicon Worlds S.A. 12, rue de Chatillon 75014 Paris France Tel: +33 (01) 53.90.11.11 Fax: +33 (01) 53.90.11.12 =========================================== ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 08:26:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA01857; Tue, 28 Jan 1997 08:25:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA01841; Tue, 28 Jan 1997 08:25:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA09196; Tue, 28 Jan 1997 08:24:56 -0800 Received: from sgi600.msd.lmsc.lockheed.com ([129.197.11.3]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA10977 for ; Tue, 28 Jan 1997 08:24:53 -0800 Received: by sgi600.msd.lmsc.lockheed.com (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id IAA19153; Tue, 28 Jan 1997 08:24:17 -0800 Date: Tue, 28 Jan 1997 08:24:17 -0800 From: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) Message-Id: <199701281624.IAA19153@sgi600.msd.lmsc.lockheed.com> To: info-performer@sgi.com Subject: Deleting Performer subgraphs Status: O Hi, I have been trying to write a function that would free memory for a Performer subgraph given the root node of the subgraph to be deleted. The function shown below is designed to do this by traversing the subtree deleting geosets and nodes from the bottom up. The function seems to work fine on our R4400 ONYX but I get Performer memory corruption as indicated by pfDirtCheck warnings when I run the code on on a R10000 machine. In particular, I core dump when I later use pfNodeTravMask() to set node traversal masks on the parts of the scene graph that still remain (parts that have not been deleted using this function). Can anyone spot a problem with what I am doing? (I assume that many others have written similar functions to delete Performer subgraphs) Could this be some sort of bug? (I am compiling O32 mode using Performer 2.0.) Any help would be GREATLY appreciated as I have been fighting this problem for a while. //--------------------------------------------------------------------------- // void deleteRecursor(pfNode *node) //--------------------------------------------------------------------------- void deleteRecursor(pfNode *node) { long i,j; long num_children; long numgeosets; pfGeoSet *geoset; long rval; pfGroup *parent; long numParents; long node_id = pfGetId(node); pfNode *child_node; if(!pfIsOfType(node,pfGetGeodeClassType()) && !pfIsOfType(node,pfGetLPointClassType()) && !pfIsOfType(node,pfGetBboardClassType())) { num_children = pfGetNumChildren((const pfGroup *)node); for(i = num_children - 1; i >= 0; i--) { child_node = pfGetChild((const pfGroup *)node,i); deleteRecursor(child_node); } } else if(pfIsOfType(node,pfGetGeodeClassType())) { pfGeode *geode = (pfGeode *)node; if(numgeosets = pfGetNumGSets(geode)) { for(j = numgeosets - 1; j >= 0; j--) { geoset = pfGetGSet(geode,j); pfRemoveGSet(geode,geoset); rval = pfDelete(geoset); if(rval == FALSE) { cerr << "Geoset cannot be deleted\n"; } } } } numParents = pfGetNumParents(node); for(j = numParents - 1; j >=0; j--) { parent = pfGetParent(node,j); pfRemoveChild(parent,node); } rval = pfDelete(node); if(rval == FALSE) { cerr << "Node cannot be deleted\n"; } } Thanks, Kenneth N. Sakai Lockheed Martin Missiles & Space Research Specialist/3-D Computer Graphics P.O. Box 3504 Email: sakai@lmsc.lockheed.com Sunnyvale, CA 94088-3504 Phone: (408) 756-0682 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 08:45:03 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA01916; Tue, 28 Jan 1997 08:43:49 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA01900; Tue, 28 Jan 1997 08:43:48 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA10966; Tue, 28 Jan 1997 08:43:37 -0800 Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA15241 for ; Tue, 28 Jan 1997 08:43:32 -0800 Received: from fang.dsto.defence.gov.au (fang.dsto.defence.gov.au [131.185.2.5]) by digger1.defence.gov.au (8.7.5/8.7.3) with ESMTP id PAA21281; Tue, 28 Jan 1997 15:29:43 +1030 (CST) Received: from msmail.dsto.defence.gov.au (msmail.dsto.gov.au [131.185.2.6]) by fang.dsto.defence.gov.au (8.7.6/8.7.6) with SMTP id IAA26499; Tue, 28 Jan 1997 08:55:54 +1030 (CST) Message-Id: <199701272225.IAA26499@fang.dsto.defence.gov.au> Received: by msmail.dsto.defence.gov.au via MsMail with Mimetic; Tue, 28 Jan 1997 08:57 +1030 Date: Tue, 28 Jan 1997 08:56 +1030 From: "Simpkin, Graeme" To: myidisid@interpia.net, remi@remi.asd.sgi.com Cc: info-performer@sgi.com Subject: RE: How to use performer on Window95/NT X-priority: 3 X-charset: US-ASCII Status: O R?mi Arnaud wrote: > >Gil-won Park wrote: >> >> Greetings, >> >> I have a account on Indy and I can use performer. but Indy is located >> distant from me about 40KM. >> >> Fortunately, I can use network of T1. So, I use exceed 5.0 & Windows95 >> >> Pls give me a answer for using IRIX 5.3 remotely in Windows95/NT. >> >> Thnks for reading. >> > > I don't think exceed is compatible with opengl. It is surely not compatible > with IrisGL. Please contact your exceed support for confirmation. Actually, you can now purchase openGL extensions for the exceed product (5.x) . We tested the exceed openGL extensions (making the NT box a GLX display). Our simple.c performer application, compiled to use open GL, worked fine on the PC. Not real fast - seemed to be pixel fill limited. But I was still impressed at seeing my performer app display on the PC - might be OK for remote coding etc. regards, Graeme Simpkin ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 08:54:52 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA02033; Tue, 28 Jan 1997 08:52:44 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA02001; Tue, 28 Jan 1997 08:52:43 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA11884; Tue, 28 Jan 1997 08:52:32 -0800 Received: from dub-img-7.compuserve.com (dub-img-7.compuserve.com [149.174.206.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17891 for ; Tue, 28 Jan 1997 08:52:29 -0800 Received: by dub-img-7.compuserve.com (8.6.10/5.950515) id LAA03451; Tue, 28 Jan 1997 11:52:28 -0500 Date: 28 Jan 97 11:47:17 EST From: Jean BENOIT <101372.3460@CompuServe.COM> To: info_performer Subject: Re: add triangles in a pfGeode Message-ID: <970128164716_101372.3460_JHP141-3@CompuServe.COM> Status: O If you want to had triangles with their texture and color, you can use pfdbuilder functions. if it's only to correct a Geode you have to get its geosets and their arrays and modify them . Yoel ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 08:54:51 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA01997; Tue, 28 Jan 1997 08:52:42 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA01980; Tue, 28 Jan 1997 08:52:41 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA11878; Tue, 28 Jan 1997 08:52:30 -0800 Received: from dub-img-7.compuserve.com (dub-img-7.compuserve.com [149.174.206.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17889 for ; Tue, 28 Jan 1997 08:52:29 -0800 Received: by dub-img-7.compuserve.com (8.6.10/5.950515) id LAA03445; Tue, 28 Jan 1997 11:52:28 -0500 Date: 28 Jan 97 11:47:08 EST From: Jean BENOIT <101372.3460@CompuServe.COM> To: info_performer Subject: zbuf and texture on Impact Again Message-ID: <970128164708_101372.3460_JHP141-2@CompuServe.COM> Status: O For the texture detail problem, it's the samme with 1 or 4 TRAM. It's look like a little rubban just in front of me. For the zbuffer problem: I discover that subfaces are not cutting by the EarthandSky model (it's works only with Clear mode) . it's seems to work better but not perfect when I use the Stencil Mode for Layer. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 08:54:52 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA02017; Tue, 28 Jan 1997 08:52:43 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA01999; Tue, 28 Jan 1997 08:52:42 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA11881; Tue, 28 Jan 1997 08:52:31 -0800 Received: from dub-img-7.compuserve.com (dub-img-7.compuserve.com [149.174.206.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17885 for ; Tue, 28 Jan 1997 08:52:28 -0800 Received: by dub-img-7.compuserve.com (8.6.10/5.950515) id LAA03436; Tue, 28 Jan 1997 11:52:27 -0500 Date: 28 Jan 97 11:46:57 EST From: Jean BENOIT <101372.3460@CompuServe.COM> To: info_performer Subject: IR texture Message-ID: <970128164656_101372.3460_JHP141-1@CompuServe.COM> Status: O I work with Performer 2.1 on OpenGL Version I notice a problem of dithering on texture like on MaxImpact. Another patch on 2.1 ? Yoel ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 09:25:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA02356; Tue, 28 Jan 1997 09:24:49 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA02340; Tue, 28 Jan 1997 09:24:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA15286; Tue, 28 Jan 1997 09:24:38 -0800 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA25812 for ; Tue, 28 Jan 1997 09:24:32 -0800 Received: from christine.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA52435; Tue, 28 Jan 1997 12:13:28 -0500 Received: by christine.cae.ca (950413.SGI.8.6.12/930416.SGI) id MAA00599; Tue, 28 Jan 1997 12:10:22 -0500 From: "Nicolas Gauvin" Message-Id: <9701281210.ZM597@christine.cae.ca> Date: Tue, 28 Jan 1997 12:10:22 -0500 In-Reply-To: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) "Deleting Performer subgraphs" (Jan 28, 8:24am) References: <199701281624.IAA19153@sgi600.msd.lmsc.lockheed.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: sakai@lmsc.lockheed.com Subject: Re: Deleting Performer subgraphs Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 28, 8:24am, Ken Sakai wrote: > Subject: Deleting Performer subgraphs > > Hi, > > I have been trying to write a function that would free memory for a > Performer subgraph given the root node of the subgraph to be deleted. You don't really need to write such a function since Performer already does it for you. Using pfDelete on a node which has no parent (ie its ref count is zero) will free all memory associated to the subgraph under it (if no part of this subgraph is referenced elsewhere). In other words, Performer will traverse all its children and call pfDelete on them as well as on their geosets and whatever else. You might want to consider using pfAsyncDelete in order to have a separate DBASE process carry out this deletion so it doesn't affect too much your regular Performer loop. -- Nicolas Gauvin CAE Electronics Ltd., 8585 Cote De Liesse Software Developer Saint-Laurent, Quebec, Canada, H4L-4X4 3-D Graphics Applications tel: +1 514 341 2000 extension 2275 nicolas@cae.ca fax: +1 514 340 5496 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 09:23:34 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA02325; Tue, 28 Jan 1997 09:22:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA02309; Tue, 28 Jan 1997 09:22:15 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA15082; Tue, 28 Jan 1997 09:22:04 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA25333 for ; Tue, 28 Jan 1997 09:22:02 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA09623; Tue, 28 Jan 97 11:20:09 -0500 Date: Tue, 28 Jan 97 11:20:09 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701281620.AA09623@mred.bgm.link.com> To: info-performer@sgi.com Subject: Re: Deleting Performer subgraphs Status: O sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) said: > I have been trying to write a function that would free memory for a > Performer subgraph given the root node of the subgraph to be deleted. ...lots of code... Why all the complication? Just pfRemoveChild the root node from the tree and then pfDelete it and you are done. RTFM for pfDelete: pfDelete frees the memory associated with mem if its reference count is <= 0. When an object is freed, it decrements the reference count of all pfMemories that it once referenced and will delete any of these pfMemories with reference counts that are <= 0. Thus, pfDelete will fol- low all reference chains until it encounters a pfMemory which it cannot delete. Note that the reference count of a pfNode is incremented each time it is added as a child to a pfGroup. Thus, a pfNode must be removed from all its parents before it can be deleted. This means that it will recursively do just what you want. If you are deleting in realtime, you might want to consider pfAsyncDelete(). Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 09:32:42 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA02437; Tue, 28 Jan 1997 09:31:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA02421; Tue, 28 Jan 1997 09:31:35 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA16085; Tue, 28 Jan 1997 09:31:24 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27615; Tue, 28 Jan 1997 09:31:18 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA11024; Tue, 28 Jan 1997 17:31:12 GMT From: "Angus Dorbie" Message-Id: <9701281731.ZM11022@bitch.reading.sgi.com> Date: Tue, 28 Jan 1997 17:31:11 +0000 In-Reply-To: Jean BENOIT <101372.3460@compuserve.com> "IR texture" (Jan 28, 11:46am) References: <970128164656_101372.3460_JHP141-1@CompuServe.COM> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Jean BENOIT <101372.3460@compuserve.com>, info_performer Subject: Re: IR texture Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I think you mean texture quantisation. You'll be using 5 bits per component on iR by default. Use your modeller, a scene graph traversal or a loader callback to modify the textures in the database to use an internal format of 8bpc. You may preffer to use higher contrast textures and maintain better fill performance. Cheers, Angus. On Jan 28, 11:46am, Jean BENOIT wrote: > Subject: IR texture > I work with Performer 2.1 on OpenGL Version > I notice a problem of dithering on texture like on MaxImpact. > Another patch on 2.1 ? > > Yoel > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Jean BENOIT ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 12:24:53 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA03230; Tue, 28 Jan 1997 12:18:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA03214; Tue, 28 Jan 1997 12:18:50 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA02893; Tue, 28 Jan 1997 12:18:46 -0800 Received: from ist.ucf.edu (babylon.ist.ucf.edu [132.170.193.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA11043 for ; Tue, 28 Jan 1997 12:18:43 -0800 Received: from raider.ist.ucf.edu (raider.ist.ucf.edu [132.170.194.10]) by ist.ucf.edu (8.7.3/8.7.3) with SMTP id PAA12799 for ; Tue, 28 Jan 1997 15:18:36 -0500 (EST) Received: by raider.ist.ucf.edu (940816.SGI.8.6.9) id PAA00822; Tue, 28 Jan 1997 15:18:35 -0500 From: "Dave Russell" Message-Id: <9701281518.ZM820@raider.ist.ucf.edu> Date: Tue, 28 Jan 1997 15:18:34 -0500 X-Face: S,2I_5VKb+qvoohP]aM-hI"ln#&"["HRuLvG(kLkVX\Crtw&ADY&|w|&[%dwM!5|{RL(FcaX|CB[vgqz!B8fj-:g'KT}D\b!5&M5K?0>MU@F9dfKy7PH]2)K?zW7lxT(Gs- X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.com Subject: Spaceball Interface Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O After several days of investigation, I must admit apparent defeat and ask for help on this issue. I perused the archives last Thursday and noted that a question involving accessing a spaceball in Performer was posted with no apparent responses. I'm now asking for help in this matter. I have code which has been used in the past to access a spaceball through the GL event queue. Unfortunately, this code will obviously not function in the OpenGL/X environment that I am now trying to support. I have found reference to and examples of accessing the spaceball through SGI X extensions, but have not found a way to allow these to work in conjunction with the pfuGetEvent() system of event handling. I have come to the conclusion that I have three real choices as to how to proceed. I would like corrections if there is another option or opinions on how to proceed with the best of these options: 1) Modify the pfutil library source to make use of the Spaceball Extensions. (Ugghh, create a "proprietary" Performer library) 2) Make my own X event handler which in many ways mimicks the pfutil library functionality (Ugghh, create a "proprietary" Performer library, but don't call it that) 3) Quit fooling with X, write a serial based driver directly for the spaceball and create some kind of event queue of my own to handle the whole ugly mess. Of course, I'm not real fond of any of these options as they are far more complicated than I had ever expected, but I'd certainly appreciate any words of wisdom related to this particular problem. -- David Russell | Visual Systems Lab | Static worlds breed Institute for Simulation and Training | static minds. | drussell@ist.ucf.edu | CHANGE YOUR (virtual) WORLD! ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 15:27:29 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA04450; Tue, 28 Jan 1997 15:24:53 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA04434; Tue, 28 Jan 1997 15:24:52 -0800 Received: from roll.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA04119; Tue, 28 Jan 1997 15:24:40 -0800 Received: from odin.corp.sgi.com by roll.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA13352; Tue, 28 Jan 1997 14:12:45 -0800 Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id OAA24559; Tue, 28 Jan 1997 14:12:41 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA07017 for ; Tue, 28 Jan 1997 14:12:15 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Tue, 28 Jan 1997 16:58:34 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Tue, 28 Jan 1997 16:58:32 Eastern Standard Time Message-ID: <32EE7BF8.2C9A@ivex3d.com> Date: Tue, 28 Jan 1997 17:21:44 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com, info-vega@paradigmsim.com Subject: pfColorTable/vgObjCTab !!! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi, How does vgObjCTab work ? All I know is, it attaches a Coloratable to an object. Is there such a mechanism under Performer, which allows me to get the colortable of an object and modify the r,g,b,a values and reapply the parameters ? In Perf., applying a colortable works globally, but I want to do this on a per-object basis. Thanks Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 20:56:22 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id UAA06361; Tue, 28 Jan 1997 20:49:30 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id UAA06345; Tue, 28 Jan 1997 20:49:29 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id UAA21889; Tue, 28 Jan 1997 20:49:18 -0800 Received: from emerald.oz.net (emerald.oz.net [198.68.184.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA23244 for ; Tue, 28 Jan 1997 20:49:17 -0800 Received: from avi.oz.net (avi.oz.net [206.61.159.122]) by emerald.oz.net (8.8.4/8.7.3) with SMTP id VAA16370 for ; Tue, 28 Jan 1997 21:03:04 -0800 (PST) Date: Tue, 28 Jan 1997 21:03:04 -0800 (PST) Message-Id: <1.5.4.16.19970128205209.269f80d6@oz.net> X-Sender: avi@oz.net X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.com From: Avi Bar-Zeev Subject: Alias or Softimage Animation Loaders Status: O I'm looking for a public domain or commercially available set of routines (preferably source) for loading either Alias or Softimage animation data (including transforms, paths, and morphs if possible) into some form of a Performer runtime database. I understand the conversion issues well enough but I'd like to not recreate the wheel if possible. And I'd prefer not to use any commercial API (e.g., Softimage game SDK) just for the loader _if_ that precludes me from using Performer directly. BTW, I can find several paths for loading basic geometry but I haven't found any that include animation data. I'm sure someone's already written this (as we did in my former company) but I need something that's not proprietary. Thanks for any help. Avi P.S. If there are none, then I'll need to hire a consultant who can write this. Has anyone used a consultant they'd like to recommend? Avi Bar-Zeev -- "Every trip begins with a single misstep" A Real-Time 3-D Animated Character -- avi@oz.net http://www.oz.net/~avi WOLFCHILD-3D Consulting -- avi@wolfchild.com http://www.wolfchild.com/3d ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Tue Jan 28 23:58:13 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id XAA06612; Tue, 28 Jan 1997 23:56:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id XAA06596; Tue, 28 Jan 1997 23:56:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA27085; Tue, 28 Jan 1997 23:56:45 -0800 Received: from rtset.co.il (oren.rtset.co.il [194.90.96.233]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA17681 for ; Tue, 28 Jan 1997 23:56:37 -0800 Received: (from rany@localhost) by rtset.co.il (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA03363; Wed, 29 Jan 1997 09:51:06 +0200 Date: Wed, 29 Jan 1997 09:51:06 +0200 From: rany@rtset.co.il (Ran Yakir) Message-Id: <9701290951.ZM3361@oren.rtset.co.il> In-Reply-To: "Rambabu" "pfColorTable/vgObjCTab !!!" (Jan 28, 5:21pm) References: <32EE7BF8.2C9A@ivex3d.com> X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: "Rambabu" Subject: Re: pfColorTable/vgObjCTab !!! Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 28, 5:21pm, Rambabu wrote: > How does vgObjCTab work ? All I know is, it attaches a Coloratable to an > object. Is there such a mechanism under Performer, which allows me to > get the colortable of an object and modify the r,g,b,a values and > reapply the parameters ? In Perf., applying a colortable works globally, ----------------------------------------------------------------^ Not exactly. You can attach a pfColorTable to a pfGeoState with pfGStateAttr. You will have to enable colortabling for that geostate with pfGStateMode Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | RT-SET Ltd. / )_ (_(_) ) \/ (_(_/<_(_)( | _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@rtset.co.il Work : 972-9-9552236 | rany@netvision.net.il Res. : 972-9-7489974 | Fax : 972-9-9552239 | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 01:17:24 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA06811; Wed, 29 Jan 1997 01:16:10 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA06795; Wed, 29 Jan 1997 01:16:10 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA01135; Wed, 29 Jan 1997 01:15:59 -0800 Received: from crane.cf.ac.uk (crane.cf.ac.uk [131.251.0.45]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA27522 for ; Wed, 29 Jan 1997 01:15:57 -0800 Received: from thor.cf.ac.uk by crane.cf.ac.uk with SMTP (PP); Wed, 29 Jan 1997 09:13:24 +0000 Received: from localhost (saprar@localhost) by thor.cf.ac.uk (8.8.5/8.6.12) with SMTP id JAA22904 for ; Wed, 29 Jan 1997 09:15:53 GMT Date: Wed, 29 Jan 1997 09:15:52 +0000 (GMT) From: Roy Ruddle Reply-To: Ruddle@cardiff.ac.uk To: info-performer@sgi.com Subject: Multiple camera positions in 1 channel(!) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O We're investigating some of the cognitive problems people have developing mental models of discontinuous VEs. In some of our VEs, certain locations visually "appear" to be in more than one place. I can render these VEs if I update the parent DCSs of nodes between multiple pfDraw() calls from the channel draw function (pfChanDrawFunc()). However, my life may become easier if I can leave the DCSs unchanged and change the view position between each pfDraw() call (yes, my databases would look visually correct if I do this!). So, the question: Is there a way I can change the camera position between multiple pfDraw() calls for each frame of a channel? I tried this, but Performer seemed always to use the position supplied in the first pfChanView() call and ignore the second call. cheers roy PS. We're running PF1.2 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 04:04:16 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA07367; Wed, 29 Jan 1997 04:01:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA07351; Wed, 29 Jan 1997 04:01:26 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA06679; Wed, 29 Jan 1997 04:01:15 -0800 Received: from ns.yle.fi (ns.yle.fi [193.65.105.161]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA19092 for ; Wed, 29 Jan 1997 04:01:05 -0800 Received: by ns.yle.fi; id OAA14547; Wed, 29 Jan 1997 14:00:39 +0200 (EET) Received: from thaxp1.yle.fi(193.65.107.2) by ns.yle.fi via smap (3.2) id xma014539; Wed, 29 Jan 97 14:00:35 +0200 Received: by thaxp1.yle.fi id OAA17822 ; Wed, 29 Jan 1997 14:00:52 +0200 (EET) Received: from onyx.yle.fi (onyx.yle.fi [192.168.250.201]) by sgisrv.yle.fi (950413.SGI.8.6.12/8.6.9) with SMTP id OAA05815 for ; Wed, 29 Jan 1997 14:00:18 +0200 Sender: harri@yle.fi Message-ID: <32EF3BD1.ABD@yle.fi> Date: Wed, 29 Jan 1997 14:00:17 +0200 From: Harri Kaimio Organization: Finnish Broadcasting Company X-Mailer: Mozilla 3.0Gold (X11; I; IRIX64 6.2 IP19) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Performer & color_matrix_SGI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi all Performer gurus! I am afraid I have lost all hope of understanding, how Performer works internally :-( I am working on a project in which I need to change the color saturation (perhaps also hue) of part of the scene graph over time. The way I have planned to do it is by using the color matrix OpenGL extension. My source code looks like this: int bwPreDraw( pfTraverser * ) { // draw callback to turn on color matrix stuff float colorMat[16]; // set up the color matrix ... // Store current matrix mode int mmode[1]; glGetIntegerv( GL_MATRIX_MODE, mmode ); glMatrixMode( GL_COLOR ); glLoadMatrixf( colorMat ); glMatrixMode( mmode[0] ); return PFTRAV_CONT; } int bwPostDraw( pfTraverser * ) { // Turn off color matrixes int mmode[1]; glGetIntegerv( GL_MATRIX_MODE, mmode ); glMatrixMode( GL_COLOR ); glLoadIdentity(); glMatrixMode( mmode[0] ); return PFTRAV_CONT; } ... // Set color matrix callbacks for a node node->setTravFuncs( PFTRAV_DRAW, bwPreDraw, bwPostDraw ) ... OK, this kind of works - I can specify different color matrix for different nodes and the results look correct, BUT I CANNOT ANIMATE THE COLOR MATRIXES. If I change the color matrix used for a certain object between frames, it makes no visible difference in the rendered picture - it is always rendered using the color matrices specified in the first frame of simulation. I have checked that my callbacks are really called and correct color matrixes have been loaded for each frame. Can someone wiser than me explain what is happening? The only explanation I can think of is that perhaps Performer stores my database into a GL display list during the first frame, so my color matrices are also stored there. I is so? And what would be the best way around this problem? Of course I could render the scene twice, the second time with B/W textures, but I am not very fond of that idea (twice the geometry, twice the textures, more difficult to use as a "plug-and-play" routine, difficulties in using transparent objects...) I would greatly appreciate any help on this. -- ----------------------------------------------------------------- Harri Kaimio | harri.kaimio@yle.fi Computer Graphics Specialist | http://cartes.hut.fi/~hkaimio Finnish Broadcasting Company | Tel. +358-40-50 67 679 TV Production Operations | Fax. +358-0-1480 4769 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 04:43:19 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA07517; Wed, 29 Jan 1997 04:42:12 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA07501; Wed, 29 Jan 1997 04:42:12 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA07771; Wed, 29 Jan 1997 04:41:56 -0800 Received: from server.rtset.co.il ([194.90.96.254]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA23596 for ; Wed, 29 Jan 1997 04:41:44 -0800 Received: from rtset.co.il (eclipse.rtset.co.il [194.90.96.228]) by server.rtset.co.il (8.6.12/8.6.9) with ESMTP id OAA02920; Tue, 30 Jan 1996 14:33:56 +0200 Received: (from rany@localhost) by rtset.co.il (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA05908; Wed, 29 Jan 1997 13:49:26 +0200 From: "Ran Yakir" Message-Id: <9701291349.ZM5906@eclipse> Date: Wed, 29 Jan 1997 13:49:25 +0000 In-Reply-To: Harri Kaimio "Performer & color_matrix_SGI" (Jan 29, 2:00pm) References: <32EF3BD1.ABD@yle.fi> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Harri Kaimio Subject: Re: Performer & color_matrix_SGI Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 29, 2:00pm, Harri Kaimio wrote: > Subject: Performer & color_matrix_SGI > I am working on a project in which I need to change the color saturation > (perhaps also hue) of part of the scene graph over time. The way I have > planned to do it is by using the color matrix OpenGL extension. My > source code looks like this: > > > int > bwPreDraw( pfTraverser * ) > { > // draw callback to turn on color matrix stuff > float colorMat[16]; > > // set up the color matrix > ... > > // Store current matrix mode > int mmode[1]; > glGetIntegerv( GL_MATRIX_MODE, mmode ); > > glMatrixMode( GL_COLOR ); > glLoadMatrixf( colorMat ); > glMatrixMode( mmode[0] ); > return PFTRAV_CONT; > } > > int > bwPostDraw( pfTraverser * ) > { > // Turn off color matrixes > int mmode[1]; > glGetIntegerv( GL_MATRIX_MODE, mmode ); > glMatrixMode( GL_COLOR ); > > glLoadIdentity(); > glMatrixMode( mmode[0] ); > return PFTRAV_CONT; > } > > ... > > // Set color matrix callbacks for a node > node->setTravFuncs( PFTRAV_DRAW, bwPreDraw, bwPostDraw ) > > ... > > OK, this kind of works - I can specify different color matrix for > different nodes and the results look correct, BUT I CANNOT ANIMATE THE > COLOR MATRIXES. If I change the color matrix used for a certain object > between frames, it makes no visible difference in the rendered picture - > it is always rendered using the color matrices specified in the first > frame of simulation. I have checked that my callbacks are really called > and correct color matrixes have been loaded for each frame. Color matrix is not applied to glColor as it is sent to the pipe. Also, it is not applied to texture fragements after the filtering. It is only applied to texture pixels, as they are being loaded to the texture memory, using glTexImage, glCopyTexSubImage, etc, and to pixels drawn with glDrawPixels and glCopyPixels. In your case, when you draw the frame for the first time, the textures are being loaded when they are first applied, so they are transformed by the color matrix. To do realtime modifications of colors you have several choices : 1. Use a pfColortable, that will allow you to change the vertex colors on the fly. On iR, it will propobaly hurt your performance. 2. Use the GL_POST_TEXTURE_FILTER_SCALE_SGIX and GL_POST_TEXTURE_FILTER_BIAS_SGIX texture parameters. Those allow you to set a scale and bias for texture fragements after filtering. You will have to call them in the GeoState callback functions, after the texture is bound (glBindTextureEXT). Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | RT-SET Ltd. / )_ (_(_) ) \/ (_(_/<_(_)( | _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@rtset.co.il Work : 972-9-9552236 | rany@netvision.net.il Res. : 972-9-7489974 | Fax : 972-9-9552239 | ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 05:40:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id FAA07725; Wed, 29 Jan 1997 05:39:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id FAA07709; Wed, 29 Jan 1997 05:39:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA09911; Wed, 29 Jan 1997 05:38:57 -0800 Received: from svmail03.mdc.com (SVMAIL03.MDC.COM [130.38.186.34]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA00635 for ; Wed, 29 Jan 1997 05:38:54 -0800 Received: from mdc.com by svmail03.mdc.com with SMTP (1.37.109.20/16.2) id AA142195293; Wed, 29 Jan 1997 07:41:33 -0600 Received: from GWXSL002-Message_Server by mdc.com with Novell_GroupWise; Wed, 29 Jan 1997 07:41:32 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 29 Jan 1997 07:38:14 -0600 From: Bryan Wasileski To: info-performer@sgi.com Subject: draw times Status: O Performers: Does any know how to deterministically calculate, in closed form, the draw and cull times per viewport (channel) for a Performer app? Some would say that deterministic and SGI don't usually go together in the same sentence but I need to at least get close. The application I have can have anywhere from 1-28 viewports and I need to know how to pre-determine the frame rate as a function of the number of channels. Any help or direction would be greatly appreciated. Thanks - bryan wasileski McDonnell Douglas Training Systems St. Louis, MO bwasileski@mdc.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 07:18:11 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA07947; Wed, 29 Jan 1997 07:16:46 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA07931; Wed, 29 Jan 1997 07:16:45 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA14248; Wed, 29 Jan 1997 07:16:36 -0800 Received: from lobster.bu.edu (LOBSTER.BU.EDU [128.197.160.43]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA16343 for ; Wed, 29 Jan 1997 07:16:31 -0800 Received: (from ebrisson@localhost) by lobster.bu.edu (8.8.4/8.7.3) id KAA128016 for info-performer@sgi.com; Wed, 29 Jan 1997 10:16:40 -0500 From: Erik Brisson Message-Id: <199701291516.KAA128016@lobster.bu.edu> Subject: pfLightColor() Unknown color token To: info-performer@sgi.com Date: Wed, 29 Jan 97 10:16:40 EST X-Mailer: ELM [version 2.3 PL11] Status: O I get these errors: PF Warning/Usage: pfLightColor() Unknown color token 4608. PF Warning/Usage: pfLightColor() Unknown color token 4609. PF Warning/Usage: pfLightColor() Unknown color token 4610. >From these calls: camlightsource = pfNewLSource(); pfLSourceColor(camlightsource, PFLT_AMBIENT, 0.2f, 0.2f, 0.2f); pfLSourceColor(camlightsource, PFLT_DIFFUSE, 1.0f, 1.0f, 1.0f); pfLSourceColor(camlightsource, PFLT_SPECULAR,1.0f, 1.0f, 1.0f); Can anyone tell me what I am doing wrong? Not getting some shared library, perhaps? (In case that is the problem, here is my link line: cc -O -32 -o buidesk buideskMain.o -L/usr/local/CAVE/lib -lpfcave_igl -L/usr/lib -L/usr/lib/libpfdb -L/lib -all -ignore_unresolved -lpf_igl -lpfdu_igl -lpfui -lpfutil_igl -limage -lfm -lgl -lXm -lXt -lXirisw -lfpe -lXmu -lX11 -lm -lmalloc -lC I am running Performer 2.0 (with the 2.0.2 patches, and the 2.0.1 exec env) on an Onyx with RE2, IRIX 6.2 Thank you, Erik P.s. I did find a possible clue: parameter ( GL_AMBIENT = 4608 ) in /usr/include/GL/fgl.h. But this seems a strange place to be getting stuff from. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 07:18:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA07967; Wed, 29 Jan 1997 07:17:33 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA07951; Wed, 29 Jan 1997 07:17:33 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA14433; Wed, 29 Jan 1997 07:17:25 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA16532 for ; Wed, 29 Jan 1997 07:17:24 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA20654; Wed, 29 Jan 1997 10:10:11 -0500 Date: Wed, 29 Jan 1997 10:10:11 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701291010.ZM20653@hotsauce.clubfed.sgi.com> In-Reply-To: Bryan Wasileski "draw times" (Jan 29, 7:38am) References: Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Bryan Wasileski , info-performer@sgi.com Subject: Re: draw times Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 29, 7:38am, Bryan Wasileski wrote: > Subject: draw times > Performers: > Does any know how to deterministically calculate, in closed form, the > draw and cull times per viewport (channel) for a Performer app? > Some would say that deterministic and SGI don't usually go together > in the same sentence but I need to at least get close. The application I > have can have anywhere from 1-28 viewports and I need to know how > to pre-determine the frame rate as a function of the number of channels. > > Any help or direction would be greatly appreciated. Thanks > > - bryan wasileski > McDonnell Douglas Training Systems > St. Louis, MO > bwasileski@mdc.com > > > > > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Bryan Wasileski This probably isn't much help and it seems obvious but the example program multichan.C could be modified to accept the number of channels desired on the command line then using pfStats you could do some measurements with a sample database which is relavent to your project. This is just a suggestion I don't have any SGI benchmark numbers to give you. I guess the big hangup with drawing multiple channels is the gfx context switch plus you have to download the textures all over again. mulitchan is in /usr/share/Performer/src/pguide/libpf/C|C++ Brian -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 07:40:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA08126; Wed, 29 Jan 1997 07:39:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA08110; Wed, 29 Jan 1997 07:39:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA15625; Wed, 29 Jan 1997 07:39:29 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA20987 for ; Wed, 29 Jan 1997 07:39:27 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA20726; Wed, 29 Jan 1997 10:32:08 -0500 Date: Wed, 29 Jan 1997 10:32:08 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701291032.ZM20725@hotsauce.clubfed.sgi.com> In-Reply-To: Harri Kaimio "Performer & color_matrix_SGI" (Jan 29, 2:00pm) References: <32EF3BD1.ABD@yle.fi> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Harri Kaimio , info-performer@sgi.com Subject: Re: Performer & color_matrix_SGI Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 29, 2:00pm, Harri Kaimio wrote: > Subject: Performer & color_matrix_SGI > Hi all Performer gurus! > > I am afraid I have lost all hope of understanding, how Performer works > internally :-( > > I am working on a project in which I need to change the color saturation > (perhaps also hue) of part of the scene graph over time. The way I have > planned to do it is by using the color matrix OpenGL extension. My > source code looks like this: > > > int > bwPreDraw( pfTraverser * ) > { > // draw callback to turn on color matrix stuff > float colorMat[16]; > > // set up the color matrix > ... > > // Store current matrix mode > int mmode[1]; > glGetIntegerv( GL_MATRIX_MODE, mmode ); > > glMatrixMode( GL_COLOR ); > glLoadMatrixf( colorMat ); > glMatrixMode( mmode[0] ); > return PFTRAV_CONT; > } > > int > bwPostDraw( pfTraverser * ) > { > // Turn off color matrixes > int mmode[1]; > glGetIntegerv( GL_MATRIX_MODE, mmode ); > glMatrixMode( GL_COLOR ); > > glLoadIdentity(); > glMatrixMode( mmode[0] ); > return PFTRAV_CONT; > } > > ... > > // Set color matrix callbacks for a node > node->setTravFuncs( PFTRAV_DRAW, bwPreDraw, bwPostDraw ) > > ... > > OK, this kind of works - I can specify different color matrix for > different nodes and the results look correct, BUT I CANNOT ANIMATE THE > COLOR MATRIXES. If I change the color matrix used for a certain object > between frames, it makes no visible difference in the rendered picture - > it is always rendered using the color matrices specified in the first > frame of simulation. I have checked that my callbacks are really called > and correct color matrixes have been loaded for each frame. > > Can someone wiser than me explain what is happening? The only > explanation I can think of is that perhaps Performer stores my database > into a GL display list during the first frame, so my color matrices are > also stored there. I is so? And what would be the best way around this > problem? > > Of course I could render the scene twice, the second time with B/W > textures, but I am not very fond of that idea (twice the geometry, twice > the textures, more difficult to use as a "plug-and-play" routine, > difficulties in using transparent objects...) > > I would greatly appreciate any help on this. > -- > ----------------------------------------------------------------- > Harri Kaimio | harri.kaimio@yle.fi > Computer Graphics Specialist | http://cartes.hut.fi/~hkaimio > Finnish Broadcasting Company | Tel. +358-40-50 67 679 > TV Production Operations | Fax. +358-0-1480 4769 > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Harri Kaimio Harri, to find out how performer works get a hold of the 1994 SIGGRAPH Proceedings and read "IRIS Performer: A High Performance Multiprocessing Toolkit for Real-Time 3D Graphics" should help your understanding greatly. Brian -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 08:07:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA08281; Wed, 29 Jan 1997 08:05:21 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA08265; Wed, 29 Jan 1997 08:05:21 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA17514; Wed, 29 Jan 1997 08:05:20 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA25376 for ; Wed, 29 Jan 1997 08:05:17 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA13492; Wed, 29 Jan 97 10:03:26 -0500 Date: Wed, 29 Jan 97 10:03:26 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701291503.AA13492@mred.bgm.link.com> To: info-performer@sgi.com Subject: NTSC output from iR. Status: O Anybody out there playing with the NTSC encoder on Inf.Reality? I'm trying to videotape some of my normal 1280x1024/60Hz simulations. When I set up ircombine on my iR box for 1280x1024 (60Hz) on one DG-2 output and NTSC on the other, I see an occasional horizontal discontinuity creeping up the NTSC display - no such artifact appears on the regular display. This looks like the kind of thing that you might expect if the buffer swap wasn't correctly sync'ed to the vertical retrace. When I check the frame rates in ircombine, it says that my 1280x1024 channel is running at 60Hz and the NTSC is at 59.94Hz. ircombine doesn't seem to have any place to change this frame rate. This is evidently the reason why I have this discontinuity in the video output. Can anyone answer the following questions? * What is the reason for this 0.06Hz discrepancy? * Am I correct in assuming that this is the reason for the occasional creeping discontinuity in my NTSC recordings. * What can I do about it? Thanks in advance. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 08:06:54 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA08263; Wed, 29 Jan 1997 08:05:02 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA08247; Wed, 29 Jan 1997 08:05:02 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA17409; Wed, 29 Jan 1997 08:05:01 -0800 Received: from nordwest.pop.de (mail.nordwest.POP.DE [193.100.96.7]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA25212 for ; Wed, 29 Jan 1997 08:04:59 -0800 Received: from pink.atlas.de by nordwest.pop.de with smtp (Smail3.1.28.1 #6) id m0vpcU8-0000n5C; Wed, 29 Jan 97 17:03 MEZ Received: from trixi by pink.atlas.de (4.1/SMI-4.1) id AA04430; Wed, 29 Jan 97 17:04:53 +0100 Date: Wed, 29 Jan 1997 17:03:29 +0000 (WET) From: Nikolaus Hanekamp X-Sender: klaus@trixi To: info-performer@sgi.com Subject: Job Opportunities in Bremen (Germany) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O STN ATLAS has open positions for software engineers, to extend its Image Generator Software Group: 1. Design and development of visual simulation software for various applications. 2. Design and development of database generation software in conjunction with STN ATLAS own roadtool (START) and other modelling tools, like MultiGen or DWB. (see also http://www.public.asu.edu/~image/IMG/Img9702.html) Qualified candidates should have a MS degree or Diplom in Computer Science or related fields, a strong programming background in C++/Unix and 2 years experience in: - Object-oriented design and development of large software systems - SGI Performer and OpenGl - 3D Modelling ( OpenFlight, MultiGen, DWB or Medit ) - Real-time visual systems - Unix ( preferable IRIX) The Simulation Division ( 500 employees) of STN ATLAS ( 4500 employees) is located in Bremen, northern Germany. The main activities are: - driving simulators - ship handling simulators - power plant simulators - tank simulators - combat trainers - computer based training systems - etc. For more details please email or fax to the address below. ______________________________________________________________________________ | STN ATLAS Elektronik GmbH D-28305 Bremen | | Nikolaus Hanekamp Simulation Division ETZ2 Sebaldsbruecker Heerstr. 235 | | +49/421/457-2906 -4120 fax | |___________ hanekamp@atlas.de _________________________________| ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 08:46:18 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA08550; Wed, 29 Jan 1997 08:44:51 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA08534; Wed, 29 Jan 1997 08:44:50 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA20389; Wed, 29 Jan 1997 08:44:39 -0800 Received: from gauntlet.ht.com (he.ht.com [207.22.119.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA04219 for ; Wed, 29 Jan 1997 08:44:36 -0800 Received: by gauntlet.ht.com; id LAA13757; Wed, 29 Jan 1997 11:44:14 -0500 (EST) Received: from unknown(10.0.100.2) by gauntlet.ht.com via smap (3.2) id xma013755; Wed, 29 Jan 97 11:44:13 -0500 Received: by ht.com (950413.SGI.8.6.12/3.1.090690-High Techsplanations) id QAA17710; Wed, 29 Jan 1997 16:43:44 GMT From: "Morten Bro-Nielsen" Message-Id: <9701291143.ZM17708@ht.com> Date: Wed, 29 Jan 1997 11:43:44 -0500 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: JOBS: Simulation/CG at HT Medical Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O HT Medical, Inc. is looking for new people to join our exciting team. HT Medical, Inc. (formerly High Techplanations) of Rockville, Maryland is a leading developer of physically-based virtual environment software whose primary application area is surgery simulation. We are currently working on projects for development of turnkey products as well as core research, and has immediate full-time openings for several software development people. At HT you will find an exciting team of people, a full machine park with all the stuff you ever wanted to try, and a lot of challenges. 1. Sr. software engineer - Simulation and Graphics [Multiple positions] We are looking for creative, problem-solving individuals (M.Sc./Ph.D. or equivalent) to work on advanced simulation software for our virtual surgery systems. If you like developing advanced solutions for practical problems, can implement algorithms from SIGGRAPH papers, and find the idea of writing such a paper an interesting challenge, you are the right person. You need a strong background in applied math, must be familiar with OpenGL computer graphics on SGI/UNIX workstations. Physically based modeling and SGI Performer experience a plus. C/C++ required, real-time systems and OO would be nice. 2. Software engineer - Computer Graphics [Multiple positions] We are looking for creative, problem-solving individuals (B.Sc./M.Sc. or equivalent) to develop realistic computer graphics environments for our virtual surgery systems. If you like creating cool graphics applications, and are good at finding non-standard solutions to non-standard problems, you are the right person. Experience with SGI/UNIX workstations and one or more of the following is required: OpenGL, Performer, or Inventor. In addition, experience with VRML and game graphics packages such as Direct3D and RenderWare is a plus. 3. Electrical/computer engineer We are looking for a creative, problem-solving individual (B.Sc./M.Sc.) to develop software interfaces for force-feedback devices, as well as other hardware used in our virtual surgery systems. You will also contribute to the design of these devices in collaboration with our hardware partners. You should have experience in working with device drivers and hardware. Hardware interfacing in UNIX/SGI a plus. You should be familiar with various interface cards - VME to PCI - and their individual quirks. Experience with force-feedback devices or robotics would be a definite plus. 4. System Administrator We are looking for a cool-headed individual to manage our multi-platform environment. If you are a quick - but methodical - problem-solver, can adapt in a fast-paced environment and at the same time keep calm, you are the right person. The network includes several SGI/UNIX systems, PCs (Win95/NT), Macs, an FTP/Web server and a firewall. Responsibilities include updating SGI software and OS, and maintaining shared file systems, internal and external networks, email, and DNS. Travel a strong possibility for shows and demonstrations. To keep things running smoothly, experience with SGIs a must, NFS/NIS, firewalls, and network proxies a plus. Please respond by email: jobs@ht.com or fax: (301) 984-2104 -- ,,, (o o) -------------------------oOO--(_)--OOo------------------------------- Morten Bro-Nielsen, PhD E-mail: bro@ht.com Senior Scientist HT WWW: http://www.ht.com/ HT Medical, Inc. Private: http://www.imm.dtu.dk/~bro 6001 Montrose Road, Suite 902 http://www.imm.dtu.dk/~mvox Rockville, MD 20852, USA Phone: +1(301)984-3706 Fax: ..-2104 -------------- Creator of Surgery Simulation Systems ---------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 09:31:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA08754; Wed, 29 Jan 1997 09:30:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA08738; Wed, 29 Jan 1997 09:30:08 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA24381; Wed, 29 Jan 1997 09:29:57 -0800 Received: from wolfe.net (mail1.wolfe.net [204.157.98.11]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA16076 for ; Wed, 29 Jan 1997 09:29:57 -0800 Received: from gonzo.wolfenet.com (moore@gonzo.wolfenet.com [204.157.98.2]) by wolfe.net (8.8.0/8.8.0) with ESMTP id JAA03066; Wed, 29 Jan 1997 09:31:40 -0800 (PST) From: Timothy Moore Received: (from moore@localhost) by gonzo.wolfenet.com (8.8.3/8.7) id JAA00242; Wed, 29 Jan 1997 09:29:51 -0800 (PST) Date: Wed, 29 Jan 1997 09:29:51 -0800 (PST) Message-Id: <199701291729.JAA00242@gonzo.wolfenet.com> To: ebrisson@lobster.bu.edu CC: info-performer@sgi.com In-reply-to: Erik Brisson's message of Wed, 29 Jan 97 10:16:40 EST <199701291516.KAA128016@lobster.bu.edu> Subject: Re: pfLightColor() Unknown color token Status: O From: Erik Brisson Date: Wed, 29 Jan 97 10:16:40 EST I get these errors: PF Warning/Usage: pfLightColor() Unknown color token 4608. PF Warning/Usage: pfLightColor() Unknown color token 4609. PF Warning/Usage: pfLightColor() Unknown color token 4610. >From these calls: camlightsource = pfNewLSource(); pfLSourceColor(camlightsource, PFLT_AMBIENT, 0.2f, 0.2f, 0.2f); pfLSourceColor(camlightsource, PFLT_DIFFUSE, 1.0f, 1.0f, 1.0f); pfLSourceColor(camlightsource, PFLT_SPECULAR,1.0f, 1.0f, 1.0f); Can anyone tell me what I am doing wrong? Not getting some shared library, perhaps? (In case that is the problem, here is my link line: It looks like you're including OpenGL header files in your IrisGL application. Do you have IRISGL #defined? cc -O -32 -o buidesk buideskMain.o -L/usr/local/CAVE/lib -lpfcave_igl -L/usr/lib -L/usr/lib/libpfdb -L/lib -all -ignore_unresolved -lpf_igl -lpfdu_igl -lpfui -lpfutil_igl -limage -lfm -lgl -lXm -lXt -lXirisw -lfpe -lXmu -lX11 -lm -lmalloc -lC P.s. I did find a possible clue: parameter ( GL_AMBIENT = 4608 ) in /usr/include/GL/fgl.h. But this seems a strange place to be getting stuff from. in GL/gl.h GL_AMBIENT is defined to be 0x1200 which equals... 4608. Tim ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 09:34:24 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA08799; Wed, 29 Jan 1997 09:33:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA08783; Wed, 29 Jan 1997 09:33:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA24753; Wed, 29 Jan 1997 09:33:04 -0800 Received: from wolfe.net (mail1.wolfe.net [204.157.98.11]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA17275; Wed, 29 Jan 1997 09:33:03 -0800 Received: from gonzo.wolfenet.com (moore@gonzo.wolfenet.com [204.157.98.2]) by wolfe.net (8.8.0/8.8.0) with ESMTP id JAA03602; Wed, 29 Jan 1997 09:34:38 -0800 (PST) From: Timothy Moore Received: (from moore@localhost) by gonzo.wolfenet.com (8.8.3/8.7) id JAA00797; Wed, 29 Jan 1997 09:32:48 -0800 (PST) Date: Wed, 29 Jan 1997 09:32:48 -0800 (PST) Message-Id: <199701291732.JAA00797@gonzo.wolfenet.com> To: brian@sgi.com CC: bwasileski@mdc.com, info-performer@sgi.com In-reply-to: Brian Furtaw's message of Wed, 29 Jan 1997 10:10:11 -0500 <9701291010.ZM20653@hotsauce.clubfed.sgi.com> Subject: Re: draw times Status: O Date: Wed, 29 Jan 1997 10:10:11 -0500 From: brian@sgi.com (Brian Furtaw) On Jan 29, 7:38am, Bryan Wasileski wrote: This is just a suggestion I don't have any SGI benchmark numbers to give you. I guess the big hangup with drawing multiple channels is the gfx context switch plus you have to download the textures all over again. Uh, I don't think multiple channels necessarily cause graphics context switches and multiple texture downloads. Multiple windows do, though. Possibly full of it, Tim ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 10:29:25 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA09126; Wed, 29 Jan 1997 10:27:50 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA09110; Wed, 29 Jan 1997 10:27:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA29419; Wed, 29 Jan 1997 10:27:38 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA02734 for ; Wed, 29 Jan 1997 10:27:33 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA14908; Wed, 29 Jan 97 12:25:01 -0500 Date: Wed, 29 Jan 97 12:25:01 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701291725.AA14908@mred.bgm.link.com> To: info-performer@sgi.com Subject: RE: NTSC output from iR. Status: O I said: > Anybody out there playing with the NTSC encoder on Inf.Reality? > > I'm trying to videotape some of my normal 1280x1024/60Hz simulations. > > When I set up ircombine on my iR box for 1280x1024 (60Hz) on one > DG-2 output and NTSC on the other, I see an occasional horizontal > discontinuity creeping up the NTSC display - no such artifact > appears on the regular display. Well, I think I now understand the problem fully (thanks to some help from an old friend at Philips Research)... NTSC *isn't* 60Hz - it's 59.96Hz, however, your normal SGI CRT *is* exactly 60.00000000Hz. Hence, the buffer swap signal in the simulation switches the double buffers at 60Hz - which is not in sync with the NTSC vertical retrace - so you get a buffer swap partway down the screen. Now all we need is an SGI Guru to tell us either: 1) How to get Performer to swap the double buffer in sync with the NTSC frame rate. or... 2) How to get the NTSC encoder to run at exactly 60Hz. (Admittedly if we did this, it wouldn't be perfectly timed to the NTSC standard - but a VCR wouldn't care about that). Why isn't NTSC 60Hz? Well - that's an interesting subject in it's own right. I think the story boils down to the fact that good old monochrome television (back when "I Love Lucy" wasn't a rerun) *was* 60Hz, in order to avoid nasty interactions with 60Hz wall socket power frequencies. When colour came along, they needed some extra data within each frame - and to avoid increasing the bandwidth needed in the transmitters, they dropped the frame rate to 59.96Hz (ugh!) and presumably just hoped that electrical isolation within the TV was good enough to avoid interactions with the 60Hz power. ...and these are the same people who are defining the wonderous (NOT!) new HDTV standards. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 11:18:11 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA09358; Wed, 29 Jan 1997 11:15:17 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA09340; Wed, 29 Jan 1997 11:15:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA03560; Wed, 29 Jan 1997 11:15:06 -0800 Received: from cinet (cinet.fcr.es [194.140.128.70]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14307 for ; Wed, 29 Jan 1997 11:14:56 -0800 Received: from oscar by cinet via ESMTP (951211.SGI.8.6.12.PATCH1042/940406.SGI) for id UAA03447; Wed, 29 Jan 1997 20:11:08 +0100 Message-Id: <199701291911.UAA03447@cinet> From: "=?ISO-8859-1?Q?=D3scar_S.?=" <0781.ct@cinet.fcr.es> To: "=?ISO-8859-1?Q?Info_T=E9cnica_Performer?=" Subject: New Proyect Date: Wed, 29 Jan 1997 20:17:40 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Status: O Hi! I'm a student that finish 5º of electronics and I like to make my proyect with the Performer. Please Can you give me any ideas about a new interested proyect? Thanks! Oscar ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 11:24:13 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA09419; Wed, 29 Jan 1997 11:22:33 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA09403; Wed, 29 Jan 1997 11:22:32 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA04372; Wed, 29 Jan 1997 11:22:21 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16372; Wed, 29 Jan 1997 11:22:19 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA21475; Wed, 29 Jan 1997 14:14:59 -0500 Date: Wed, 29 Jan 1997 14:14:59 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701291414.ZM21474@hotsauce.clubfed.sgi.com> In-Reply-To: Timothy Moore "Re: draw times" (Jan 29, 9:32am) References: <199701291732.JAA00797@gonzo.wolfenet.com> Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Timothy Moore , brian@sgi.com Subject: Re: draw times Cc: bwasileski@mdc.com, info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Jan 29, 9:32am, Timothy Moore wrote: > Subject: Re: draw times > Date: Wed, 29 Jan 1997 10:10:11 -0500 > From: brian@sgi.com (Brian Furtaw) > > On Jan 29, 7:38am, Bryan Wasileski wrote: > > This is just a suggestion I don't have any SGI benchmark numbers to > give you. I guess the big hangup with drawing multiple channels is > the gfx context switch plus you have to download the textures all > over again. > > Uh, I don't think multiple channels necessarily cause graphics context > switches and multiple texture downloads. Multiple windows do, though. > > Possibly full of it, > Tim >-- End of excerpt from Timothy Moore See this is what you get when you guess, I just assumed multiple channels required multiple contexts, now I really don't know why it takes longer. Brian -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 11:18:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA09374; Wed, 29 Jan 1997 11:15:18 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA09353; Wed, 29 Jan 1997 11:15:17 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA03563; Wed, 29 Jan 1997 11:15:06 -0800 Received: from cinet (cinet.fcr.es [194.140.128.70]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14298 for ; Wed, 29 Jan 1997 11:14:54 -0800 Received: from oscar by cinet via ESMTP (951211.SGI.8.6.12.PATCH1042/940406.SGI) for id UAA03445; Wed, 29 Jan 1997 20:11:06 +0100 Message-Id: <199701291911.UAA03445@cinet> From: "=?ISO-8859-1?Q?=D3scar_S.?=" <0781.ct@cinet.fcr.es> To: "=?ISO-8859-1?Q?Info_T=E9cnica_Performer?=" Subject: Reference pages Date: Wed, 29 Jan 1997 20:09:34 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: O Hello! In the IRIS Performer Programmer's Guide talk about reference pages to get more information on one instrucction. Where I can find this reference pages? Thanks Oscar ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 11:40:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA09517; Wed, 29 Jan 1997 11:38:20 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA09501; Wed, 29 Jan 1997 11:38:19 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA06070; Wed, 29 Jan 1997 11:38:04 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20760 for ; Wed, 29 Jan 1997 11:38:04 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA05588; Wed, 29 Jan 1997 11:38:02 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA01654; Wed, 29 Jan 1997 11:38:01 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701291938.LAA01654@remi.asd.sgi.com> Subject: Re: NTSC output from iR. To: steve@mred.bgm.link.com (Steve Baker) Date: Wed, 29 Jan 1997 11:38:01 -0800 (PST) Cc: info-performer@sgi.com In-Reply-To: <9701291725.AA14908@mred.bgm.link.com> from "Steve Baker" at Jan 29, 97 12:25:01 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 2430 Status: O Steve Baker wrote: > > Anybody out there playing with the NTSC encoder on Inf.Reality? > > I'm trying to videotape some of my normal 1280x1024/60Hz simulations. > > When I set up ircombine on my iR box for 1280x1024 (60Hz) on one > DG-2 output and NTSC on the other, I see an occasional horizontal > discontinuity creeping up the NTSC display - no such artifact > appears on the regular display. > > .................... > > Well, I think I now understand the problem fully (thanks to some help from an > old friend at Philips Research)... > > NTSC *isn't* 60Hz - it's 59.96Hz, however, your normal SGI CRT > *is* exactly 60.00000000Hz. Hence, the buffer swap signal in the simulation > switches the double buffers at 60Hz - which is not in sync with the > NTSC vertical retrace - so you get a buffer swap partway down the screen. > > Now all we need is an SGI Guru to tell us either: > > 1) How to get Performer to swap the double buffer in sync with the > NTSC frame rate. > > or... > > 2) How to get the NTSC encoder to run at exactly 60Hz. (Admittedly if we > did this, it wouldn't be perfectly timed to the NTSC standard - but > a VCR wouldn't care about that). Ed hutchins pointed to me that since patch1355 the NTSC frequency is quietly coerced to 60Hz. But you should tell ircombine what is the source channel for the NTSC output (knowned as vampire mode) by selecting the source channel in the encode attributes of ircombine. This also has the advantage to let you map the NTSC video to the full frame buffer, instead of being limited to 640x486. > > Why isn't NTSC 60Hz? Well - that's an interesting subject in it's > own right. I think the story boils down to the fact that good old > monochrome television (back when "I Love Lucy" wasn't a rerun) *was* > 60Hz, in order to avoid nasty interactions with 60Hz wall socket > power frequencies. > > When colour came along, they needed some extra data within each > frame - and to avoid increasing the bandwidth needed in the > transmitters, they dropped the frame rate to 59.96Hz (ugh!) and > presumably just hoped that electrical isolation within the TV > was good enough to avoid interactions with the 60Hz power. > Is it the difference between the two NTSCs ? Japan vs Us ? _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 11:58:26 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA09673; Wed, 29 Jan 1997 11:57:05 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA09657; Wed, 29 Jan 1997 11:57:04 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA07575; Wed, 29 Jan 1997 11:56:54 -0800 Received: from nvsgi1.netvision.net.il (nvsgi1.NetVision.net.il [194.90.1.31]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA25955 for ; Wed, 29 Jan 1997 11:56:50 -0800 Received: from EFRAT.netvision.net.il (ts011p6.pop9a.netvision.net.il [194.90.11.206]) by nvsgi1.netvision.net.il (8.7.5/8.7.3) with SMTP id VAA26043; Wed, 29 Jan 1997 21:56:20 +0200 (IST) Message-ID: <32F03767.658E@netvision.net.il> Date: Wed, 29 Jan 1997 21:53:43 -0800 From: Moshe Nissim Reply-To: orad_u@netvision.net.il Organization: Orad Hi-Tec Systems X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Steve Baker CC: info-performer@sgi.com Subject: Re: NTSC output from iR. References: <9701291725.AA14908@mred.bgm.link.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Steve Baker wrote: > > I said: > > > Anybody out there playing with the NTSC encoder on Inf.Reality? > > > > I'm trying to videotape some of my normal 1280x1024/60Hz simulations. > > > > When I set up ircombine on my iR box for 1280x1024 (60Hz) on one > > DG-2 output and NTSC on the other, I see an occasional horizontal > > discontinuity creeping up the NTSC display - no such artifact > > appears on the regular display. > > Well, I think I now understand the problem fully (thanks to some help from an > old friend at Philips Research)... > > NTSC *isn't* 60Hz - it's 59.96Hz, however, your normal SGI CRT > *is* exactly 60.00000000Hz. Hence, the buffer swap signal in the simulation > switches the double buffers at 60Hz - which is not in sync with the > NTSC vertical retrace - so you get a buffer swap partway down the screen. > True but, I think the DG4 absolutely requires that all channels run at the same swap rate. So don't beleive everything ircombine says about frequencies... Anyway, you can "slave" channel 1 to channel 0, wouldn't that guarantee it will see the exact pixel-stream as channel 0 ( the CRT )? Moshe Nissim Orad Hi-Tec Systems ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 12:05:24 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA09755; Wed, 29 Jan 1997 12:04:17 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA09739; Wed, 29 Jan 1997 12:04:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA08184; Wed, 29 Jan 1997 12:04:06 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27457; Wed, 29 Jan 1997 12:03:54 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id UAA13231; Wed, 29 Jan 1997 20:03:48 GMT From: "Angus Dorbie" Message-Id: <9701292003.ZM13229@bitch.reading.sgi.com> Date: Wed, 29 Jan 1997 20:03:47 +0000 In-Reply-To: "=?ISO-8859-1?Q?=D3scar_S.?=" <0781.ct@cinet.fcr.es> "Reference pages" (Jan 29, 8:09pm) References: <199701291911.UAA03445@cinet> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com, "=?ISO-8859-1?Q?=D3scar_S.?=" <0781.ct@cinet.fcr.es> Subject: Re: Reference pages Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Install the manuals and type: man pfWhateverIWant or install the 'books' with the performer release and use 'insight' to read the books online. For a quick start look in /usr/share/Performer/src/* for working C & C++ examples. I recommend 'complex.C', it isn't actually that complex and does the right things. There is a bug in the function which updates the eye though which closes a couple of brackets in the wrong place and so includes the pitch angle in the heading direction calculations. This is easily fixed. Cheers, Angus. On Jan 29, 8:09pm, =?ISO-8859-1?Q?=D3scar_S.?= wrote: > Subject: Reference pages > Hello! > > In the IRIS Performer Programmer's Guide talk about reference pages to get more > information on one instrucction. > > Where I can find this reference pages? > > Thanks > > Oscar > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from =?ISO-8859-1?Q?=D3scar_S.?= ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 12:14:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id MAA09849; Wed, 29 Jan 1997 12:12:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id MAA09833; Wed, 29 Jan 1997 12:12:56 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA08751; Wed, 29 Jan 1997 12:12:45 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA29942; Wed, 29 Jan 1997 12:12:41 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id UAA13249; Wed, 29 Jan 1997 20:12:33 GMT From: "Angus Dorbie" Message-Id: <9701292012.ZM13245@bitch.reading.sgi.com> Date: Wed, 29 Jan 1997 20:12:33 +0000 In-Reply-To: =?iso-8859-1?Q?remi=40remi=2Easd=2Esgi=2Ecom_=28R=E9mi_Arnaud?= =?iso-8859-1?Q?=29 _______=22Re=3A_NTSC_output_from_iR=2E=22_=28Jan_29=2C_11=3A38am=29?= References: <199701291938.LAA01654@remi.asd.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: remi@remi.asd.sgi.com (=?iso-8859-1?Q?R=E9mi_Arnaud?=), steve@mred.bgm.link.com (Steve Baker) Subject: Re: NTSC output from iR. Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19701292012.ZM13245.reading.sgi.com" Status: O --PART-BOUNDARY=.19701292012.ZM13245.reading.sgi.com Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u On Jan 29, 11:38am, R=E9mi Arnaud wrote: > > Ed hutchins pointed to me that since patch1355 the NTSC frequency is > quietly coerced to 60Hz. > > But you should tell ircombine what is the source channel for the NTSC = output > (knowned as vampire mode) by selecting the source channel in the encod= e > attributes of ircombine. > > This also has the advantage to let you map the NTSC video to the full > frame buffer, instead of being limited to 640x486. I expect genlocking to a house sync if you have one will drag the whole thing back into line if the frame rate bothers you. Cheers, Angus. --PART-BOUNDARY=.19701292012.ZM13245.reading.sgi.com-- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 13:11:46 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA10310; Wed, 29 Jan 1997 13:10:25 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA10294; Wed, 29 Jan 1997 13:10:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA13323; Wed, 29 Jan 1997 13:10:14 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA12838 for ; Wed, 29 Jan 1997 13:09:53 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Wed, 29 Jan 1997 15:55:58 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Wed, 29 Jan 1997 15:55:57 Eastern Standard Time Message-ID: <32EFBED4.381B@ivex3d.com> Date: Wed, 29 Jan 1997 16:19:16 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Rain / Thunderstorms ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi, Can anyone give me good pointers to implementing Rain/Thunderstorms using Performer ? I did read a posting on the archive sometime back. Did anybody try to implement this and if so how did it work . If I remember correctly, this implementation was suggesting using overlay planes to draw pixels at random. We intend to use the overlay planes for something else. So, I was just wondering if there is a better approach to this issue. Thanks in advance Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 13:18:57 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA10339; Wed, 29 Jan 1997 13:17:45 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA10323; Wed, 29 Jan 1997 13:17:44 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA14010; Wed, 29 Jan 1997 13:17:33 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA14872 for ; Wed, 29 Jan 1997 13:17:31 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.com id VAA13332; Wed, 29 Jan 1997 21:17:27 GMT From: "Angus Dorbie" Message-Id: <9701292117.ZM13330@bitch.reading.sgi.com> Date: Wed, 29 Jan 1997 21:17:27 +0000 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com Subject: (Fwd) Re: (Fwd) RE: NTSC output from iR. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O A response from Paul Spencer, our multimedia guru in residence. Cheers, Angus. ---- Forwarded mail from spencer@hailwood.asd.sgi.com (Paul Spencer) Reply-To: spencer@hailwood.asd.sgi.com (Paul Spencer) From: spencer@hailwood.asd.sgi.com (Paul Spencer) Subject: Re: (Fwd) RE: NTSC output from iR. Date: 29 Jan 1997 20:57:26 GMT > > NTSC *isn't* 60Hz - it's 59.96Hz, Actually 59.94 Hz. > however, your normal SGI CRT > *is* exactly 60.00000000Hz. Well, not really. Nominally, it is 60 Hz; but it certainly isn't that precise. We drive it off a normal crystal; on recent DG boards we use a 10 ppm tolerance part. That means the 107.352 MHz dot clock of 1280x1024_60 can vary by +/- 107 Hz, so you get a range of 59.99994 to 60.00006 Hz. The exact frequency will vary from board to board, and vary with temperature, and vary with line voltage; but it is *not* exactly 60 Hz. > Hence, the buffer swap signal in the simulation > switches the double buffers at 60Hz - which is not in sync with the > NTSC vertical retrace - so you get a buffer swap partway down the screen. Yes, precisely. This same effect will happen when you have two graphics heads (either in the same system, or two separate systems); although since the base frequencies are closer together, the two displays will drift with respect to each other much more slowly. > 1) How to get Performer to swap the double buffer in sync with the > NTSC frame rate. Genlock/framelock the two systems together! This is exactly the problem that genlock is for; getting two video displays to match up. > 2) How to get the NTSC encoder to run at exactly 60Hz. (Admittedly if we > did this, it wouldn't be perfectly timed to the NTSC standard - but > a VCR wouldn't care about that). You can't do this and call it NTSC; and it wouldn't work on some equipment anyway. Besides, you'd *still* have the same problem of having two separate crystals running at two very slightly different frequencies. There is a second problem that you don't bring up. Suppose that we had a graphics head slaved to an atomic clock, running at *PRECISELY* 59.94 Hz; and we had the NTSC output slaved to the atomic clock as well, at *PRECISELY* 59.94 Hz. You would still have a technical issue; the vertical retrace interval of the two video outputs would not be aligned. There would be no relative drift of the two; but the NTSC output could still have a tear in it. This second problem is also fixed by genlocking/framelocking the two together; this will assure that the two are running at the same frequency, and have their vertical intervals aligned. ....paul -- Paul Spencer Silicon Graphics Advanced Systems Division spencer@sgi.com Mountain View, California ---End of forwarded mail from spencer@hailwood.asd.sgi.com (Paul Spencer) ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 13:25:54 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA10364; Wed, 29 Jan 1997 13:24:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA10348; Wed, 29 Jan 1997 13:24:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA14532; Wed, 29 Jan 1997 13:24:23 -0800 Received: from crdems.ge.com (crdems.GE.COM [192.35.44.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA16229 for ; Wed, 29 Jan 1997 13:24:20 -0800 Received: from bart.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA21323; Wed, 29 Jan 97 16:16:31 -0500 Received: from bart by bart.crd.ge.com (SMI-8.6/GE-CRD Standard Sendmail Version S1.5)id QAA17538; Wed, 29 Jan 1997 16:16:37 -0500 Sender: volpe@ash.crd.ge.com Message-Id: <32EFBE35.3887@ash.crd.ge.com> Date: Wed, 29 Jan 1997 16:16:37 -0500 From: Christopher R Volpe Organization: GE Corporate Research & Development, Schenectady, NY X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: info-performer@sgi.com Subject: multi-channel performer setup using ircombine Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi- I am *trying* to use ircombine to do something useful on my onyx iR. I want a performer application I'm developing to be able to draw up to five channels in five viewports within a window, and have the physical displays mapped onto each of the viewports. At the moment, I have a DG with two outputs, so I'm just trying to set up the framebuffer for two channels. No matter what I do, ircombine complains about an integer parameter out of range (an X error). What I want to do is configure the framebuffer to have a size of 1280x480. Channels 0 and 1 should each have a size of 640x480 with 60Hz refresh rate, and channel 1 should have an x offset of 640. Basically, two VGA-resolution channels adjacent to each other in the framebuffer. The total resolution is smaller than the existing 1280x1024, so I don't think I'm asking for anything beyond the capabilities of the hardware. However, nothing that I have tried has worked. Anyone know what I am missing? thanks, Chris -- Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr@crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 14:09:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA10642; Wed, 29 Jan 1997 14:07:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA10626; Wed, 29 Jan 1997 14:07:56 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA18258; Wed, 29 Jan 1997 14:07:45 -0800 Received: from yacko.csd.sgi.com ([150.166.145.94]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA26284 for ; Wed, 29 Jan 1997 14:07:44 -0800 Received: from localhost by yacko.csd.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id OAA07489; Wed, 29 Jan 1997 14:07:54 -0800 Message-Id: <199701292207.OAA07489@yacko.csd.sgi.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Christopher R Volpe cc: info-performer@sgi.com Subject: Re: multi-channel performer setup using ircombine In-reply-to: Your message of "Wed, 29 Jan 1997 16:16:37 EST." <32EFBE35.3887@ash.crd.ge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 14:07:53 -0800 From: Eric Kunze Status: O Chris, Probably what is happening is that you are not running ircombine as root. If you don't run as root, everything will appear to work fine until you try to download the combination at which time you get a BadValue error. There is a bug filed to make this error message report a useful error, instead of BadValue. Eric > Hi- > I am *trying* to use ircombine to do something useful on my onyx iR. I > want a performer application I'm developing to be able to draw up to > five channels in five viewports within a window, and have the physical > displays mapped onto each of the viewports. At the moment, I have a DG > with two outputs, so I'm just trying to set up the framebuffer for two > channels. No matter what I do, ircombine complains about an integer > parameter out of range (an X error). What I want to do is configure the > framebuffer to have a size of 1280x480. Channels 0 and 1 should each > have a size of 640x480 with 60Hz refresh rate, and channel 1 should have > an x offset of 640. Basically, two VGA-resolution channels adjacent to > each other in the framebuffer. The total resolution is smaller than the > existing 1280x1024, so I don't think I'm asking for anything beyond the > capabilities of the hardware. However, nothing that I have tried has > worked. Anyone know what I am missing? > > thanks, > Chris > -- > > Chris Volpe Phone: (518) 387-7766 > GE Corporate R&D Fax: (518) 387-6560 > PO Box 8 Email: volpecr@crd.ge.com > Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 14:37:25 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA10999; Wed, 29 Jan 1997 14:36:03 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA10983; Wed, 29 Jan 1997 14:36:03 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA20626; Wed, 29 Jan 1997 14:35:52 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA03037 for ; Wed, 29 Jan 1997 14:35:51 -0800 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id OAA17888; Wed, 29 Jan 1997 14:35:50 -0800 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id OAA05311; Wed, 29 Jan 1997 14:35:49 -0800 From: remi@remi.asd.sgi.com (Rémi Arnaud) Message-Id: <199701292235.OAA05311@remi.asd.sgi.com> Subject: Re: multi-channel performer setup using ircombine To: volpe@ash.crd.ge.com (Christopher R Volpe) Date: Wed, 29 Jan 1997 14:35:49 -0800 (PST) Cc: info-performer@sgi.com In-Reply-To: <32EFBE35.3887@ash.crd.ge.com> from "Christopher R Volpe" at Jan 29, 97 04:16:37 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1371 Status: O Christopher R Volpe wrote: > > Hi- > I am *trying* to use ircombine to do something useful on my onyx iR. I > want a performer application I'm developing to be able to draw up to > five channels in five viewports within a window, and have the physical > displays mapped onto each of the viewports. At the moment, I have a DG > with two outputs, so I'm just trying to set up the framebuffer for two > channels. No matter what I do, ircombine complains about an integer > parameter out of range (an X error). What I want to do is configure the > framebuffer to have a size of 1280x480. Channels 0 and 1 should each > have a size of 640x480 with 60Hz refresh rate, and channel 1 should have > an x offset of 640. Basically, two VGA-resolution channels adjacent to > each other in the framebuffer. The total resolution is smaller than the > existing 1280x1024, so I don't think I'm asking for anything beyond the > capabilities of the hardware. However, nothing that I have tried has > worked. Anyone know what I am missing? > Selecting 640x480_60.vfo for channel 0 and channel 1, then moving the origin to 640 for the channel 1 works perfectly. What is the Xerror you have ? Do you run ircombine on IR ? _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 15:39:19 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA11435; Wed, 29 Jan 1997 15:37:50 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA11419; Wed, 29 Jan 1997 15:37:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA25341; Wed, 29 Jan 1997 15:37:38 -0800 Received: from crdems.ge.com (crdems.GE.COM [192.35.44.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA17453 for ; Wed, 29 Jan 1997 15:37:34 -0800 Received: from bart.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA24722; Wed, 29 Jan 97 18:36:13 -0500 Received: from bart by bart.crd.ge.com (SMI-8.6/GE-CRD Standard Sendmail Version S1.5)id SAA20035; Wed, 29 Jan 1997 18:36:21 -0500 Sender: volpe@ash.crd.ge.com Message-Id: <32EFDEF4.1A22@ash.crd.ge.com> Date: Wed, 29 Jan 1997 18:36:20 -0500 From: Christopher R Volpe Organization: GE Corporate Research & Development, Schenectady, NY X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: everyone@ash.crd.ge.com Cc: info-performer@sgi.com Subject: Re: multi-channel performer setup using ircombine References: <32EFBE35.3887@ash.crd.ge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Thank you all for your help. A couple of you suggested that I should be root when downloading a new combination, and you were right! That was the problem. -Chris -- Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr@crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 15:51:23 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA11550; Wed, 29 Jan 1997 15:49:45 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA11534; Wed, 29 Jan 1997 15:49:44 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA26213; Wed, 29 Jan 1997 15:49:32 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19955 for ; Wed, 29 Jan 1997 15:49:32 -0800 Received: from bugs.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id PAA23882; Wed, 29 Jan 1997 15:49:27 -0800 Received: by bugs.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id PAA03465; Wed, 29 Jan 1997 15:49:25 -0800 Date: Wed, 29 Jan 1997 15:49:24 -0800 (PST) From: Trina Roy To: Brian Corrie cc: info-performer@sgi.com Subject: Re: [Q] Onyx2 Reality for VR??? In-Reply-To: <199701280012.LAA09323@silver.anu.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi - The Onyx2 Reality should be sufficient to run an ImmersaDesk. I dont want to say that it does absolutely for sure unless I could test it myself (which could happen in a month or so if need be), but the I-Desk can run off an RE and an Impact as well so the Onyx2 Reality should be fine. Keep in mind though the impact that it will have on the applications running on the I-Desk. Having an application work on the I-Desk is one thing, having it run fast enough and accurately enough visually to sustain the frame rate needed to maintain immersion (at least 10 Hz) is an entirely different story (remember you're rendering each frame twice, once per eye for stereo). Without knowing more details about what you'll be running it's hard for me to make that call. But it sounds like you have the right information about the differences between the two systems so you can make a pretty educated judgement call. Good luck!! -Trina ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ trina m. roy trina@sgi.com scientific visualization silicon graphics inc. 415.933.6395 mountain view, ca On Tue, 28 Jan 1997, Brian Corrie wrote: > > G'day all, > > I have what may seem like a silly question, but I am a bit of a newbie to high > end SGI graphics systems and this seems like the place to clarify some things. > Sorry about the length of this email, but I thought it best to give as much > info as possible to avoid confusion. We are looking at purchasing an > Immersadesk VR system and an Onyx2 Reality Deskside system to drive it. The > Immersadesk is a drafting sized immersive VR system with stereo viewing and > both head and hand tracking. Up until recently, these devices were typically > driven by a Onyx RE or Onyx IR system, usually with 1 pipe. Given the > previous statement, it appears obvious that the Onyx2 Reality Deskside system > would be more than capable of driving the Immersadesk. > > The problem (and my question) arises from the fact that the Onyx2 Reality is a > scaled down version of the Onyx2 IR and I am not familiar enough with high end > SGI hardware (nor familiar enough with the VR requirements imposed on these > machines) to determine whether or not this 'scaling down' is going to impact > drastically on opearting the Immersadesk... I am unfortunately in the > position that I have to advise the powers that be on whether the machine will > be capable of driving the Immeradesk successfully, so I need to find these > things out... > > The main potential problem is the configuartion of the frame buffer. The > Onyx2 Reality has an RM8 with 40 MB of frame buffer as standard, which is half > the frame buffer of what the IR RM7s have (80 MB). To drive the Immersadesk, > we require 1280x1024 stereo, double buffered rendering. With 40 MB of frame > buffer at 1280x1024 pixels, this gives us 256 bits/pixel. My problem is that > I do not know enough about the frame buffer modes of the IR pipes to be sure > that we are not going to lose some capabability that we require due to having > "only" 256 bits/pixel. If we are using 12bit RGBA pixels with stereo double > buffering my calculations tell me that we need 4 x 48 bits (for left/front, > right/front, left/back, and right/back images) and we will say 23 bits for > depth. This leaves us with just over 40 bits/pxel remaining, which seems like > more than enough... > > So my question is, am I missing anything here???? Our SGI reps here in > Canberra have expressed some concern that this may not be enough. > Specifically, they have stated that there will be no anti-aliasing available > (only 1 sample per pixel). I have the Onyx2 Technical Report and it mentions > the Accumulation Buffer, stencils, overlays, tags, and things like LA32, LA16, > and MS Color (see page 20 of the Onyx2 Tech Report) without really defining > what they are and how they are used. What I need to know in what > circumstances are they used and how many of my valuable bits/pixel are they > going to chew up? I am also interested in finding out if any of these are > essential in driving a system like the Immersadesk and if so, will my 40 MB of > frame buffer be enough... (Gee, I am really starting to sound possesive about > that good ol' Onyx2 Reality box, I wonder if they will let me have it in my > office 8-) > > I am hoping that someone on this list is both an Onyx2 and an Immersadesk > user, as that is really what I need to answer my questions. Of course any > input from anyone would be HUGELY appreciated!!!! > > Thanks in advance, > > Brian Corrie. > > > > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ trina m. roy trina@sgi.com scientific visualization silicon graphics inc. 415.933.6395 mountain view, ca ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 17:50:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA12187; Wed, 29 Jan 1997 17:48:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA12171; Wed, 29 Jan 1997 17:48:47 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA04544; Wed, 29 Jan 1997 17:48:36 -0800 Received: from llogic.com (llogic.com [198.168.83.173]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA14924 for ; Wed, 29 Jan 1997 17:48:32 -0800 Received: by llogic.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id UAA07184; Wed, 29 Jan 1997 20:51:44 -0800 From: fred@llogic.com (Frederic Francis) Message-Id: <199701300451.UAA07184@llogic.com> Subject: Job Opportunity in Montreal To: info-performer@sgi.com Date: Wed, 29 Jan 1997 20:51:22 -0800 (PST) X-Mailer: ELM [version 2.4 PL24 ME5a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 982 Status: O Job Offer: Senior Real-Time Graphics Programmer The Company Lateral Logic Inc is a young visual simulation company located in Montreal. Our primary focus is the development of visual simulation software for training, prototyping, and presentation with a strong emphasis on exact modeling of multi-body dynamics and accurate visuals. Job Requirements Lateral Logic is currently looking for an expert in the field of real-time graphics programming to join our core R&D team. Candidates should have extensive experience in all of the following: - OpenGL and IRIS Performer programming - C++, Object-Oriented programming methods - Graphical Database Optimization - Code optimization for multiprocessing Candidates should hold a B.Sc. (graduate degree preferred) and should have a strong background in mathematics and/or physics. Interested candidates should mail their resumes in ascii format to karsten@llogic.com. Regards, Karsten Howes Director of Research ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 18:50:23 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id SAA12408; Wed, 29 Jan 1997 18:47:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id SAA12392; Wed, 29 Jan 1997 18:47:25 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id SAA07514; Wed, 29 Jan 1997 18:47:15 -0800 Received: from discreet.qc.ca (discreet.qc.ca [198.168.76.29]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA24378 for ; Wed, 29 Jan 1997 18:47:08 -0800 Received: by gate.discreet.qc.ca id <47567>; Wed, 29 Jan 1997 22:09:25 -0500 Date: Wed, 29 Jan 1997 21:47:26 -0500 From: amit@discreet.qc.ca (Amit Parghi) Message-Id: <97Jan29.220925est.47567@gate.discreet.qc.ca> In-Reply-To: Trina Roy "Re: [Q] Onyx2 Reality for VR???" (Jan 29, 6:49pm) References: Reply-To: amit@discreet.qc.ca (Amit Parghi) X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Trina Roy , Brian Corrie Subject: Re: [Q] Onyx2 Reality for VR??? Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Brian Corrie writes: > > we require 1280x1024 stereo, double buffered rendering. ... > > My problem is that I do not know enough about the frame buffer modes > > of the IR pipes to be sure that we are not going to lose some > > capabability that we require due to having "only" 256 bits/pixel. As Brian Corrie suggested, some potential snags lie within the reduced frame buffer capacity and the available pixel formats using the 40MB raster manager (RM8) on the Reality pipe. However, as Trina Roy (hi, Trina!) pointed out, there is also a potential issue in the reduced geometry throughput on the GE boards ("reduced" relative to an InfiniteReality, that is). (Please note that I don't know much at all about the ImmersaDesk and I'm not addressing its requirements specifically here!) RM8: For double-buffered stereo at 1280x1024, my (somewhat preliminary) information tells me that you can get: - RGBA 12/12/12/12 pixels with either - 31 bits of Z and one bit of stencil; or - 32 bits of Z. - RGB 10/10/10 pixels (no destination alpha planes) with one of: - four-sample multisampling; - 32/32/32 accumulation; or - 1 aux, 32 bits of Z, and 8 bits of stencil. While it would be possible to add a second RM8 to the Reality pipe to get you back into the world of Medium pixel depth, you should compare the pricing of this option against a single-RM7 InfiniteReality system. GE: Due to the design of the GE on the Reality pipeline, you should expect its geometry throughput (as opposed to pixel-fill) to be approximately half of what you would get on an InfiniteReality pipeline. I think this is also made clear on the table on the back page of the Onyx2 short brochure (the little eight-page thing). Ciao, Amit -- AMIT PARGHI DISCREET LOGIC amit@discreet.com 5505, boul. St.-Laurent, bureau 5200 +1.514.272.0525 Montreal (Quebec) Canada H2T 1S6 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Wed Jan 29 23:07:22 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id XAA13354; Wed, 29 Jan 1997 23:05:59 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id XAA13338; Wed, 29 Jan 1997 23:05:59 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA17293; Wed, 29 Jan 1997 23:05:48 -0800 Received: from emerald.oz.net (emerald.oz.net [198.68.184.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA29043 for ; Wed, 29 Jan 1997 23:05:40 -0800 Received: from avi.oz.net (avi.oz.net [206.61.159.122]) by emerald.oz.net (8.8.4/8.7.3) with SMTP id XAA05886 for ; Wed, 29 Jan 1997 23:19:35 -0800 (PST) Date: Wed, 29 Jan 1997 23:19:35 -0800 (PST) Message-Id: <1.5.4.16.19970129230817.35e7009c@oz.net> X-Sender: avi@oz.net X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.com From: Avi Bar-Zeev Subject: JOBS: Seattle, VR, games Status: O >From my consulting business, I am aware of several Performer-related jobs in Seattle. I can't make any official offers myself but I can refer you to the appropriate person in the company. Presently, a company with whom I'm contracting needs another experienced Performer person for project-term work (about 1 year, possibly leading to permanent work). This person would be working with us to bring a cool real-time 3-D entertainment application to fruition. The company is small and frieldny and the project is well financed. And we're still in the design phase so now is the time to get on board. Time is of the essence. We may also need a shorter-term (on the order of 3-5 months) contract person to work on specific tasks such as writing a converter from Alias and/or Softimage to the run-time Performer structures, including animation and some other cool features. I can't guarantee the availability of this position since we may find an affordable 3rd party product for this task. But I'm betting that we'll have to develop this ourselves due to licensing expense. You can send your resume to me in confidence and I'll forward it directly to the company. Or, if you ask nicely, I'll give you the contact info (but I can't post it publicly). Thanks. Avi Avi Bar-Zeev -- "Every trip begins with a single misstep" A Real-Time 3-D Animated Character -- avi@oz.net http://www.oz.net/~avi WOLFCHILD-3D Consulting -- avi@wolfchild.com http://www.wolfchild.com/3d ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 30 10:19:04 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA14326; Thu, 30 Jan 1997 10:16:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA14310; Thu, 30 Jan 1997 10:16:46 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA16117; Thu, 30 Jan 1997 10:16:35 -0800 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA12068 for ; Thu, 30 Jan 1997 10:16:33 -0800 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA58138; Thu, 30 Jan 1997 13:10:22 -0500 Received: by eagle.cae.ca (950413.SGI.8.6.12/930416.SGI) id NAA04399; Thu, 30 Jan 1997 13:08:24 -0500 From: "Bernard Leclerc" Message-Id: <9701301308.ZM4397@eagle.cae.ca> Date: Thu, 30 Jan 1997 13:08:24 -0500 In-Reply-To: Bryan Wasileski "draw times" (Jan 29, 7:38am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Bryan Wasileski , info-performer@sgi.com Subject: Re: draw times Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Bryan Wasileski wrote: > Does any know how to deterministically calculate, in closed form, the > draw and cull times per viewport (channel) for a Performer app? > Some would say that deterministic and SGI don't usually go together > in the same sentence but I need to at least get close. The application I > have can have anywhere from 1-28 viewports and I need to know how > to pre-determine the frame rate as a function of the number of channels. Bryan, You'll can obtain deterministic results if your application is running with PFPHASE_LOCK, a non-degrading priority, on restricted and isolated CPUs. To ensure a valid timing on a per-channel basis, I suggest you use a DRAW callback similar to this one: void drawCB(pfChannel* chan, void* data) { chan->clear(); pfDraw(); glFinish(); // or simply finish() for IrisGL } I've tried this method of timing a channel independently from the others. It was suggested to me by Sharon Clay. Using this, you'll will obtain the exact time required to draw a particular channel. However, the overall throughput of your application may (and will) be reduced because every channel will block the DRAW process until the graphics pipeline is done drawing it. You won't benefit from the fact that a channel could start sending drawing commands to the pipe even if there are still graphics commands from the previous channel being processed inside the graphics subsystem. As for the CULL stage, you might consider using pfMultithread() to avoid being limited by the culling task when drawing 28 channels (man, that's a large number of views). Use pfFrameStats to obtain channel statistics. It is still possible to use pfChannel::drawStats() to draw the statistics panel inside the channel, but this will artificially increase the draw time of your channel. It is best to query the channel statistics from the APP process. Let us know how you're doing. You have an interesting problem. And I'm personaly interested with multi-channel applications. -- Bernard Leclerc CAE Electronics Ltd., 8585 Cote De Liesse Technical Leader Saint-Laurent, Quebec, Canada, H4L-4X4 3-D Graphics Applications tel: +1 514 341 2000 extension 2275 bleclerc@cae.ca fax: +1 514 340 5496 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 30 15:33:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id PAA15632; Thu, 30 Jan 1997 15:31:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id PAA15616; Thu, 30 Jan 1997 15:31:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA12856; Thu, 30 Jan 1997 15:31:46 -0800 Received: from nvg.aircrew.asu.edu (nvg.aircrew.asu.edu [198.60.190.110]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA26025 for ; Thu, 30 Jan 1997 15:31:37 -0800 Received: (from jeff@localhost) by nvg.aircrew.asu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA08172; Thu, 30 Jan 1997 16:34:34 -0700 From: "Jeff Clark" Message-Id: <9701301634.ZM8170@nvg.aircrew.asu.edu> Date: Thu, 30 Jan 1997 16:34:34 -0700 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Hardware questions... Cc: jclark@acm.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hello all, I am having difficulty implementing an "automatic gain control" for my Performer app. By AGC, I mean the gain on each pixel is a function of the average pixel value (intensity... one color component) of the current frame (or previous frame, Ill take what I can get). The correct result would be constant overall brightness on the display. I have implemented this in a handful of ways, but all of my attempts EITHER make it impossible to maintain my target frame rate OR don't provide an adequate AGC performance (I would like an AGC update rate of ~15Hz). There are two issues involved... here they are along with my attempted solutions: -Come up with an accurate (or approximate) average pixel value at ~15Hz: -approximate average pixel value using an ogl MINMAX histogram. This is fast, but the approximation is unsatisfactory. -approximate average pixel value by reading a slice of the framebuffer (glReadPixels()) every frame. i.e. if I read 32 lines/frame, I read the entire FB every 32 frames. So what I have is an "idea" of the brightness of the entire scene over the last 32 frames. This introduces temporal inaccuracies that are probably unacceptable. This actually looks pretty good a lot of the time, but sometimes not...i.e. in the worst case a bright source moves into the scene and has no effect on the AGC until 31 frames later. At 60 fps, this is an effective AGC update of 2 Hz... unacceptable. -approximate average pixel value using an ogl MINMAX histogram of one color component. The penalty to the draw process is comparable to using glReadPixels() and, therefore would be done in slices. Now I have the same problem as in the last attempt. -Apply a gain to the entire display based on the result of the first task above: -accumulate the 1 million pixels in the accumulation buffer and set the acbuf gain to the desired gain. This, of course, works fine but takes up so much draw that I don't have enough time to draw my scene at the complexity my simulation requires. SO, anybody have any ideas? (in the context of a 2 pipe iR with Sirius option) I am starting to think of ways to do it near the end or after the pipeline: On the gain issue, I wonder if there is a way to apply a gain (analog or digital) in the DG... i.e. near the DAC or gamma tables? In the ircombine channel attributes window I notice a GAIN field... is this a user register that can be changed at 15 Hz? (ASD, if this doesn't exist it sure would be a groovy thing to have!) Or, could the Sirius box apply a gain offline (and do so quickly) (sorry, I'm Siriusly ignorant)? On the pixel averaging issue, I wonder again if the Sirius can't be used? If not Sirius, I would think it would be posible to find a specialized hardware box that performs my AGC... i.e. a box that takes analog video and outputs a signal with constant overall brightness. Anybody ever heard of such a gizmo? Apologies: Im sorry that these aren't -exactly- Performer questions, but they are SGI questions... and this list is the best resource I know of. Besides, it is difficult to get this kind of info from support. Im sorry that this post is long enough to cut into your lunch break! Any responses will be GREATLY appreciated... I'm am beginning to run out of ideas. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 30 17:56:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id RAA16397; Thu, 30 Jan 1997 17:54:08 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA16381; Thu, 30 Jan 1997 17:54:07 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA21911; Thu, 30 Jan 1997 17:53:29 -0800 Received: from od.sri.com (od.sri.com [128.18.53.220]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA23917 for ; Thu, 30 Jan 1997 17:53:28 -0800 Received: by od.sri.com (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id RAA01583; Thu, 30 Jan 1997 17:53:08 -0800 From: "Nathaniel Bletter" Message-Id: <9701301753.ZM1581@od.sri.com> Date: Thu, 30 Jan 1997 17:53:07 -0800 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.com Subject: Mirror image rendering Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Does anyone know how to vertically flip the image produced by perfomer? I'm viewing the monitor in a mirror and need to compensate for it. I tried creating a perspective frustrum with the top < bottom, but this seems to reverse all the normals, messing up back face culling and lighting, and does weird things with the near and far clipping planes. I also tried to do a pfGetChanViewMat(chan, view); pfPostMultMat(view, inv); pfChanViewMat(chan, view); where inv = {1, 0, 0, 0, 0, -1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1} This seemed to do nothing. Any ideas? -- Nat Bletter SRI International nat@od.sri.com http://os.sri.com/people/nat/ (415) 859-4358 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 30 18:52:35 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id SAA16667; Thu, 30 Jan 1997 18:50:42 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id SAA16651; Thu, 30 Jan 1997 18:50:41 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id SAA25061; Thu, 30 Jan 1997 18:50:31 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA03592 for ; Thu, 30 Jan 1997 18:50:30 -0800 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id SAA16289; Thu, 30 Jan 1997 18:50:22 -0800 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id SAA03556; Thu, 30 Jan 1997 18:50:20 -0800 From: "Javier Castellar" Message-Id: <9701301850.ZM3554@sixty.asd.sgi.com> Date: Thu, 30 Jan 1997 18:50:19 -0800 In-Reply-To: "Jeff Clark" "Hardware questions..." (Jan 30, 4:34pm) References: <9701301634.ZM8170@nvg.aircrew.asu.edu> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Jeff Clark" , info-performer@sgi.com Subject: Re: Hardware questions... Cc: jclark@acm.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O For auto gain, one good way is to page the frame buffer into texture memory and then render it back onto a 2D polygon using TLUTs (Texture Look Up Tables). Both OpenGL and Performer support direct framebuffer to texture paging (also named as texture copy). In the TLUT you can apply whatever is the transfer function that you whish to achieve in funtion of the "main brightness" of the previous frames. The TLUT has no performance penalty. -Javier On Jan 30, 4:34pm, Jeff Clark wrote: > Subject: Hardware questions... > > Hello all, > > I am having difficulty implementing an "automatic gain control" for my > Performer app. By AGC, I mean the gain on each pixel is a function > of the average pixel value (intensity... one color component) of the > current frame (or previous frame, Ill take what I can get). The correct > result would be constant overall brightness on the display. > > I have implemented this in a handful of ways, but all of my attempts EITHER > make it impossible to maintain my target frame rate OR don't provide > an adequate AGC performance (I would like an AGC update rate of ~15Hz). > > There are two issues involved... here they are along with my attempted > solutions: > > -Come up with an accurate (or approximate) average pixel value at ~15Hz: > > -approximate average pixel value using an ogl MINMAX histogram. This > is fast, but the approximation is unsatisfactory. > > -approximate average pixel value by reading a slice of the framebuffer > (glReadPixels()) every frame. i.e. if I read 32 lines/frame, I read > the entire FB every 32 frames. So what I have is an "idea" of the > brightness of the entire scene over the last 32 frames. This introduces > temporal inaccuracies that are probably unacceptable. This actually > looks pretty good a lot of the time, but sometimes not...i.e. in the > worst case a bright source moves into the scene and has no effect on > the AGC until 31 frames later. At 60 fps, this is an effective AGC > update of 2 Hz... unacceptable. > > -approximate average pixel value using an ogl MINMAX histogram of one > color component. The penalty to the draw process is comparable to > using glReadPixels() and, therefore would be done in slices. Now > I have the same problem as in the last attempt. > > -Apply a gain to the entire display based on the result of the first task > above: > > -accumulate the 1 million pixels in the accumulation buffer and set the > acbuf gain to the desired gain. This, of course, works fine but takes > up so much draw that I don't have enough time to draw my scene at the > complexity my simulation requires. > > > SO, anybody have any ideas? (in the context of a 2 pipe iR with Sirius option) > > I am starting to think of ways to do it near the end or after the pipeline: > > On the gain issue, I wonder if there is a way to apply a gain (analog or > digital) in the DG... i.e. near the DAC or gamma tables? In the ircombine > channel attributes window I notice a GAIN field... is this a user register > that can be changed at 15 Hz? (ASD, if this doesn't exist it sure would be > a groovy thing to have!) Or, could the Sirius box apply a gain offline > (and do so quickly) (sorry, I'm Siriusly ignorant)? > > On the pixel averaging issue, I wonder again if the Sirius can't be used? > > If not Sirius, I would think it would be posible to find a specialized > hardware box that performs my AGC... i.e. a box that takes analog video > and outputs a signal with constant overall brightness. Anybody ever heard > of such a gizmo? > > Apologies: > > Im sorry that these aren't -exactly- Performer questions, but they are SGI > questions... and this list is the best resource I know of. Besides, it is > difficult to get this kind of info from support. > Im sorry that this post is long enough to cut into your lunch break! > > > Any responses will be GREATLY appreciated... I'm am beginning to run out of > ideas. > > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Jeff Clark -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: 415-933-1589 / 2108 (lab) * * Core Design - Applied Engineering * Fax: 415-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetent" Hardin Seldon ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Thu Jan 30 20:34:46 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id UAA17307; Thu, 30 Jan 1997 20:33:14 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id UAA17291; Thu, 30 Jan 1997 20:33:13 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id UAA28985; Thu, 30 Jan 1997 20:33:02 -0800 Received: from emerald.oz.net (emerald.oz.net [198.68.184.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA18565 for ; Thu, 30 Jan 1997 20:32:49 -0800 Received: from avi.oz.net (avi.oz.net [206.61.159.122]) by emerald.oz.net (8.8.4/8.7.3) with SMTP id UAA04002; Thu, 30 Jan 1997 20:46:32 -0800 (PST) Date: Thu, 30 Jan 1997 20:46:32 -0800 (PST) Message-Id: <1.5.4.16.19970130203533.35e7982c@oz.net> X-Sender: avi@oz.net X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jeff Clark" From: Avi Bar-Zeev Subject: Re: Hardware questions... Cc: info-performer@sgi.com Status: O To speed up your framebuffer approach, you can open a second, much smalller, off-screen channel and re-render the scene (capture the first render to a displaylist). Or, better yet, use the framebuffer-to-texture trick to render the second channel. By cranking multi-sampling all the way up, you may be able to use the hardware antialiasing (gausian filtering, right?) to speed up your calculations. You might get a big boost with the fb-to-texture trick if your second channel is 1x1 pixel and you can somehow get the texture quickly MIP-map processed. But this may be pushing it. Avi At 04:34 PM 1/30/97 -0700, Jeff Clark wrote: > >Hello all, > >I am having difficulty implementing an "automatic gain control" for my >Performer app. By AGC, I mean the gain on each pixel is a function >of the average pixel value (intensity... one color component) of the >current frame (or previous frame, Ill take what I can get). The correct >result would be constant overall brightness on the display. > >I have implemented this in a handful of ways, but all of my attempts EITHER >make it impossible to maintain my target frame rate OR don't provide >an adequate AGC performance (I would like an AGC update rate of ~15Hz). > >There are two issues involved... here they are along with my attempted >solutions: > >-Come up with an accurate (or approximate) average pixel value at ~15Hz: > > -approximate average pixel value using an ogl MINMAX histogram. This > is fast, but the approximation is unsatisfactory. > > -approximate average pixel value by reading a slice of the framebuffer > (glReadPixels()) every frame. i.e. if I read 32 lines/frame, I read > the entire FB every 32 frames. So what I have is an "idea" of the > brightness of the entire scene over the last 32 frames. This introduces > temporal inaccuracies that are probably unacceptable. This actually > looks pretty good a lot of the time, but sometimes not...i.e. in the > worst case a bright source moves into the scene and has no effect on > the AGC until 31 frames later. At 60 fps, this is an effective AGC > update of 2 Hz... unacceptable. > > -approximate average pixel value using an ogl MINMAX histogram of one > color component. The penalty to the draw process is comparable to > using glReadPixels() and, therefore would be done in slices. Now > I have the same problem as in the last attempt. > >-Apply a gain to the entire display based on the result of the first task > above: > > -accumulate the 1 million pixels in the accumulation buffer and set the > acbuf gain to the desired gain. This, of course, works fine but takes > up so much draw that I don't have enough time to draw my scene at the > complexity my simulation requires. > > >SO, anybody have any ideas? (in the context of a 2 pipe iR with Sirius option) > >I am starting to think of ways to do it near the end or after the pipeline: > >On the gain issue, I wonder if there is a way to apply a gain (analog or >digital) in the DG... i.e. near the DAC or gamma tables? In the ircombine >channel attributes window I notice a GAIN field... is this a user register >that can be changed at 15 Hz? (ASD, if this doesn't exist it sure would be >a groovy thing to have!) Or, could the Sirius box apply a gain offline >(and do so quickly) (sorry, I'm Siriusly ignorant)? > >On the pixel averaging issue, I wonder again if the Sirius can't be used? > >If not Sirius, I would think it would be posible to find a specialized >hardware box that performs my AGC... i.e. a box that takes analog video >and outputs a signal with constant overall brightness. Anybody ever heard >of such a gizmo? > >Apologies: > >Im sorry that these aren't -exactly- Performer questions, but they are SGI >questions... and this list is the best resource I know of. Besides, it is >difficult to get this kind of info from support. >Im sorry that this post is long enough to cut into your lunch break! > > >Any responses will be GREATLY appreciated... I'm am beginning to run out of >ideas. > > >======================================================================= >List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > > Avi Bar-Zeev -- "Every trip begins with a single misstep" A Real-Time 3-D Animated Character -- avi@oz.net http://www.oz.net/~avi WOLFCHILD-3D Consulting -- avi@wolfchild.com http://www.wolfchild.com/3d ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 01:47:02 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id BAA17737; Fri, 31 Jan 1997 01:45:38 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id BAA17721; Fri, 31 Jan 1997 01:45:38 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA08601; Fri, 31 Jan 1997 01:45:27 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA28988; Fri, 31 Jan 1997 01:45:21 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA17472; Fri, 31 Jan 1997 09:38:33 GMT From: "Angus Dorbie" Message-Id: <9701310938.ZM17470@bitch.reading.sgi.com> Date: Fri, 31 Jan 1997 09:38:33 +0000 In-Reply-To: "Nathaniel Bletter" "Mirror image rendering" (Jan 30, 5:53pm) References: <9701301753.ZM1581@od.sri.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com, "Nathaniel Bletter" Subject: Re: Mirror image rendering Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Nat, either reproduce the reflected geometry, or just use an SCS to flip the model. You will experience reverse face culling but I think lighting should be OK. Just remember that a reflected object would need a different set of light sources so perhaps your multiple channel idea is worth exploring. It'd also let you ensure rendering order without channel bin sorting. You need to reverse or disable the surface culling and it may help to turn on two sided lighting, but actually I thing this _would_ reverse the lighting so keep the normals you've got and try _just_ face cullng for now. Don't forget to move the light sources for the scene in the reflective channel. I think it would be a _really_ good idea to use a pfFlatten with an SCS like this if it will avoid the negative scale. This will probably improve geometry performance a lot. On Jan 30, 5:53pm, Nathaniel Bletter wrote: > Subject: Mirror image rendering > Does anyone know how to vertically flip the image produced by perfomer? I'm > viewing the monitor in a mirror and need to compensate for it. >-- End of excerpt from Nathaniel Bletter ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 02:53:55 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id CAA17873; Fri, 31 Jan 1997 02:52:43 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id CAA17857; Fri, 31 Jan 1997 02:52:42 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA10281; Fri, 31 Jan 1997 02:52:31 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id CAA07013 for ; Fri, 31 Jan 1997 02:52:28 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-9.mail.demon.net id aa902238; 31 Jan 97 10:44 GMT From: Mark Baranowski To: info-performer@sgi.com Subject: Q; How to determine memory allocation for a given scene? Date: Fri, 31 Jan 1997 10:44:53 GMT Organization: Pera Message-ID: <32f1cb5a.8028395@post.demon.co.uk> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O Hi Performers, Is there an easy way to determine the amount of memory required by a given scene graph? or will I have to write a traverser and use pfGetSize on everything I can lay my hands on? (Anybody already done this?) A quick response would be greatly appreciated. TIA Mark (Off to check the archives now!) --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leics. LE13 0PB. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 03:44:07 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id DAA18023; Fri, 31 Jan 1997 03:42:54 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id DAA18007; Fri, 31 Jan 1997 03:42:53 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA11414; Fri, 31 Jan 1997 03:42:42 -0800 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA16126 for ; Fri, 31 Jan 1997 03:42:42 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id DAA26248; Fri, 31 Jan 1997 03:42:41 -0800 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id DAA18456; Fri, 31 Jan 1997 03:42:40 -0800 From: "Sharon Clay" Message-Id: <9701310342.ZM18454@rose.asd.sgi.com> Date: Fri, 31 Jan 1997 03:42:40 -0800 In-Reply-To: Mark Baranowski "Q; How to determine memory allocation for a given scene?" (Jan 31, 10:44am) References: <32f1cb5a.8028395@post.demon.co.uk> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: Mark Baranowski , info-performer@sgi.com Subject: Re: Q; How to determine memory allocation for a given scene? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Jan 31, 10:44am, Mark Baranowski wrote: > Subject: Q; How to determine memory allocation for a given scene? ->From: Mark Baranowski -> -> ->Is there an easy way to determine the amount of memory required by a ->given scene graph? or will I have to write a traverser and use ->pfGetSize on everything I can lay my hands on? -> ->(Anybody already done this?) -> ->A quick response would be greatly appreciated. -> You can use amallinfo() to get the allocation in the shared arena. So, you can call amallinfo() before and after you load your scene and look at how much you grew. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 04:37:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id EAA18198; Fri, 31 Jan 1997 04:35:43 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id EAA18182; Fri, 31 Jan 1997 04:35:42 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA13142; Fri, 31 Jan 1997 04:35:31 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id EAA21707 for ; Fri, 31 Jan 1997 04:35:30 -0800 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-9.mail.demon.net id aa901859; 31 Jan 97 12:11 GMT From: Mark Baranowski To: info-performer@sgi.com Subject: Re: Q; How to determine memory allocation for a given scene? Date: Fri, 31 Jan 1997 12:11:20 GMT Organization: Pera Message-ID: <32f2e0a4.13474803@post.demon.co.uk> References: <32f1cb5a.8028395@post.demon.co.uk> <9701310342.ZM18454@rose.asd.sgi.com> In-Reply-To: <9701310342.ZM18454@rose.asd.sgi.com> X-Mailer: Forte Agent .99f/32.275 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Status: O On Fri, 31 Jan 1997 03:42:40 -0800, Sharon wrote: >+>---- On Jan 31, 10:44am, Mark Baranowski wrote: >> Subject: Q; How to determine memory allocation for a given scene? >->From: Mark Baranowski >-> >-> >->Is there an easy way to determine the amount of memory required by a >->given scene graph? or will I have to write a traverser and use >->pfGetSize on everything I can lay my hands on? >-> >->(Anybody already done this?) >-> >->A quick response would be greatly appreciated. >-> > > >You can use amallinfo() to get the allocation in the shared arena. >So, you can call amallinfo() before and after you load your scene >and look at how much you grew. > *THANK YOU* Sharon. Mark. --=20 Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leics. LE13 0PB. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 All opinions expressed are my own and should not be viewed as representing my employer unless stated otherwise. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 06:58:26 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id GAA18432; Fri, 31 Jan 1997 06:57:12 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id GAA18416; Fri, 31 Jan 1997 06:57:10 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA18864; Fri, 31 Jan 1997 06:57:10 -0800 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA12680 for ; Fri, 31 Jan 1997 06:57:08 -0800 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA34584; Fri, 31 Jan 1997 09:53:42 -0500 Received: by eagle.cae.ca (950413.SGI.8.6.12/930416.SGI) id JAA09278; Fri, 31 Jan 1997 09:51:11 -0500 From: "Bernard Leclerc" Message-Id: <9701310951.ZM9276@eagle.cae.ca> Date: Fri, 31 Jan 1997 09:51:11 -0500 In-Reply-To: "Jeff Clark" "Hardware questions..." (Jan 30, 4:34pm) References: <9701301634.ZM8170@nvg.aircrew.asu.edu> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Jeff Clark" , info-performer@sgi.com Subject: Re: Hardware questions... Cc: jclark@acm.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Jeff Clark wrote: > I am having difficulty implementing an "automatic gain control" for my > Performer app. By AGC, I mean the gain on each pixel is a function > of the average pixel value (intensity... one color component) of the > current frame (or previous frame, Ill take what I can get). The correct > result would be constant overall brightness on the display. [...] > On the gain issue, I wonder if there is a way to apply a gain (analog or > digital) in the DG... i.e. near the DAC or gamma tables? Supposedly, an extension to the X server could do it for you. Look for XSGIvc extensions and specifically for XSGIvcSetChannelGammaMap(). Refer to Remi Arnaud or Sharon Clay if you can't find info on the subject. > Apologies: > > Im sorry that these aren't -exactly- Performer questions, but they are > SGI questions... and this list is the best resource I know of. Besides, > it is difficult to get this kind of info from support. No need to apologize. This is the perfect forum for this type of questions.. and besides, we're all interested by the subject - well, at least some of us. -- Bernard Leclerc CAE Electronics Ltd., 8585 Cote De Liesse Technical Leader Saint-Laurent, Quebec, Canada, H4L-4X4 3-D Graphics Applications tel: +1 514 341 2000 extension 2275 bleclerc@cae.ca fax: +1 514 340 5496 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 07:13:11 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA18485; Fri, 31 Jan 1997 07:11:57 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA18469; Fri, 31 Jan 1997 07:11:56 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA19720; Fri, 31 Jan 1997 07:11:56 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id HAA15283 for ; Fri, 31 Jan 1997 07:11:51 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA21253; Fri, 31 Jan 97 09:09:56 -0500 Date: Fri, 31 Jan 97 09:09:56 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701311409.AA21253@mred.bgm.link.com> To: info-performer@sgi.com Subject: pfFrameTimeStamp Status: O Hi! I want to run *all* of my pfSequences at slower-than-realtime rates - just for a test - so in APP, I do something like: static float time = 0.0f ; . . pfFrame() ; pfFrameTimeStamp ( time ) ; time += 0.0001 ; ...and run my simulation at 30Hz. What happens is that my sequences freeze - no more animation at all! I have tried printing out pfGetFrameTimeStamp() and it increments nicely as I would expect. If (partway through the run) I stop changing pfFrameTimeStamp every frame, then the sequences continue running from where they left off. Is there some problem with touching the pfFrameTimeStamp every frame? Is there a better way to slow down realtime? (For lots of complicated reasons, I can't go and touch every pfSequence node to slow it down). Thanks in advance. Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 07:31:47 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA18620; Fri, 31 Jan 1997 07:30:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA18604; Fri, 31 Jan 1997 07:30:15 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA20768; Fri, 31 Jan 1997 07:30:15 -0800 Received: from xr1.atlas.fr (xr1.atlas.fr [194.51.9.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA18712 for ; Fri, 31 Jan 1997 07:29:38 -0800 Message-Id: <199701311529.HAA18712@sgi.sgi.com> X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 31 Jan 1997 16:28:59 +0100 X400-Received: by mta xr1.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 31 Jan 1997 16:28:59 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; converted (ia5-text,iso (1) (0) (10021) (7) (1) (0) (1),iso (1) (0) (10021) (7) (1) (0) (6),iso (1) (0) (10021) (7) (1) (0) (100)); Relayed; Fri, 31 Jan 1997 16:28:55 +0100 X400-Received: by /PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/; Relayed; Fri, 31 Jan 1997 16:26:35 +0100 Date: Fri, 31 Jan 1997 16:26:35 +0100 X400-Originator: MICHAEL.BOCCARA@siege.aerospatiale.fr X400-Recipients: info-performer@sgi.com X400-MTS-Identifier: [/PRMD=AEROSPATIALE/ADMD=ATLAS/C=FR/;970131152635] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: CSI NC V3.0 From: BOCCARA Michael To: Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: Graphics Harware Problem MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Status: O =0C Hi, I have a problem of graphics performance on an Onyx RE2 when I run a= Performer application. I have already opened a call on the SGI Hotline of Paris, but I woul= d like to have an advice from one of you pfusers, or a personnal answer from a= person of the Performer technical staff to help me. We have 2 Onyx RE2 with each 1 RM4, and 2 CPUs. We are working (stil= l) with IRIX 5.3, and Performer 2.0.1 When I am running any Performer application, even perfly, both machi= nes don't give the same graphics performance. The drawing time is at least twi= ce longer on one Onyx than on the other. I guess there is a hardware problem on the bad machine, or a problem= of configuration. But I have a strange phenomenon, that could give you a clue to help = me searching in the good direction. I have looked at the system activit= y with gr_osview while running my Performer application. In the good Onyx, the CPU activity is almost 90 percents occupied by= the "user" part (the blue one), and the system is automatically alternat= ing between the 2 CPUs. I guess this is quite normal. In the bad Onyx, the CPU activity is half shared by the "sys" part (= the red one), and there is no alternating between the two CPUs ; only one CP= U is working during one simulation. It seems like the system is fully run= ning when it deals with graphics display, but I 'm not a hardware specialist a= t all. With what I told you, does any have an idea on where is the problem = ? Which test I should do to get a finer approach of the bug ? Which trick I = could try to turn around the bug ? Anyway I am waiting for the HotLine answer, but thanks in advance to= the one(s) who will make me go a little forward. Regards, Mike Michael Boccara - ! Aerospatiale Software engineer ! Centre commun = de email : ! recher= che Louis Bleriot michael.boccara(a)siege.aerospatiale.fr ! 12 rue Pasteur Tel : (+33) (0)1 46 97 32 40 ! 92150 Suresnes Fax : (+33) (0)1 46 97 32 59 ! France ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 07:45:20 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id HAA18693; Fri, 31 Jan 1997 07:43:57 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id HAA18677; Fri, 31 Jan 1997 07:43:57 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA21394; Fri, 31 Jan 1997 07:43:56 -0800 Received: from gateway.ivex3d.com (ivex3d.com [204.241.103.1]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA21039 for ; Fri, 31 Jan 1997 07:43:36 -0800 Received: by gateway.ivex3d.com from localhost (router,SLMAIL95 V2.2); Fri, 31 Jan 1997 10:29:04 Eastern Standard Time Received: by gateway.ivex3d.com from gateway.ivex3d.com (192.168.1.27::mail daemon; unverified,SLMAIL95 V2.2); Fri, 31 Jan 1997 10:29:03 Eastern Standard Time Message-ID: <32F21535.7041@ivex3d.com> Date: Fri, 31 Jan 1997 10:52:21 -0500 From: "Rambabu" Organization: IVEX X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: info-performer@sgi.com Subject: Evironment mapping for patchy reflections below the lightpoints !!!! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi, I want to have a patchy wet surface around runway light points, for which I could use environment mapping. But my question is how do I vary the reflection parameters from on these patches. By parameters, I mean, I want to correlate the duration of rain to the reflection of the surface. The longer it rains, the better (bigger patch) reflection on the surface. Thanks in advance Ram ram@ivex3d.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 08:19:23 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA18900; Fri, 31 Jan 1997 08:17:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA18884; Fri, 31 Jan 1997 08:17:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA23931; Fri, 31 Jan 1997 08:17:54 -0800 Received: from cdse14.rti.org (cdse14.rti.org [152.5.64.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA28054 for ; Fri, 31 Jan 1997 08:17:43 -0800 Received: from es.rti.org by cdse14.rti.org (SMI-8.6/SMI-SVR4) id LAA14776; Fri, 31 Jan 1997 11:26:51 -0500 Received: by es.rti.org (5.65/DEC-Ultrix/4.3) id AA12442; Fri, 31 Jan 1997 11:10:43 -0500 Date: Fri, 31 Jan 1997 11:10:41 -0500 (EST) From: "Richard M. Spencer" X-Sender: rspencer@shrike To: Nathaniel Bletter Cc: info-performer@sgi.com Subject: Re: Mirror image rendering In-Reply-To: <9701301753.ZM1581@od.sri.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Thu, 30 Jan 1997, Nathaniel Bletter wrote: Try: pfPreScaleMat(mat, -1.0f, 1.0f, 1.0f, mat); > Does anyone know how to vertically flip the image produced by perfomer? I'm > viewing the monitor in a mirror and need to compensate for it. > > I tried creating a perspective frustrum with the top < bottom, but this seems > to reverse all the normals, messing up back face culling and lighting, and does > weird things with the near and far clipping planes. > > I also tried to do a > pfGetChanViewMat(chan, view); > pfPostMultMat(view, inv); > pfChanViewMat(chan, view); > where inv = {1, 0, 0, 0, > 0, -1, 0, 0, > 0, 0, 1, 0, > 0, 0, 0, 1} > > This seemed to do nothing. Any ideas? > > -- > > Nat Bletter > SRI International > nat@od.sri.com > http://os.sri.com/people/nat/ > (415) 859-4358 > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > Richard M. Spencer Research Triangle Institute rspencer@es.rti.org Center for Digital Systems Engineering 919-541-6733 (voice) 3040 Cornwallis Road, Herbert Bldg, Rm 246 919-541-6515 (fax) P.O. Box 12194; RTP, NC 27709-2194 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 08:41:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA18959; Fri, 31 Jan 1997 08:39:45 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA18943; Fri, 31 Jan 1997 08:39:44 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA25269; Fri, 31 Jan 1997 08:39:43 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02489 for ; Fri, 31 Jan 1997 08:39:43 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id IAA25260; Fri, 31 Jan 1997 08:39:42 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id IAA23398; Fri, 31 Jan 1997 08:39:42 -0800 From: "Rob Jenkins" Message-Id: <9701310839.ZM23396@quid.csd.sgi.com> Date: Fri, 31 Jan 1997 08:39:42 -0800 In-Reply-To: BOCCARA Michael "Graphics Harware Problem" (Jan 31, 4:26pm) References: <199701311529.HAA18712@sgi.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: BOCCARA Michael , Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: Re: Graphics Harware Problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Michael When you say both machines are the *same* does that include SW ? Can you look at the patches installed on each one ? You might also look at 'chkconfig' and 'limit', that sort of thing. In fact you could try swapping the disks and see if the problem 'follows' the disk. Just plain 'osview' may give you more accurate numbers for performance. Cheers Rob -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 08:47:11 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA19013; Fri, 31 Jan 1997 08:46:01 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA18997; Fri, 31 Jan 1997 08:46:01 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA25742; Fri, 31 Jan 1997 08:46:00 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA04317; Fri, 31 Jan 1997 08:45:58 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA17963; Fri, 31 Jan 1997 16:45:47 GMT From: "Angus Dorbie" Message-Id: <9701311645.ZM17961@bitch.reading.sgi.com> Date: Fri, 31 Jan 1997 16:45:47 +0000 In-Reply-To: "Rambabu" "Evironment mapping for patchy reflections below the lightpoints !!!!" (Jan 31, 10:52am) References: <32F21535.7041@ivex3d.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Rambabu" , info-performer@sgi.com Subject: Re: Evironment mapping for patchy reflections below the lightpoints !!!! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O You can't use environment mapping for this. If you want really excellent patchy light sources then you could try writing hidden alpha patches (alpha = wetness) to the destination alpha over the runway surface. Duplicate the geometry of the lights, but reflected through the plane of the runway. You can then change the geometry of the reflected lights to be representative of the reflection for the surface roughness. Disable the depth test. Enable blended pfTransparency. Draw the reflected lights with a blendfunction of GL_DST_ALPHA, GL_ONE. Cheers, Angus. On Jan 31, 10:52am, Rambabu wrote: > Subject: Evironment mapping for patchy reflections below the lightpoints ! > Hi, > > I want to have a patchy wet surface around runway light points, for > which I could use environment mapping. But my question is how do I > vary the reflection parameters from on these patches. By parameters, I > mean, I want to correlate the duration of rain to the reflection of the > surface. The longer it rains, the better (bigger patch) reflection on > the surface. > > > Thanks in advance > > Ram > > ram@ivex3d.com > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Rambabu ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 09:00:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id IAA19103; Fri, 31 Jan 1997 08:58:54 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA19087; Fri, 31 Jan 1997 08:58:53 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA26521; Fri, 31 Jan 1997 08:58:53 -0800 Received: from relay.interserv.com (relay.interserv.com [165.121.1.67]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id IAA06673 for ; Fri, 31 Jan 1997 08:58:47 -0800 From: inca@public.bta.net.cn Received: from 202.96.61.206 ([202.96.61.206]) by relay.interserv.com with SMTP id AA08556 (5.67b/IDA-1.5 for info-performer@sgi.com); Fri, 31 Jan 1997 08:34:59 -0800 Date: Fri, 31 Jan 1997 08:34:59 -0800 Message-Id: <199701311634.AA08556@relay.interserv.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Billboard Bug on iR? To: info-performer@sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Hi, all iR users, the following program makes a billboard, it rotates about viewpoint, and i trace to view it. so i should see a still image always. it's ok on indigo2 machine(IRIX5.3,PF2.0), but wrong on iR(IRIX6.2, PF2.1). is it a known bug? or am i missing something? Thanks for any help. (please reply befor Feb,4 or after Feb,16. i'l make holiday.) liubin inca@public.bta.net.cn #include #include #include #include "/usr/share/Performer/src/pguide/libpf/C/billboard.c" int main (int argc, char *argv[]) { float r = 0.0f, t = 0.0f; pfScene *scene; pfBillboard *bill; pfPipe *p; pfPipeWindow *pw; pfChannel *chan; pfVec3 pos; pfCoord view; pfInit(); pfMultiprocess( PFMP_DEFAULT ); pfConfig(); pfSetVec3(pos, 0.0f, 0.0f, 0.0f); bill = MakeABill(pos, NULL, 3); scene = pfNewScene(); pfAddChild(scene, bill); pfAddChild(scene, pfNewLSource()); p = pfGetPipe(0); pw = pfNewPWin(p); pfPWinName(pw, "IRIS Performer"); pfPWinOriginSize(pw, 0, 0, 500, 500); pfOpenPWin(pw); chan = pfNewChan(p); pfChanScene(chan, scene); pfChanFOV(chan, 60.0f, 0.0f); /* position viewpoint at (0, -2, 0) */ pfSetVec3(view.xyz, 0.0f, -2.0f, 0.0f); pfChanNearFar(chan, 1.0f, 100.0f); /* Simulate for twenty seconds. */ while (t > -20.0f) { float x,y,z; static dir = 1; pfSync(); pfFrame(); t = pfGetTime(); r += dir; if(r > 120.0f) dir = -1; if(r < -120.0f) dir = 1; x = 2.0f*fsin(r*M_PI/180.0f); y = 2.0f*fcos(r*M_PI/180.0f) - 2.0f; z = 0.0f; pfSetVec3(pos, x, y, z); pfBboardPos(bill, 0, pos); pfSetVec3(view.hpr, -r, 0.0f, 0.0f); pfChanView(chan, view.xyz, view.hpr); } pfExit(); } ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 09:17:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA19306; Fri, 31 Jan 1997 09:15:35 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA19290; Fri, 31 Jan 1997 09:15:34 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA27848; Fri, 31 Jan 1997 09:15:33 -0800 Received: from mail.eecs.uic.edu (mail.eecs.uic.edu [131.193.32.27]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10440 for ; Fri, 31 Jan 1997 09:15:29 -0800 Received: from cray.evl.uic.edu (cray.evl.uic.edu [131.193.48.163]) by mail.eecs.uic.edu (8.7.5/8.7.5) with ESMTP id KAA18804 for ; Fri, 31 Jan 1997 10:50:51 -0600 (CST) Received: from localhost (swami@localhost) by cray.evl.uic.edu (8.6.5/8.6.4) with SMTP id QAA01509 for ; Fri, 31 Jan 1997 16:50:38 GMT X-Authentication-Warning: cray.evl.uic.edu: swami owned process doing -bs Date: Fri, 31 Jan 1997 10:50:38 -0600 (CST) From: "Swaminathan N." To: performer mailing list Subject: pfInitClock Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Is there some weird relationship between calling pfInitClock and pfFrameStats? My app always hangs when I bring up statistics display after calling pfInitClock() with the current time (an arbitrarily large number). If instead I call pfInitClock with a small number, all's fine. What makes this frustrating is that it seems to work for most of the supplied demos. However I did manage to replicate the situation with /usr/share/Performer/src/pguide/libpfutil/movie.c After adding pfInitClock(10000000); after the line pfInit();, the app hangs if one clicks on the stats button. Am I missing something? Performer 2.0.2 under Irix 6.2. Thanks Swami <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< v Swaminathan Narayanan ^ v swami@evl.uic.edu ^ v Office: 996-3002 ^ v Home: 850-3725 ^ v http://www.evl.uic.edu/swami ^ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 09:32:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA19465; Fri, 31 Jan 1997 09:30:25 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA19449; Fri, 31 Jan 1997 09:30:24 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA29263; Fri, 31 Jan 1997 09:30:23 -0800 Received: from glut.angel.com ([198.133.210.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA14441 for ; Fri, 31 Jan 1997 09:30:18 -0800 Received: from balou.angel.com by glut.angel.com via ESMTP (951211.SGI.8.6.12.PATCH1042/940406.SGI.AUTO) id JAA22718; Fri, 31 Jan 1997 09:36:45 -0800 Received: from localhost (ryan@localhost) by balou.angel.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA24844; Fri, 31 Jan 1997 09:36:32 -0800 Date: Fri, 31 Jan 1997 09:36:32 -0800 (PST) From: Chris Ryan To: BOCCARA Michael cc: Performer ML Question Subject: Re: Graphics Harware Problem In-Reply-To: <199701311529.HAA18712@sgi.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O We had a problem here on 4cpu, 5.3 machine that turned out to be bug in the kernal/scheduler. Same symptoms of draw time on the order of 2 to 3 times slower than on other (2cpu) machines. Same gr_osview outputs you describe. The workaround, later blessed by sgi rep, was the following C/C++ program run in the background. Don't laugh, it worked for us and sgi hotline finally ended up recommending that this is the "fix" until 6.X addresses kernel/scheduler bugs. extern "C" int sginap(long); main(int, char**) { while (1) { sginap(0); } } If you read the man pages on sginap(), you can see why this might work if in fact the problem is a scheduler bug. It definitely changes your gr_osview output so that you don't have an idle CPU. For us, draw times recovered miraculously. On Fri, 31 Jan 1997, BOCCARA Michael wrote: > > > Hi, > > I have a problem of graphics performance on an Onyx RE2 when I run a > Performer application. > I have already opened a call on the SGI Hotline of Paris, but I would like to > have an advice from one of you pfusers, or a personnal answer from a person > of the Performer technical staff to help me. > > We have 2 Onyx RE2 with each 1 RM4, and 2 CPUs. We are working (still) with > IRIX 5.3, and Performer 2.0.1 > > When I am running any Performer application, even perfly, both machines don't > give the same graphics performance. The drawing time is at least twice longer > on one Onyx than on the other. > I guess there is a hardware problem on the bad machine, or a problem of > configuration. > > But I have a strange phenomenon, that could give you a clue to help me > searching in the good direction. I have looked at the system activity with > gr_osview while running my Performer application. > In the good Onyx, the CPU activity is almost 90 percents occupied by the > "user" part (the blue one), and the system is automatically alternating > between the 2 CPUs. I guess this is quite normal. > In the bad Onyx, the CPU activity is half shared by the "sys" part (the red > one), and there is no alternating between the two CPUs ; only one CPU is > working during one simulation. It seems like the system is fully running when > it deals with graphics display, but I 'm not a hardware specialist at all. > > With what I told you, does any have an idea on where is the problem ? Which > test I should do to get a finer approach of the bug ? Which trick I could try > to turn around the bug ? > > Anyway I am waiting for the HotLine answer, but thanks in advance to the > one(s) who will make me go a little forward. > > Regards, > Mike > > Michael Boccara - ! Aerospatiale > Software engineer ! Centre commun de > email : ! recherche Louis > Bleriot > michael.boccara(a)siege.aerospatiale.fr ! 12 rue Pasteur > Tel : (+33) (0)1 46 97 32 40 ! 92150 Suresnes > Fax : (+33) (0)1 46 97 32 59 ! France > ===================================List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 09:43:23 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id JAA19548; Fri, 31 Jan 1997 09:42:00 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id JAA19532; Fri, 31 Jan 1997 09:41:59 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA29941; Fri, 31 Jan 1997 09:41:58 -0800 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA16784 for ; Fri, 31 Jan 1997 09:41:56 -0800 Received: from poster.cae.ca by bhole with SMTP (DuhMail/2.0) id MAA23609; Fri, 31 Jan 1997 12:16:19 -0500 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA44140; Fri, 31 Jan 1997 12:18:07 -0500 Received: by eagle.cae.ca (950413.SGI.8.6.12/930416.SGI) id MAA09944; Fri, 31 Jan 1997 12:15:33 -0500 From: "Bernard Leclerc" Message-Id: <9701311215.ZM9942@eagle.cae.ca> Date: Fri, 31 Jan 1997 12:15:33 -0500 In-Reply-To: BOCCARA Michael "Graphics Harware Problem" (Jan 31, 4:26pm) References: <199701311529.HAA18712@sgi.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: BOCCARA Michael , Performer ML Question (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: Re: Graphics Harware Problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Michael Boccara wrote: > In the bad Onyx, the CPU activity is half shared by the "sys" part (the > red one), and there is no alternating between the two CPUs ; only one > CPU is working during one simulation. Mike, Since your application seems to be running on only one CPU, maybe you have restricted or isolated CPUs on the "bad" Onyx. Try running "mpadmin -s". Is your application always running on the same CPU every time you try it? If it's the case, it might indicate that the other CPU is restricted. As mentioned by Rob Jenkins, use the plain "osview" to obtain better indication on various system activities. -- Bernard Leclerc CAE Electronics Ltd., 8585 Cote De Liesse Technical Leader Saint-Laurent, Quebec, Canada, H4L-4X4 3-D Graphics Applications tel: +1 514 341 2000 extension 2275 bleclerc@cae.ca fax: +1 514 340 5496 ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 10:12:21 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA19766; Fri, 31 Jan 1997 10:10:58 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA19750; Fri, 31 Jan 1997 10:10:58 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA02111; Fri, 31 Jan 1997 10:10:57 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA23428 for ; Fri, 31 Jan 1997 10:10:45 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA22815; Fri, 31 Jan 97 11:56:59 -0500 Date: Fri, 31 Jan 97 11:56:59 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701311656.AA22815@mred.bgm.link.com> To: info-performer@sgi.com Subject: glDrawPixels speed. Status: O Is there some trick to getting fast 'glDrawPixels'? I'm trying to dump a 640x480 chunk of image data from main memory into the frame buffer, using something like: glDrawPixels ( WIDTH, HEIGHT, GL_RGB, GL_UNSIGNED_BYTE, buff ) ; On infinite reality (2xRM, R10k CPU's) I'm seeing ~12Mbytes per second and on RE2 (2xRM R4400 CPU's) I'm getting ~7Mbytes per second. I recollect hearing figure nearer 100 to 200Mbytes/sec on the iR - am I mistaken - or is there something wrong here? I get better rates than this on my PC at home (admittedly not when using GL)! Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 10:21:54 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA19835; Fri, 31 Jan 1997 10:20:50 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA19819; Fri, 31 Jan 1997 10:20:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA02902; Fri, 31 Jan 1997 10:20:49 -0800 Received: from gatekeep.ti.com (news.ti.com [192.94.94.33]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25838 for ; Fri, 31 Jan 1997 10:20:47 -0800 Received: from dskp3.itg.ti.com ([172.25.2.71]) by gatekeep.ti.com (8.6.13) with ESMTP id MAA11056 for ; Fri, 31 Jan 1997 12:20:46 -0600 Received: from ti (mallbright.dseg.ti.com [172.25.56.33]) by dskp3.itg.ti.com (8.8.3/8.8.2) with SMTP id MAA28637 for ; Fri, 31 Jan 1997 12:20:15 -0600 (CST) X-Mailer: BeyondMail for Windows/Professional 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit To: info-performer@sgi.com From: "Michael M. Allbright" Subject: Non-MultiSample Anti-aliasing Date: Fri, 31 Jan 1997 11:58:49 -0800 X-BeyondMail-Priority: 1 Message-Id: Conversation-Id: Reply-To: "Michael M. Allbright" X-Receipt-From-Agent: true Status: O Howdy: I am considering the purchase of an Octane or two, but I am very concerned about aliasing. I understand that the Octane does anti-aliasing of points and lines only--no polygon anti-aliasing. Since the next OpenGL machine capable of hardware polygon antialiasing seems to be an Onyx IR at about 4 times the price, I am seriously considering antialiasing using the accumulation buffer (although I have yet to verify that the accum. buffer will be available on the Octane in the rendering mode our simulator uses). Hence the question: Can anyone share any hints/tips/tricks/gotchas/code-snippets/algorithms or just plain old advice on the subject of anti-aliasing using the accumulation buffer, or similar techniques on Max Impact/Octane level machines? Thanks --Mike ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 10:34:01 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA19935; Fri, 31 Jan 1997 10:30:54 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA19919; Fri, 31 Jan 1997 10:30:53 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA03788; Fri, 31 Jan 1997 10:30:53 -0800 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA28397 for ; Fri, 31 Jan 1997 10:30:49 -0800 Received: from dskp3.itg.ti.com ([172.25.2.71]) by dragon.ti.com (8.6.13) with ESMTP id MAA06041 for ; Fri, 31 Jan 1997 12:30:29 -0600 Received: from ti (mallbright.dseg.ti.com [172.25.56.33]) by dskp3.itg.ti.com (8.8.3/8.8.2) with SMTP id MAA01171 for ; Fri, 31 Jan 1997 12:29:58 -0600 (CST) X-Mailer: BeyondMail for Windows/Professional 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit To: info-performer@sgi.com From: "Michael M. Allbright" Subject: Non-MultiSample Anti-aliasing Date: Fri, 31 Jan 1997 12:30:58 -0800 X-BeyondMail-Priority: 1 Message-Id: Conversation-Id: Reply-To: "Michael M. Allbright" X-Receipt-From-Agent: true Status: O Howdy: I am seriously considering the purchase of an Octane or two, but I am very concerned about aliasing. Since the next OpenGL machine capable of hardware polygon anti-aliasing seems to be an Onyx IR at about 4 times the price, I am thinking about using the accumulation buffer (although I have yet to verify that the accumulation buffer will be available on the Octane in the rendering mode our simulator uses). Hence the question: Does anyone have any hints/tips/tricks/gotchas/code-snippets/algorithms or just plain advice on the topic of using the accumulation buffer or similar techniques on Max Impact/Octane level machines. Thanks. --Mike ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 10:36:10 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA19975; Fri, 31 Jan 1997 10:34:59 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA19959; Fri, 31 Jan 1997 10:34:58 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA04066; Fri, 31 Jan 1997 10:34:58 -0800 Received: from due.unit.no (due.unit.no [129.241.1.83]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA29354 for ; Fri, 31 Jan 1997 10:34:55 -0800 Received: from localhost (morten@localhost) by due.unit.no (8.7.5/8.7.3) with SMTP id TAA00287; Fri, 31 Jan 1997 19:33:10 +0100 (MET) Date: Fri, 31 Jan 1997 19:33:08 +0100 (MET) From: Morten Eriksen To: Steve Baker cc: info-performer@sgi.com Subject: Re: glDrawPixels speed. In-Reply-To: <9701311656.AA22815@mred.bgm.link.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O > Is there some trick to getting fast 'glDrawPixels'? I'm If you stuff the call inside a displaylist, I believe there's a good chance that the format of the pixeldata get optimized (by GL) for your particular hardware-platform. (This method is only good if you're not displaying different images on each call, of course). Morten ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 10:40:26 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA20023; Fri, 31 Jan 1997 10:39:23 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA20007; Fri, 31 Jan 1997 10:39:22 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA04294; Fri, 31 Jan 1997 10:39:22 -0800 Received: from due.unit.no (due.unit.no [129.241.1.83]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00559 for ; Fri, 31 Jan 1997 10:39:18 -0800 Received: from localhost (morten@localhost) by due.unit.no (8.7.5/8.7.3) with SMTP id TAA00305; Fri, 31 Jan 1997 19:38:00 +0100 (MET) Date: Fri, 31 Jan 1997 19:37:58 +0100 (MET) From: Morten Eriksen To: steve@mred.bgm.link.com cc: info-performer@sgi.com Subject: glDrawPixels() speed cont. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Forgot to say: Also, remember to disable all expensive states which you don't need (blending, transparency, depthtesting, and so on). Morten ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 10:46:03 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA20076; Fri, 31 Jan 1997 10:44:31 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA20060; Fri, 31 Jan 1997 10:44:31 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA04604; Fri, 31 Jan 1997 10:44:30 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01818 for ; Fri, 31 Jan 1997 10:44:30 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for <@rock.csd.sgi.com:info-performer@sgi.com> id KAA04601; Fri, 31 Jan 1997 10:44:29 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer@sgi.com id KAA23809; Fri, 31 Jan 1997 10:44:29 -0800 From: "Rob Jenkins" Message-Id: <9701311044.ZM23807@quid.csd.sgi.com> Date: Fri, 31 Jan 1997 10:44:29 -0800 In-Reply-To: steve@mred.bgm.link.com (Steve Baker) "glDrawPixels speed." (Jan 31, 11:56am) References: <9701311656.AA22815@mred.bgm.link.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.com Subject: Re: glDrawPixels speed. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Steve - if this doesn't cover some specific case you have, let me know. I 'spect GL_RGBA and some glDisables will help. Allen Akin put this in the FAQs, it covers all platforms so can serve as reference to all ( actually it's the answer to 'Why is OpenGL's glDrawPixels slower than IrisGL's lrectwrite?' but covers Steve's question: ----------------------------- Q:'Why is OpenGL's glDrawPixels slower than IrisGL's lrectwrite?' A:It's not, for the most common cases. After all, similar microcode and the same hardware are used for both commands. However, there are three issues to keep in mind. First, some midrange and low-end SGI graphics adaptors (particularly XS, XZ, Elan, and Extreme) transfer ABGR-ordered images much faster than they transfer RGBA-ordered images. The normal image format in IrisGL was ABGR, while in OpenGL it's RGBA. So to achieve the same performance in OpenGL that you did in IrisGL on those machines, you need to use ABGR-format images in OpenGL. The ABGR extension available in Irix 5.3 and later releases allows you to do this. See ``man glintro'' for background information on using OpenGL extensions, and ``man gldrawpixels'' for details on ABGR. Note that RealityEngine, IMPACT, and all future machines will process RGBA data at least as fast as ABGR, so RGBA is the way to go for new code. Second, some OpenGL pixel data types are faster than others. For most machines, unsigned byte RGBA (or ABGR) is the fastest full-color type. Unsigned byte and unsigned short are usually the fastest gray-scale types. Signed integer types are slower. Third, OpenGL pixel operations have a much richer set of features than IrisGL, and if any of those features are enabled, then image transfer can be significantly slower. Always disable the features that you don't need. The following code fragment disables features that are likely to make glDrawPixels slow: /* * Disable stuff that's likely to slow down glDrawPixels. * (Omit as much of this as possible, when you know in advance * that the OpenGL state will already be set correctly.) */ glDisable(GL_ALPHA_TEST); glDisable(GL_BLEND); glDisable(GL_DEPTH_TEST); glDisable(GL_DITHER); glDisable(GL_FOG); glDisable(GL_LIGHTING); glDisable(GL_LOGIC_OP); glDisable(GL_STENCIL_TEST); glDisable(GL_TEXTURE_1D); glDisable(GL_TEXTURE_2D); glPixelTransferi(GL_MAP_COLOR, GL_FALSE); glPixelTransferi(GL_RED_SCALE, 1); glPixelTransferi(GL_RED_BIAS, 0); glPixelTransferi(GL_GREEN_SCALE, 1); glPixelTransferi(GL_GREEN_BIAS, 0); glPixelTransferi(GL_BLUE_SCALE, 1); glPixelTransferi(GL_BLUE_BIAS, 0); glPixelTransferi(GL_ALPHA_SCALE, 1); glPixelTransferi(GL_ALPHA_BIAS, 0); /* * Disable extensions that could slow down glDrawPixels. * (Actually, you should check for the presence of the proper * extension before making these calls. I've omitted that * code for simplicity.) */ #ifdef GL_EXT_convolution glDisable(GL_CONVOLUTION_1D_EXT); glDisable(GL_CONVOLUTION_2D_EXT); glDisable(GL_SEPARABLE_2D_EXT); #endif #ifdef GL_EXT_histogram glDisable(GL_HISTOGRAM_EXT); glDisable(GL_MINMAX_EXT); #endif #ifdef GL_EXT_texture3D glDisable(GL_TEXTURE_3D_EXT); #endif -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 10:53:27 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA20266; Fri, 31 Jan 1997 10:52:20 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA20249; Fri, 31 Jan 1997 10:52:19 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA05404; Fri, 31 Jan 1997 10:52:19 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA03955; Fri, 31 Jan 1997 10:52:17 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA18285; Fri, 31 Jan 1997 18:52:15 GMT From: "Angus Dorbie" Message-Id: <9701311852.ZM18283@bitch.reading.sgi.com> Date: Fri, 31 Jan 1997 18:52:15 +0000 In-Reply-To: "Rambabu" "Re: Evironment mapping for patchy reflections below the lightpoints !!!!" (Jan 31, 1:36pm) References: <32F21535.7041@ivex3d.com> <9701311645.ZM17961@bitch.reading.sgi.com> <32F23B9D.7176@ivex3d.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Rambabu" Subject: Re: Evironment mapping for patchy reflections below the lightpoints !!!! Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I should point out that for this blend function alpha is meaningless, you should have accurate light colour fading to black on the outside of the polygon. Cheers, Angus. > Subject: Re: Evironment mapping for patchy reflections below the lightpoin > Angus Dorbie wrote: > > If you want really excellent patchy light sources then you could > > try writing hidden alpha patches (alpha = wetness) to the destination > > alpha over the runway surface. > > > > Duplicate the geometry of the lights, but reflected through > > the plane of the runway. > > > > You can then change the geometry of the reflected lights to be representative > > of the reflection for the surface roughness. > > > > Disable the depth test. > > > > Enable blended pfTransparency. > > > > Draw the reflected lights with a blendfunction of GL_DST_ALPHA, GL_ONE. > > ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 10:59:17 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id KAA20407; Fri, 31 Jan 1997 10:57:56 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id KAA20391; Fri, 31 Jan 1997 10:57:55 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA05945; Fri, 31 Jan 1997 10:57:55 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05364; Fri, 31 Jan 1997 10:57:53 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA18307; Fri, 31 Jan 1997 18:57:51 GMT From: "Angus Dorbie" Message-Id: <9701311857.ZM18305@bitch.reading.sgi.com> Date: Fri, 31 Jan 1997 18:57:51 +0000 In-Reply-To: steve@mred.bgm.link.com (Steve Baker) "glDrawPixels speed." (Jan 31, 11:56am) References: <9701311656.AA22815@mred.bgm.link.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: steve@mred.bgm.link.com (Steve Baker), info-performer@sgi.com Subject: Re: glDrawPixels speed. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Steve, check your pixel transfer modes etc. Try different format images on the host. Have you tried sub texture loading the image to a bound texture in texture memory and drawing a polygon to the screen? Again, watch texture memory. Does the image have to be back on the host? Cheers, Angus. On Jan 31, 11:56am, Steve Baker wrote: > Subject: glDrawPixels speed. > > Is there some trick to getting fast 'glDrawPixels'? I'm > trying to dump a 640x480 chunk of image data from main > memory into the frame buffer, using something like: > > glDrawPixels ( WIDTH, HEIGHT, GL_RGB, GL_UNSIGNED_BYTE, buff ) ; > > On infinite reality (2xRM, R10k CPU's) I'm seeing ~12Mbytes per second > and on RE2 (2xRM R4400 CPU's) I'm getting ~7Mbytes per second. > > I recollect hearing figure nearer 100 to 200Mbytes/sec on the iR - am > I mistaken - or is there something wrong here? > > I get better rates than this on my PC at home (admittedly not when using GL)! > > > Steve Baker 817-619-1361 (Vox-Lab) > Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) > 2200 Arlington Downs Road 817-619-4028 (Fax) > Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) > http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) > http://web2.airmail.net/sjbaker1 (external) > > "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. > > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Steve Baker ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 11:22:44 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA20731; Fri, 31 Jan 1997 11:20:47 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA20715; Fri, 31 Jan 1997 11:20:46 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA08198; Fri, 31 Jan 1997 11:20:46 -0800 Received: from smtp.connectnet.com (smtp.connectnet.com [207.110.0.12]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10968 for ; Fri, 31 Jan 1997 11:20:44 -0800 Received: from curt.delphiresearch.com ([207.110.10.2]) by smtp.connectnet.com (8.8.4/Connectnet-2.2) with ESMTP id KAA11894 for ; Fri, 31 Jan 1997 10:50:59 -0800 (PST) Message-Id: <199701311850.KAA11894@smtp.connectnet.com> From: "Curt Bryan" To: Subject: R4400 vs. R10000 thoughts or benchmarks Date: Fri, 31 Jan 1997 10:53:02 -0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: O Hello, I guess this is really more of a general SGI question but who would know better than all of you. Has anyone seen any information that offers a direct comparison between the R4400 and R10000 CPUs. Someone might also have first-hand experience with them both? The problem I'm having is that the benchmarks for the R4400 are SPEC92 and SPEC95 for the R10000. I haven't figured a way to normalize the benchmarks to get an apples-to-apples comparison. Any help would be appreciated. Thanks, Curt __________________________________ Curt Bryan | Delphi Research, Inc. | 3954 Murphy Canyon Road | Suite D-201 | San Diego, CA 92123 | | Voice: (619) 694-1314 | Fax: (619) 694-1356 | | E-mail: curtb@delphiresearch.com | ----------------------------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 11:22:47 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA20749; Fri, 31 Jan 1997 11:20:50 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA20733; Fri, 31 Jan 1997 11:20:49 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA08204; Fri, 31 Jan 1997 11:20:48 -0800 Received: from smtp.connectnet.com (smtp.connectnet.com [207.110.0.12]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10994 for ; Fri, 31 Jan 1997 11:20:47 -0800 Received: from curt.delphiresearch.com ([207.110.10.2]) by smtp.connectnet.com (8.8.4/Connectnet-2.2) with ESMTP id KAA11895 for ; Fri, 31 Jan 1997 10:50:59 -0800 (PST) Message-Id: <199701311850.KAA11895@smtp.connectnet.com> From: "Curt Bryan" To: Subject: R4400 vs. R10000 thoughts or benchmarks Date: Fri, 31 Jan 1997 10:53:02 -0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: O Hello, I guess this is really more of a general SGI question but who would know better than all of you. Has anyone seen any information that offers a direct comparison between the R4400 and R10000 CPUs. Someone might also have first-hand experience with them both? The problem I'm having is that the benchmarks for the R4400 are SPEC92 and SPEC95 for the R10000. I haven't figured a way to normalize the benchmarks to get an apples-to-apples comparison. Any help would be appreciated. Thanks, Curt __________________________________ Curt Bryan | Delphi Research, Inc. | 3954 Murphy Canyon Road | Suite D-201 | San Diego, CA 92123 | | Voice: (619) 694-1314 | Fax: (619) 694-1356 | | E-mail: curtb@delphiresearch.com | ----------------------------------- ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 11:28:08 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA20805; Fri, 31 Jan 1997 11:26:55 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA20789; Fri, 31 Jan 1997 11:26:54 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA08564; Fri, 31 Jan 1997 11:26:54 -0800 Received: from hotsauce.clubfed.sgi.com ([169.238.2.14]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12758 for ; Fri, 31 Jan 1997 11:26:52 -0800 Received: (from brian@localhost) by hotsauce.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA01203; Fri, 31 Jan 1997 14:18:14 -0500 Date: Fri, 31 Jan 1997 14:18:14 -0500 From: brian@sgi.com (Brian Furtaw) Message-Id: <9701311418.ZM1202@hotsauce.clubfed.sgi.com> In-Reply-To: "Michael M. Allbright" "Non-MultiSample Anti-aliasing" (Jan 31, 11:58am) References: Reply-To: brian@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Michael M. Allbright" , info-performer@sgi.com Subject: Re: Non-MultiSample Anti-aliasing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O You can outline your polygons with antialiased lines or use the accumulation buffer for full screen antialiasing. Brian On Jan 31, 11:58am, Michael M. Allbright wrote: > Subject: Non-MultiSample Anti-aliasing > Howdy: > > I am considering the purchase of an Octane or two, but I am very concerned > about aliasing. I understand that the Octane does anti-aliasing of points and > lines only--no polygon anti-aliasing. Since the next OpenGL machine capable of > hardware polygon antialiasing seems to be an Onyx IR at about 4 times the > price, I am seriously considering antialiasing using the accumulation buffer > (although I have yet to verify that the accum. buffer will be available on the > Octane in the rendering mode our simulator uses). > > Hence the question: > Can anyone share any hints/tips/tricks/gotchas/code-snippets/algorithms or just > plain old advice on the subject of anti-aliasing using the accumulation buffer, > or similar techniques on Max Impact/Octane level machines? > > Thanks > --Mike > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Michael M. Allbright -- o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o Brian Furtaw (brian@sgi.com) VisSim Technical Consultant 12200-G Plum Orchard Drive Office:(301)572-3293 Fax: (301)872-3293 Silver Spring, Maryland 20904 OpenGL/ImageVision/OpenInventor/Performer ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 11:28:50 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA20823; Fri, 31 Jan 1997 11:27:26 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA20807; Fri, 31 Jan 1997 11:27:26 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA08584; Fri, 31 Jan 1997 11:27:25 -0800 Received: from bitch.reading.sgi.com ([144.253.70.18]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12868; Fri, 31 Jan 1997 11:27:23 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id TAA18382; Fri, 31 Jan 1997 19:27:21 GMT From: "Angus Dorbie" Message-Id: <9701311927.ZM18380@bitch.reading.sgi.com> Date: Fri, 31 Jan 1997 19:27:21 +0000 In-Reply-To: "Michael M. Allbright" "Non-MultiSample Anti-aliasing" (Jan 31, 11:58am) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Michael M. Allbright" , info-performer@sgi.com Subject: Re: Non-MultiSample Anti-aliasing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O OCTANE can anti-alias in Real Time, read on. Get your sales Rep to show you an OCTANE or Indigo2 IMPACT running the "RAPIER" demo. It anti-aliases the targets using a second pass with textured, lit wireframe. In general anti-aliasing isn't that big a problem for IMPACT for several reasons: 1) trilinear MIP mapping and point sampled polygon edges mean you only need it where texture ID changes or you get a shilouette. 2) You can use a wireline pass very effectively to get high quality blended edges in a scene and can control the load. The fill performance hit is manageable because it's wireline. 3) Soft edge blending alpha textures like tree lines mean you you never need it for blended alpha textures. You may also want to look at ONYX2 Reality, if you must have multisample at IMPACT fill performance but not at 4x cost. Accumulation buffering is expensive, it's multipass + accumulation operations. Lets say you want 4 samples, you have to draw _everything_ four times, geometry and pixel fill, accumulate four images and copy to framebuffer once, simulation death. And that's just for four samples. If you perform the line anti-aliasing mentioned above you get the edge quality equivalent of 256 samples. Thet're not weighted as accurately as multisample but it's a _big_ improvement over no AA in any simulation. Cheers, Angus. On Jan 31, 11:58am, Michael M. Allbright wrote: > Subject: Non-MultiSample Anti-aliasing > Howdy: > > I am considering the purchase of an Octane or two, but I am very concerned > about aliasing. I understand that the Octane does anti-aliasing of points and > lines only--no polygon anti-aliasing. Since the next OpenGL machine capable of > hardware polygon antialiasing seems to be an Onyx IR at about 4 times the > price, I am seriously considering antialiasing using the accumulation buffer > (although I have yet to verify that the accum. buffer will be available on the > Octane in the rendering mode our simulator uses). > > Hence the question: > Can anyone share any hints/tips/tricks/gotchas/code-snippets/algorithms or just > plain old advice on the subject of anti-aliasing using the accumulation buffer, > or similar techniques on Max Impact/Octane level machines? > > Thanks > --Mike > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Michael M. Allbright ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 11:47:16 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA21030; Fri, 31 Jan 1997 11:45:37 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA21014; Fri, 31 Jan 1997 11:45:36 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA09823; Fri, 31 Jan 1997 11:45:36 -0800 Received: from crdems.ge.com (crdems.GE.COM [192.35.44.5]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA15820 for ; Fri, 31 Jan 1997 11:45:30 -0800 Received: from bart.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA19901; Fri, 31 Jan 97 14:42:14 -0500 Received: from bart by bart.crd.ge.com (SMI-8.6/GE-CRD Standard Sendmail Version S1.5)id OAA05629; Fri, 31 Jan 1997 14:42:20 -0500 Sender: volpe@ash.crd.ge.com Message-Id: <32F24B1C.7502@ash.crd.ge.com> Date: Fri, 31 Jan 1997 14:42:20 -0500 From: Christopher R Volpe Organization: GE Corporate Research & Development, Schenectady, NY X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: iris-performer@sgi.com Subject: pfPipeWindow constructor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Documentation question: Is there some reason why the C++ reference page for pfPipeWindows indicates that the constructor takes no arguments? The documentation just sent me on a wild goose chase looking for *some* C++ method for associating a pfPipe with a pfPipeWindow, since it allegedly isn't done at creation side on the C++ side, the way it is in C. Of course, subsequent inspection (which I should have done sooner :( ) of the header file revealed that the documentation is wrong, and that the pipe is passed into the constructor. Is this a known and subsequently fixed problem, or should I forward this correction off to techpubs@sgi.com? If it's known and fixed, is there available somewhere an errata sheet for the C++ reference pages? thanks, Chris -- Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr@crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 11:53:45 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id LAA21147; Fri, 31 Jan 1997 11:52:40 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id LAA21131; Fri, 31 Jan 1997 11:52:39 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA10334; Fri, 31 Jan 1997 11:52:38 -0800 Received: from bur.visidyne.com (netsafe-outer.bur.visidyne.com [204.180.72.4]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17753 for ; Fri, 31 Jan 1997 11:52:36 -0800 Received: from spock.hsv.visidyne.com (spock.hsv.visidyne.com [207.60.194.10]) by bur.visidyne.com (8.6.11/8.6.6) with SMTP id OAA25347; Fri, 31 Jan 1997 14:51:10 -0500 Organization: Visidyne Inc. Message-Id: <2.2.32.19970131195400.006f7dcc@mail.bur.visidyne.com> X-Sender: sartor@mail.bur.visidyne.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 31 Jan 1997 13:54:00 -0600 To: "Curt Bryan" , From: ken sartor Subject: Re: R4400 vs. R10000 thoughts or benchmarks Status: O At 10:53 AM 1/31/97 -0800, Curt Bryan wrote: >Hello, > >I guess this is really more of a general SGI question but who would know >better than all of you. Has anyone seen any information that offers a >direct comparison between the R4400 and R10000 CPUs. Someone might also >have first-hand experience with them both? The problem I'm having is that >the benchmarks for the R4400 are SPEC92 and SPEC95 for the R10000. I >haven't figured a way to normalize the benchmarks to get an >apples-to-apples comparison. Any help would be appreciated. On applications of interest to me (floating point intensive), i have found a R10000 running at 175 MHz to be 3-4 times faster than a R4400 running at 200 MHz. I had to compile the codes with the n32 flag to get these benefits, and they were *not* graphics applications... Hope this helps. ken ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 13:40:03 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA21881; Fri, 31 Jan 1997 13:38:24 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA21865; Fri, 31 Jan 1997 13:38:23 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA19042; Fri, 31 Jan 1997 13:38:23 -0800 Received: from ns1.bloomberg.com (ns1.bloomberg.com [199.172.169.16]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA12041 for ; Fri, 31 Jan 1997 13:38:20 -0800 Received: from ns2 by ns1.bloomberg.com (5.4R3.10/200.1.1.4) id AA08801; Fri, 31 Jan 1997 16:38:13 -0500 Errors-To: postmaster@ns1.bloomberg.com Received: from [160.43.152.158] by ns2.bloomberg.com (5.4R3.00/200.2.1.5) id AA17389; Fri, 31 Jan 1997 16:38:12 -0500 Message-Id: <9701312138.AA17389@ns2.bloomberg.com> Comments: Authenticated sender is From: "David Mei" Organization: Bloomberg, L.P. To: info-performer@sgi.com Date: Fri, 31 Jan 1997 16:46:05 EST5EDT Subject: performer email list request X-Mailer: Pegasus Mail for Windows (v2.10) Status: O I would like to be added onto Performer mailing list. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 13:55:07 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA21978; Fri, 31 Jan 1997 13:53:40 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA21962; Fri, 31 Jan 1997 13:53:39 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA20214; Fri, 31 Jan 1997 13:53:38 -0800 Received: from discreet.qc.ca (discreet.qc.ca [198.168.76.29]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA15244 for ; Fri, 31 Jan 1997 13:53:34 -0800 Received: by gate.discreet.qc.ca id <46217>; Fri, 31 Jan 1997 17:17:04 -0500 Message-Id: <97Jan31.171704est.46217@gate.discreet.qc.ca> To: steve@mred.bgm.link.com (Steve Baker) cc: info-performer@sgi.com Subject: Re: glDrawPixels speed. In-reply-to: Your message of "Fri, 31 Jan 1997 11:56:59 EST." <9701311656.AA22815@mred.bgm.link.com> Date: Fri, 31 Jan 1997 16:54:09 -0500 From: Jean-Francois Panisset Status: O <9701311656.AA22815@mred.bgm.link.com>Steve Baker writes > >Is there some trick to getting fast 'glDrawPixels'? I'm >trying to dump a 640x480 chunk of image data from main >memory into the frame buffer, using something like: > > glDrawPixels ( WIDTH, HEIGHT, GL_RGB, GL_UNSIGNED_BYTE, buff ) ; > >On infinite reality (2xRM, R10k CPU's) I'm seeing ~12Mbytes per second >and on RE2 (2xRM R4400 CPU's) I'm getting ~7Mbytes per second. > >I recollect hearing figure nearer 100 to 200Mbytes/sec on the iR - am >I mistaken - or is there something wrong here? > >I get better rates than this on my PC at home (admittedly not when using GL)! On an IR driven by R10K CPUs, we have measured sustained rates of around 170MB/sec when doing 720x486 glDrawPixels() in GL_RGB, GL_UNSIGNED_BYTE format. You are mostly bound by the bandwidth between over host to pipe connection, so whether you use GL_RGB, GL_RGBA, GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT data types, the MB/sec bandwidth remains pretty much the same (with correponding variations in mpixels/sec). On a RealityEngine2, we see around 79MB/sec for GL_RGB, GL_UNSIGNED_BYTE OpenGL pixels, about the same for pixmode(PM_SIZE,24) IrisGL pixels. As others have said: pixels in OpenGL are treated the same as polygon-generated fragments, so make sure expensive operations are turned off (including texturing: for some silly reasons, pixels can be textured, even though there is no way to specify texture coordinates). JF Jean-Francois Panisset panisset@discreet.com Software Engineer Discreet Logic ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 13:59:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA22050; Fri, 31 Jan 1997 13:58:32 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA22032; Fri, 31 Jan 1997 13:58:31 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA20509; Fri, 31 Jan 1997 13:58:31 -0800 Received: from rock.csd.sgi.com ([150.166.229.10]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA16296; Fri, 31 Jan 1997 13:58:30 -0800 Received: from quid.csd.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) id NAA20506; Fri, 31 Jan 1997 13:58:29 -0800 Received: by quid.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) id NAA24550; Fri, 31 Jan 1997 13:58:29 -0800 From: "Rob Jenkins" Message-Id: <9701311358.ZM24548@quid.csd.sgi.com> Date: Fri, 31 Jan 1997 13:58:29 -0800 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer-request@sgi.com Subject: (Fwd) performer email list request Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O To be sure of this type of request being honored you should really use the info-performer-request address ( I've forwarded this there too ) Cheers Rob --- Forwarded mail from "David Mei" From: "David Mei" To: info-performer@sgi.com Date: Fri, 31 Jan 1997 16:46:05 EST5EDT Subject: performer email list request I would like to be added onto Performer mailing list. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com ---End of forwarded mail from "David Mei" -- ________________________________________________________________ Rob Jenkins mailto:robj@csd.sgi.com Silicon Graphics, Mtn View, California, USA ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 13:57:27 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id NAA22013; Fri, 31 Jan 1997 13:56:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id NAA21997; Fri, 31 Jan 1997 13:56:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA20376; Fri, 31 Jan 1997 13:56:15 -0800 Received: from mred.bgm.link.com (mred.bgm.link.com [130.210.236.20]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA15784 for ; Fri, 31 Jan 1997 13:56:08 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA24175; Fri, 31 Jan 97 15:50:50 -0500 Date: Fri, 31 Jan 97 15:50:50 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9701312050.AA24175@mred.bgm.link.com> To: info-performer@sgi.com Subject: glDrawPixels. Status: O Never again - NEVER, NEVER!!! It serves me right - I should have stuck with Performer - but Noooo - I had to go and write a RAW OpenGL program. For those who have not been following this thread - I have a *VERY* simple OpenGL program that just does a single glDrawPixels() in a loop. It ought to run faster than 60Hz - it actually runs at 13Hz. Many kind people suggested that I use GL_UNSIGNED_BYTES as the data format and GL_RGB/RGBA/ABGR as the colour organization...I was already doing that (it's IMPORTANT!). Even more kind people gave me long lists of glDisable's to add to the dozen or so that I already have. Also very important - also made no difference. So I go web surfing - YAHOO came up with ~90 references to glDrawPixels, almost all of which were either about Mesa (a really nice freeware OpenGL clone) - were the man page for glDrawPixels, or were copies of the SGI FAQ entry: "Why is OpenGL's glDrawPixels slower than IrisGL's lrectwrite?" ...by Allen Akin. (It says the same things as above - watch your byte ordering and watch the glDisable's). However, by some flook of YAHOO's search engine, right at the bottom of that list of documents was: http://www.andromeda.com/people/ddyer/opengl.html Who says:- > Bug in "Libtk" makes opengl 30% slower than "gl" > > I've seen this question several times: > > > We'd like to start using OpenGL for our graphics programming, but > > it seems to be a lot slower than GL. For instance, glDrawPixels > > appears to be about 30% slower than GL's lrectwrite. Which means > > that it's too slow for us. This is on an SGI Indy(R4600) running IRIX > > 5.3. Is there any way to get the same performance out of OpenGL that > > we get out of GL? > > There are at least two versions of libtk for the SGI floating around,both distributed from > sgigate.sgi.com. The "bad" version is bundledin sgigate.sgi.com > pub/opengl/contrib/opengl.tar.Z, The "other" (maybegood, I don't know) copy is from > pub/opengl/contrib/libtk.tar.Z > > > lido 143 % diff tk.h tk.h.~1~ > 76,77c76,77 > --- /* bad version */ > #define TK_IS_DIRECT(x) (((x) & TK_INDIRECT) == 0) > #define TK_IS_INDIRECT(x) (((x) & TK_INDIRECT) != 0) > --- /* good version */ > #define TK_IS_DIRECT(x) (((x) & TK_INDIRECT) != 0) > #define TK_IS_INDIRECT(x) (((x) & TK_INDIRECT) == 0) Well - being a X11-ophobe, I was using libaux to open my OGL windows - and it looks like it has the same bug as libtk (maybe they sometimes cancel each other out). When I mailed this, my frame rate shot up to 60Hz - the speedup is probably more than 4x since I'm now limited by the frame rate. Boy - it's a big scary world outside of cosy, warm Performer-land isn't it! Thanks to everyone who helped. Steve Steve Baker 817-619-1361 (Vox-Lab) Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail) 2200 Arlington Downs Road 817-619-4028 (Fax) Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail) http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet) http://web2.airmail.net/sjbaker1 (external) "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick. ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 14:37:43 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id OAA22416; Fri, 31 Jan 1997 14:35:16 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA22400; Fri, 31 Jan 1997 14:35:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA24071; Fri, 31 Jan 1997 14:35:15 -0800 Received: from wolfe.net (mail1.wolfe.net [204.157.98.11]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA24926; Fri, 31 Jan 1997 14:35:13 -0800 Received: from gonzo.wolfenet.com (moore@gonzo.wolfenet.com [204.157.98.2]) by wolfe.net (8.8.0/8.8.0) with ESMTP id OAA19485; Fri, 31 Jan 1997 14:36:49 -0800 (PST) From: Timothy Moore Received: (from moore@localhost) by gonzo.wolfenet.com (8.8.3/8.7) id OAA07488; Fri, 31 Jan 1997 14:34:58 -0800 (PST) Date: Fri, 31 Jan 1997 14:34:58 -0800 (PST) Message-Id: <199701312234.OAA07488@gonzo.wolfenet.com> To: dorbie@bitch.reading.sgi.com CC: m-allbright1@ti.com, info-performer@sgi.com In-reply-to: "Angus Dorbie"'s message of Fri, 31 Jan 1997 19:27:21 +0000 <9701311927.ZM18380@bitch.reading.sgi.com> Subject: Re: Non-MultiSample Anti-aliasing Status: O From: "Angus Dorbie" Date: Fri, 31 Jan 1997 19:27:21 +0000 In general anti-aliasing isn't that big a problem for IMPACT for several reasons: 1) trilinear MIP mapping and point sampled polygon edges mean you only need it where texture ID changes or you get a shilouette. 2) You can use a wireline pass very effectively to get high quality blended edges in a scene and can control the load. The fill performance hit is manageable because it's wireline. Cool idea. 3) Soft edge blending alpha textures like tree lines mean you you never need it for blended alpha textures. Don't you then need to depth sort these blended edge polygons? Also, I thought that blending modes are pretty expensive. Tim ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com From guest Fri Jan 31 18:48:38 1997 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer-dist@holodeck.csd.sgi.com id SAA23508; Fri, 31 Jan 1997 18:47:17 -0800 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id SAA23492; Fri, 31 Jan 1997 18:47:16 -0800 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id SAA12461; Fri, 31 Jan 1997 18:47:16 -0800 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA16968; Fri, 31 Jan 1997 18:47:13 -0800 Received: from dskp3.itg.ti.com ([172.25.2.71]) by dragon.ti.com (8.6.13) with ESMTP id SAA13258; Fri, 31 Jan 1997 18:44:19 -0600 Received: from ti (mallbright.dseg.ti.com [172.25.56.33]) by dskp3.itg.ti.com (8.8.3/8.8.2) with SMTP id SAA20742; Fri, 31 Jan 1997 18:43:47 -0600 (CST) X-Mailer: BeyondMail for Windows/Professional 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit To: "Angus Dorbie" , info-performer@sgi.com, mscott@sgi.com From: "Michael M. Allbright" Subject: Re: Non-MultiSample Anti-aliasing Date: Fri, 31 Jan 1997 18:44:46 -0800 X-BeyondMail-Priority: 1 Message-Id: Conversation-Id: <9701311927.ZM18380@bitch.reading.sgi.com> In-Reply-To: <9701311927.ZM18380@bitch.reading.sgi.com> Reply-To: "Michael M. Allbright" X-Receipt-From-Agent: true Status: O Angus: I took your advice and took a look at the Rapier demo on the Octane, however there was really no anti-aliasing evident. Perhaps you have seen a different version? I tried the "w" key to turn on wireframe mode, and the aliasing was even more evident. If you can point me to the version you have seen, it would be very helpful as I must convince management of the efficacy of wireframe anti-aliasing before I can purchase new equipment. Thanks again, --Mike ------------------ Original text From: "Angus Dorbie" , on 1/31/97 7:27 PM: OCTANE can anti-alias in Real Time, read on. Get your sales Rep to show you an OCTANE or Indigo2 IMPACT running the "RAPIER" demo. It anti-aliases the targets using a second pass with textured, lit wireframe. In general anti-aliasing isn't that big a problem for IMPACT for several reasons: 1) trilinear MIP mapping and point sampled polygon edges mean you only need it where texture ID changes or you get a shilouette. 2) You can use a wireline pass very effectively to get high quality blended edges in a scene and can control the load. The fill performance hit is manageable because it's wireline. 3) Soft edge blending alpha textures like tree lines mean you you never need it for blended alpha textures. You may also want to look at ONYX2 Reality, if you must have multisample at IMPACT fill performance but not at 4x cost. Accumulation buffering is expensive, it's multipass + accumulation operations. Lets say you want 4 samples, you have to draw _everything_ four times, geometry and pixel fill, accumulate four images and copy to framebuffer once, simulation death. And that's just for four samples. If you perform the line anti-aliasing mentioned above you get the edge quality equivalent of 256 samples. Thet're not weighted as accurately as multisample but it's a _big_ improvement over no AA in any simulation. Cheers, Angus. On Jan 31, 11:58am, Michael M. Allbright wrote: > Subject: Non-MultiSample Anti-aliasing > Howdy: > > I am considering the purchase of an Octane or two, but I am very concerned > about aliasing. I understand that the Octane does anti-aliasing of points and > lines only--no polygon anti-aliasing. Since the next OpenGL machine capable of > hardware polygon antialiasing seems to be an Onyx IR at about 4 times the > price, I am seriously considering antialiasing using the accumulation buffer > (although I have yet to verify that the accum. buffer will be available on the > Octane in the rendering mode our simulator uses). > > Hence the question: > Can anyone share any hints/tips/tricks/gotchas/code-snippets/algorithms or just > plain old advice on the subject of anti-aliasing using the accumulation buffer, > or similar techniques on Max Impact/Octane level machines? > > Thanks > --Mike > ======================================================================= > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com >-- End of excerpt from Michael M. Allbright ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com