From guest Fri Sep 1 13:49:19 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA04220; Fri, 1 Sep 1995 13:45:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA04217; Fri, 1 Sep 1995 13:45:46 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28326; Fri, 1 Sep 95 13:45:45 -0700 Received: from sgigate.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id NAA22521; Fri, 1 Sep 1995 13:45:44 -0700 Received: from tacom-emh1.army.mil by sgigate.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/940406.SGI) id NAA00388; Fri, 1 Sep 1995 13:45:41 -0700 From: tidrowd@cc.tacom.army.mil Received: from cc-gw.tacom.army.mil by tacom-emh1.army.mil (8.6.12/8.6.12-kbp) with SMTP id QAA01240; Fri, 1 Sep 1995 16:45:31 -0400 Received: from ccMail by cc-gw.tacom.army.mil (IMA Internet Exchange 1.04b) id 04770ff0; Fri, 1 Sep 95 16:45:51 -0400 Mime-Version: 1.0 Date: Fri, 1 Sep 1995 10:41:09 -0400 Message-Id: <04770ff0@cc-gw.tacom.army.mil> To: info-performer@sgihub.corp.sgi.com, "Michael Jones" Subject: Re[2]: Performer 1.2, IRIX 6.1 Content-Type: multipart/mixed; boundary="IMA.Boundary.153889908" Status: O This is a MIME encapsulated message. --IMA.Boundary.153889908 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >On Aug 31, 6:41pm, Carlo L. Tiana wrote: >> Subject: Performer 1.2, IRIX 6.1 >: >:I am considering upgrading my PowerIndigo 2 Extreme to IRIX 6.1. >:I am currently running Performer 1.2 under 6.0.1 quite successfully. >:I was wondering if I will still be able to run Performer 1.2 under >:IRIX 6.1 as successfully. Any comments would be appreciated. >:Thanks, >:Carlo. >: >>-- End of excerpt from Carlo L. Tiana > >It will continue to work (1.2 on 6.1). vvvvvvvvvvvvvvvvvvv Define 'soon', please!!!! >In addition, the soon to be released IRIS Performer 2.0 will >allow 64-bit compiles. > >-- > >Be seeing you, Phone:415.390.1455 Fax:415.965.2658 M/S:8U-590 >Michael T. Jones Silicon Graphics, Advanced Systems Division >mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 > "Du musst Amboss oder Hammer sein" -- Goethe Don Tidrow Visual Simulation Developer US Amry Tank-automotive and Armaments Command --IMA.Boundary.153889908-- From guest Fri Sep 1 11:18:56 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA03769; Fri, 1 Sep 1995 11:16:04 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA03766; Fri, 1 Sep 1995 11:16:04 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22515; Fri, 1 Sep 95 11:16:02 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA01393; Fri, 1 Sep 1995 11:16:00 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA22505; Fri, 1 Sep 95 11:15:58 -0700 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA24359; Fri, 1 Sep 1995 11:15:56 -0700 From: "Michael Jones" Message-Id: <9509011115.ZM24357@babar.asd.sgi.com> Date: Fri, 1 Sep 1995 11:15:55 -0700 In-Reply-To: "Carlo L. Tiana" "Performer 1.2, IRIX 6.1" (Aug 31, 6:41pm) References: <199509010141.SAA05906@descartes.arc.nasa.gov> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Carlo L. Tiana" , info-performer@sgi.sgi.com Subject: Re: Performer 1.2, IRIX 6.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Aug 31, 6:41pm, Carlo L. Tiana wrote: > Subject: Performer 1.2, IRIX 6.1 : :I am considering upgrading my PowerIndigo 2 Extreme to IRIX 6.1. :I am currently running Performer 1.2 under 6.0.1 quite successfully. :I was wondering if I will still be able to run Performer 1.2 under :IRIX 6.1 as successfully. Any comments would be appreciated. :Thanks, :Carlo. : >-- End of excerpt from Carlo L. Tiana It will continue to work (1.2 on 6.1). In addition, the soon to be released IRIS Performer 2.0 will allow 64-bit compiles. -- Be seeing you, Phone:415.390.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Mon Sep 4 18:25:16 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA08220; Mon, 4 Sep 1995 18:13:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA08217; Mon, 4 Sep 1995 18:13:14 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18901; Mon, 4 Sep 95 18:13:14 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id SAA22682; Mon, 4 Sep 1995 18:13:02 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id LAA06759 (8.6.12/IDA-1.6); Tue, 5 Sep 1995 11:12:12 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA13159 (5.65c/IDA-1.5); Tue, 5 Sep 1995 10:55:50 +1000 Received: from zippy (zippy [1.0.0.79]) by aggro with ESMTP id LAA08563 (8.6.12/IDA-1.6); Tue, 5 Sep 1995 11:03:01 +1000 Received: by zippy (8.6.11) id LAA01574; Tue, 5 Sep 1995 11:02:59 +1000 Date: Tue, 5 Sep 1995 11:02:52 +1000 (BEST) From: Simon Bennett X-Sender: simonb@zippy To: Lance Marrou Cc: Robert Reif , info-performer Subject: Re: user defined cursor? In-Reply-To: <9508291950.ZM6563@lost-ark.vsl.ist.ucf.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Tue, 29 Aug 1995, Lance Marrou wrote: > On Aug 29, 7:07pm, Robert Reif wrote: > > Subject: user defined cursor? > > Is there a way to specify your own cursor in X input mode? I am able to > > create my own cursor but it gets replaced by the Performers cursor when > > pfuInitInput is called. If I select a non-existent cursor, I can use my > > cursor but I get constant warnings about a non-existent cursor selected. > > I know I can change the pfu code but I would rather not. It's really the only way in 1.2, you only have to change "input.c" pfuInitInput() forks off another process, which asynchronously collect the Xevents, it's also the process with the pointer to the Display - so if you need access to this, it really needs to be done from this process. I'm surprised your cursor code is working at all... > extern void pfuCursor(long _target, long _c); > extern void pfuCursorSel(long _sel); > extern long pfuGetCursorSel(void); > extern long pfuGetCursor(long _target); The main problem with these calls however is that you can only set the cursor to those defined in the "cursor" font... which is fine if you need a gumby cursor :) Neither do they let you specify the mask or colours - which means they don't provide an easy way to remove the cursor in a GLX window - there is no equivalent to GL's cursoff() - you have to edit input.c > code." Is it that you tried the above functions and they did not work > correctly? These functions work fine, they just don't go the distance. That's not really fair thou I guess, they do provide a nice simple interface to X's "interteresting" cursor handling functions. If it's portability to the future you're worried about, then I wouldn't be concerned with editing input.c or any pfu code - as the doco says it's unsupported. In addition - this stuff will have to be tidied up and rearranged for future versions of Performer as OpenGL versions are supported. +----------------------------------------------------------------------------+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 9981 0611 (x512) Meeting - an event where you take minutes and waste hours. From guest Mon Sep 4 23:26:39 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA08560; Mon, 4 Sep 1995 23:24:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id XAA08557; Mon, 4 Sep 1995 23:24:44 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23765; Mon, 4 Sep 95 23:24:44 -0700 Received: from han.hana.nm.kr by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id XAA19361; Mon, 4 Sep 1995 23:16:00 -0700 Received: from saitgw.Sait.Samsung.Co.KR by han.hana.nm.kr (4.1/KUM-0.1) id AA02967; Tue, 5 Sep 95 15:19:18 KST Received: from chagal (chagal.sait.samsung.co.kr) by saitgw.Sait.Samsung.Co.KR (4.1/SMI-4.1) id AA16237; Tue, 5 Sep 95 13:01:17 KDT Received: by chagal (950215.SGI.8.6.10/940406.SGI) for info-performer@sgi.com id NAA25003; Tue, 5 Sep 1995 13:01:50 +1000 From: chaos@chagal.hana.nm.kr (Cho Tae Hee) Message-Id: <199509050301.NAA25003@chagal> Subject: glowing effect using pfLightPoint To: info-performer@sgi.sgi.com Date: Tue, 5 Sep 1995 13:01:50 +1000 (KST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Content-Length: 620 Status: O Hi everyone, I have a question about the pfLightPoint. The Programmers' guide says that using pfLightPoint, one can generate image like star or street light. I wanna make a "radar". This radar consists of a scan line and object points. scan line scans the entire space counterclockwise and if the scan line is near the object point, object point glows.(just like that in sonar system of 2'nd World War movie) What is difficult to me is that I can't make glowing effect of a point using pfLightPoint or other techniques... Any hints or suggestions will be greatly appreciated. chaos@venus.sait.samsung.co.kr From guest Mon Sep 4 22:04:10 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA08421; Mon, 4 Sep 1995 22:02:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA08418; Mon, 4 Sep 1995 22:02:18 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22424; Mon, 4 Sep 95 22:02:17 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id WAA12457; Mon, 4 Sep 1995 22:02:15 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA22420; Mon, 4 Sep 95 22:02:13 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA14034; Mon, 4 Sep 1995 22:02:12 -0700 Message-Id: <199509050502.WAA14034@surreal.asd.sgi.com> To: "Carlo L. Tiana" Cc: info-performer@sgi.sgi.com Subject: Re: Performer 1.2, IRIX 6.1 In-Reply-To: Your message of "Thu, 31 Aug 95 18:41:08 PDT." <199509010141.SAA05906@descartes.arc.nasa.gov> Date: Mon, 04 Sep 95 22:02:12 -0700 From: Jim Helman Status: O Performer 1.2 works under 6.1, except for a bug in 1.2 that prevents the use of an XFS (the replacement for the older EFS) filesystem as for Performer shared memory and semaphores. There are a number of workarounds: 1) Use an EFS root filesystem 2) set PFTMPDIR to an EFS file system 3) reorder the device types in the kernel configuration files and build a new kernel. 4) wait ;-) for 2.0. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Sep 5 10:27:32 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA09091; Tue, 5 Sep 1995 10:24:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA09088; Tue, 5 Sep 1995 10:24:16 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08127; Tue, 5 Sep 95 10:24:15 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA23101; Tue, 5 Sep 1995 10:24:09 -0700 Received: from dean.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) id KAA05040; Tue, 5 Sep 1995 10:23:43 -0700 Received: by dean.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA06206; Tue, 5 Sep 1995 10:21:18 -0700 From: "scohen" Message-Id: <9509051021.ZM6204@dean.electrogig.com> Date: Tue, 5 Sep 1995 10:21:16 -0700 In-Reply-To: "Joerg Leisenberg" "Performer and Spaceball" (May 25, 6:41pm) References: <9505251841.ZM3277@immd9.informatik.uni-erlangen.de> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Joerg Leisenberg Subject: Re: Performer and Spaceball Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Joerg, We are trying to integrate a spaceball (Logitech - Magellan) with Performer. Did you ever solve this problem and could you give us some advice on how you did this. Currently, we've got our spaceball working in Inventor, but would like to extend our interface to Performer. Thanking you in advance, Steve Cohen From guest Tue Sep 5 13:59:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA09650; Tue, 5 Sep 1995 13:54:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA09647; Tue, 5 Sep 1995 13:54:23 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17985; Tue, 5 Sep 95 13:54:20 -0700 Received: from mail.Germany.EU.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA02998; Tue, 5 Sep 1995 13:54:02 -0700 Received: by mail.Germany.EU.net with SMTP (5.59:8/EUnetD-2.5.2.a) via EUnet id SAA02990; Tue, 5 Sep 1995 18:41:48 +0200 Received: from AITEC/TEMPQ by aitec.de (Mercury 1.13); Tue, 5 Sep 95 18:39:54 GMT Received: from TEMPQ by AITEC (Mercury 1.13); Tue, 5 Sep 95 18:39:38 GMT From: "Dr. Aris Christidis" Organization: AITEC GmbH & Co KG To: info-performer@sgi.sgi.com Date: Tue, 5 Sep 1995 18:39:35 GMT+1 Subject: Swapbuffer control problems in multipipe mode X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <4EB1C972ACF@aitec.de> Status: O Hello! As Michael T. Jones had already confirmed, there is a bug concerning the swapbuffer control in PF1.2; it consists in that, when the DRAW process gets ready within 1/60 sec, the buffer swaps at the next vertical retrace period, even if pfFrameRate is set to 30 and pfPhase is PFPHASE_LOCK. While running our application in single pipe mode, we had our own swap control function (declared in pfPipeSwapFunc), which forced the DRAW process (from the second frame on) to wait until the next frame boundary: void SwapPipe (pfPipe *pipe) { static double t1=0, t2=0; t2 = pfGetTime (); while ((t2-t1) < 1/30.) t2 = pfGetTime (); t1 = t2; swapbuffers(); } Currently we are changing our application from single pipe to multipipe mode and we found out that our workaround does not work any more. The same effect occurs also when using PFPHASE_FLOAT or PFPHASE_LIMIT and of course if we don't use any workaround. Any suggestions? ???????????????????????????? Best regards, Aris ChristidisAITEC GmbH & CO Informationstechnologie KG Dr. Aris Christidis Alter Hellweg 50 D-44379 Dortmund Tel.: +49 231 9646545 Fax.: +49 231 9646598 EMail: ac@aitec.de From guest Tue Sep 5 15:27:48 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA10095; Tue, 5 Sep 1995 15:20:53 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA10092; Tue, 5 Sep 1995 15:20:48 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22728; Tue, 5 Sep 95 15:20:41 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA28788; Tue, 5 Sep 1995 15:20:32 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id PAA06604; Tue, 5 Sep 1995 15:20:03 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id PAA03348; Tue, 5 Sep 1995 15:19:28 -0700 From: "AnitaKishore" Message-Id: <9509051519.ZM3346@lee.electrogig.com> Date: Tue, 5 Sep 1995 15:19:26 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfIsTexLoaded question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I am trying to test out the texture downloading mechanisms as described in /usr/share/Performer/src/pguide/libpf/examples/download.doc. When I use the function pfIsTexLoaded in the draw process before using pfuDownloadTexList, it always returns TRUE, even the first time when the draw callback is invoked. It returns TRUE even in the main routine, just after registering the draw callback. Am I not using these APIs correctly? Any help will be greatly appreciated. I am including the source code for anybody interested in having a look at it. It is very small :-) thanks in advance -anita --------------------------------------------------------------------------- Anita Kishore kishore@electrogig.com --------------------------------------------------------------------------- #include #include #include #include extern "C" { extern pfNode* pfdLoadFile (char *fileName); } void DrawChannel(pfChannel *chan, void *data); typedef struct _SharedData { pfList *texList; } SharedData; SharedData *shData; int main(int argc, char *argv[]) { pfScene *scene; pfPipe *p; pfChannel *chan; pfGroup *root; pfCoord view; if (argc<2) { printf("Input data file....\n"); exit(1); } pfInit(); shData = (SharedData *) pfMalloc(sizeof(SharedData), pfGetSharedArena()); pfConfig(); pfuInitUtil(); scene = pfNewScene(); if (pfGetFilePath() == NULL) pfFilePath(".:/disk4/people/kishore/performer/data"); if ((root = (pfGroup *)pfdLoadFile(argv[1])) == NULL) { printf("Unable to create scene data base....\n"); pfExit(); exit(-1); } pfAddChild(scene, root); shData->texList = pfuMakeTexList((pfNode *)root); p = pfGetPipe(0); chan = pfNewChan(p); pfChanScene(chan, scene); pfChanNearFar(chan, 1, 10000); pfChanAspect(chan, PFFRUST_CALC_VERT, 1.3333); pfChanFOV(chan, 140, -1); pfSetVec3(view.hpr, 0, 0, 0); pfSetVec3(view.xyz, 0, -50, 60); pfChanView(chan, view.xyz, view.hpr); pfFrameRate(60.0f); pfPhase(PFPHASE_LOCK); pfChanTravFunc(chan, PFTRAV_DRAW, DrawChannel); const pfTexture *tex = (pfTexture *) pfGet(shData->texList, 0); if (pfIsTexLoaded(tex)) printf("main : Texture already loaded\n"); for (;;) { pfSync(); pfFrame(); } } void DrawChannel(pfChannel *chan, void *data) { (chan, data); pfClearChan(chan); const pfTexture *tex = (pfTexture *) pfGet(shData->texList, 0); if (pfIsTexLoaded(tex)) printf("Texture already loaded\n"); else { printf("Loading Texture\n"); pfuDownloadTexList(shData->texList, PFUTEX_APPLY); } pfDraw(); } From guest Tue Sep 5 17:08:55 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA10597; Tue, 5 Sep 1995 17:05:13 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA10592; Tue, 5 Sep 1995 17:05:12 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29317; Tue, 5 Sep 95 17:05:11 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA01163; Tue, 5 Sep 1995 17:05:00 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id RAA07096; Tue, 5 Sep 1995 17:04:32 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id RAA03530; Tue, 5 Sep 1995 17:03:58 -0700 From: "AnitaKishore" Message-Id: <9509051703.ZM3528@lee.electrogig.com> Date: Tue, 5 Sep 1995 17:03:56 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfIsTexLoaded question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I found out the reason to my question in the previous mail. So please disregard the mail. For people who are interested in knowing it, I was running the program remotely on a machine that has no texture memory, so I guess pfIsTexLoaded always returns TRUE. When I ran it on the RE2 directly, I got the expected result! Thanks for your time -anita From guest Tue Sep 5 17:20:25 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA10654; Tue, 5 Sep 1995 17:14:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA10651; Tue, 5 Sep 1995 17:14:09 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00088; Tue, 5 Sep 95 17:14:08 -0700 Received: from cs.utah.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA03680; Tue, 5 Sep 1995 17:14:05 -0700 Received: from real.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs) id SAA10887; Tue, 5 Sep 1995 18:14:04 -0600 Received: by real.cs.utah.edu (940816.SGI.8.6.9/utah-2.15sun-leaf) id SAA29106; Tue, 5 Sep 1995 18:14:39 -0600 Date: Tue, 5 Sep 1995 18:14:39 -0600 From: dpugmire@real.cs.utah.edu (David Pugmire) Message-Id: <199509060014.SAA29106@real.cs.utah.edu> To: info-performer@sgi.sgi.com Subject: Modelling tips for best performance Status: O Hi, I'm new to performer, and am trying to get a feel for the proper way to model so as to best utilize IRIS Performer. I'd love to get some advice from some of you gurus out there. I hunted around in the topics section of the Performer web page, but didn't seem to find anything on this. For instance: I've heard that using stencils is very expensive. Avoid using it. This came from a discussion about using subfaces in MultiGen. Generate more polygons instead. A Question: I thought I read somewhere that placing texture u,v coords a certain way (?? like putting u,v=0,0 on a vertex ??) was faster. Did I hear right ? It's hard coming up with good questions because I'm so new. Any comments greatly appreciated. thanks, dp. From guest Tue Sep 5 15:41:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA10191; Tue, 5 Sep 1995 15:37:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA10188; Tue, 5 Sep 1995 15:37:33 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23826; Tue, 5 Sep 95 15:37:32 -0700 Received: from faui45.informatik.uni-erlangen.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA03745; Tue, 5 Sep 1995 15:36:11 -0700 Received: from immd9.informatik.uni-erlangen.de (faui90.informatik.uni-erlangen.de [131.188.39.4]) by uni-erlangen.de with ESMTP id WAA07219 (8.6.12/7.4f-FAU); for ; Tue, 5 Sep 1995 22:08:35 +0200 Received: from faui90r.informatik.uni-erlangen.de by immd9.informatik.uni-erlangen.de with SMTP; id WAA14794 (940816.SGI.8.6.9/7.3m-FAU); Tue, 5 Sep 1995 22:08:33 +0200 From: "Joerg Leisenberg" Message-Id: <9509052208.ZM22098@immd9.informatik.uni-erlangen.de> Date: Tue, 5 Sep 1995 22:08:33 -0600 In-Reply-To: "scohen" "Re: Performer and Spaceball" (Sep 5, 10:21am) References: <9505251841.ZM3277@immd9.informatik.uni-erlangen.de> <9509051021.ZM6204@dean.electrogig.com> Reply-To: Joerg Leisenberg X-Face: xDr}R<\Uo*94w4!\SzF(#?hd&jn-PrYjrXMF]0T>|knWu<3r_){_]AbAcu{Mih|Ae%2xwiq f8:SnyF(;>w*2K~ X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Performer and Spaceball Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > > We are trying to integrate a spaceball (Logitech - Magellan) with Performer. > Did you ever solve this problem and could you give us some advice on how you > did this. Currently, we've got our spaceball working in Inventor, but would > like to extend our interface to Performer. > I don't know how Performer 2.0 handles external devices (if it will be released at all :) but this is what I know for 1.2: a) You're using GL for input ----------------------------- Kent Miller has mailed a solution a few months ago: - look at the code in /usr/src/Performer/src/lib/pfutil/input.[ch] It's pretty straightforward, and you'll feel better once you're familiar with it. - queue the spaceball device events (see device.h for SB events) - register your spaceball input handler with pfuAddInputHandler, and use the PFU_CATCH_UNKNOWN parameter so normal keyboard and mouse events get handled first. - you can ignore the custom event struct that gets passed to your handler, since it's just used by CATCH_ALL to pass events back to the pfu calling routine. - treat the dev and val args like normal GL events. b) You're using X11 for input ----------------------------- Extending the pfu handler (as above) is *NOT* possible if you're using the pfu API. Why? - To Use XExtensionEvents you have to open the XDevice "spaceball" and you have to select particular XExtensionEvents. This has to be done from the process that read's the X events which is (unfortunately) a separate process forked by pfuInitInput. - You can't use the custom event struct because XExtensionEvents will not come one by one (as queued gl devices). They will come with a complete snapshot of all 6 dimensions. That means you have to generate 6 custom events (one dimensional!) for each XExtensionEvent. That's not possible. If you're not using the custom event struct than you've to handle the events directly out of your handler (i.e. the function added with pfuAddInputHandler). Be aware that your code is executed from a separate process (the input process) and therefore variables must be placed in shared memory etc pp. I've written a complete X11 Event handler able to read keyboard, mouse and spaceball - just drop me a line if you're interested. Regards, Joerg -- _____________________________________________________________________________ Joerg Leisenberg jgleisen@immd9.informatik.uni-erlangen.de * PGP Key available _____________________________________________________________________________ From guest Wed Sep 6 21:15:02 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA17550; Wed, 6 Sep 1995 21:11:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA17547; Wed, 6 Sep 1995 21:11:40 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14464; Wed, 6 Sep 95 21:11:38 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id VAA14478; Wed, 6 Sep 1995 21:11:35 -0700 Received: from death.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id BAA15699; Wed, 6 Sep 1995 01:11:56 -0700 Received: by death.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id JAA01770; Wed, 6 Sep 1995 09:08:13 +0100 From: "Angus Henderson" Message-Id: <9509060908.ZM1768@death.reading.sgi.com> Date: Wed, 6 Sep 1995 09:08:12 +0100 In-Reply-To: "Dr. Aris Christidis" "Swapbuffer control problems in multipipe mode" (Sep 5, 6:39pm) References: <4EB1C972ACF@aitec.de> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Dr. Aris Christidis" , info-performer@sgi.sgi.com Subject: Re: Swapbuffer control problems in multipipe mode Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Draw MOre Graphics ANgus From guest Wed Sep 6 10:07:17 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA13109; Wed, 6 Sep 1995 10:01:40 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA13106; Wed, 6 Sep 1995 10:01:39 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04563; Wed, 6 Sep 95 10:01:37 -0700 Received: from sgidev.mdc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA06383; Wed, 6 Sep 1995 10:01:22 -0700 Received: from control.mdc.com by sgidev.mdc.com via SMTP (920213.SGI.UNSUPPORTED.PROTOTYPE/920323.SGI.UNSUPPORTED.PROTOTYPE) for info-performer@sgi.com id AA19661; Wed, 6 Sep 95 08:22:31 -0700 Received: by control.mdc.com (940816.SGI.8.6.9/910805.SGI) id JAA08633; Wed, 6 Sep 1995 09:11:39 -0700 From: "Bryan Larson" Message-Id: <9509060911.ZM8631@control.mdc.com> Date: Wed, 6 Sep 1995 09:11:38 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Bluring in Performer Cc: bryan@control.mdc.com, sal@control.mdc.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I am trying to blur a scene in performer. I have used a section of the example given by SGI called 'geomblur.c'. The following is my blur.c routine: #include #include #include #include #include static float geom = 0.; void blur(pfChannel *chan, void *data) { pfClearChan(chan); pfDraw(); acbuf(AC_MULT, .8); acbuf(AC_ACCUMULATE, 1.0); geom = geom*.8 + 1.0; acbuf(AC_RETURN, 1.0/geom); } This routine then replaces the prDraw function in the Perfly file 'main.c' I would expect this to blur the image, even if it is generated in Performer, but is does not seem to work. I don't get a core dump and perfly can load files ok, but they don't seem to blur. The question is ... Am I / Can I use the accumulation buffer in this manner to blur an image in Performer? Am I using this correctly? Is there any hints / advice to bluring an image in Performer? Thanks -- talk to ya Bryan _____________________________________________________________________ | Bryan Larson | bryan@sgidev.mdc.com McDonnell Douglas | (310) 593-6766 | --------------------------------------------------------------------- From guest Wed Sep 6 12:59:15 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA13562; Wed, 6 Sep 1995 12:56:13 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA13559; Wed, 6 Sep 1995 12:56:12 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14121; Wed, 6 Sep 95 12:56:11 -0700 Received: from inesc.inesc.pt by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA08018; Wed, 6 Sep 1995 12:55:49 -0700 Received: from phortos (phortos.inesc.pt) by inesc.inesc.pt with SMTP; id AA22986 (/); Wed, 6 Sep 1995 11:39:03 +0200 Received: by phortos (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.com id LAA19053; Wed, 6 Sep 1995 11:38:36 +0200 From: "Jose Carlos Andre" Message-Id: <9509061138.ZM19051@phortos.inesc.pt> Date: Wed, 6 Sep 1995 11:38:35 -0600 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Unsubscribe me please. -- Jose' Carlos Andre' jca@phortos.inesc.pt INESC - Centro Multimedia, AudioVisuais http://www-cm.inesc.pt From guest Thu Sep 7 08:51:35 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA18324; Thu, 7 Sep 1995 08:47:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA18321; Thu, 7 Sep 1995 08:47:43 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04461; Thu, 7 Sep 95 08:47:42 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA19451; Thu, 7 Sep 1995 08:47:40 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id IAA20559; Thu, 7 Sep 1995 08:47:38 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id QAA08459; Thu, 7 Sep 1995 16:34:27 +0100 From: "Rob Jenkins" Message-Id: <9509071634.ZM8457@barney.reading.sgi.com> Date: Thu, 7 Sep 1995 16:34:25 +0100 In-Reply-To: "Angus Dorbie" "Re: Swapbuffer control problems in multipipe mode" (Sep 7, 4:53pm) References: <4EB1C972ACF@aitec.de> <9509071653.ZM2039@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Angus Dorbie" , "Dr. Aris Christidis" Subject: Re: Swapbuffer control problems in multipipe mode Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 7, 4:53pm, Angus Dorbie wrote: > Subject: Re: Swapbuffer control problems in multipipe mode > > Currently we are changing our application from single pipe > > to multipipe mode and we found out that our workaround does not > > work any more. The same effect occurs also when using PFPHASE_FLOAT > > or PFPHASE_LIMIT and of course if we don't use any workaround. > > > > Any suggestions? > > ???????????????????????????? > > Try using mswapbuffers with gangdraw. You should genlock the pipes -g + SYNC > to GEN IN (GEN OUT to GEN IN & terminate last GEN OUT) and then wire up the > swapready connections. > > > -- > Angus Dorbie, > Silicon Graphics Ltd, UK > dorbie@reading.sgi.com >-- End of excerpt from Angus Dorbie There is some good documentation and example code for this - let me know if you want it. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Thu Sep 7 10:24:59 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA18571; Thu, 7 Sep 1995 10:16:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA18566; Thu, 7 Sep 1995 10:16:17 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10910; Thu, 7 Sep 95 10:16:15 -0700 Received: from relay1.oleane.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA10552; Thu, 7 Sep 1995 10:16:11 -0700 Received: from corysmailserv (mailhost.corys.fr [194.2.225.1]) by relay1.oleane.net (8.6.10/8.6.9) with SMTP id TAA15573 for ; Thu, 7 Sep 1995 19:16:02 +0200 Received: from quartz. by corysmailserv (5.x/SMI-SVR4) id AA27361; Thu, 7 Sep 1995 19:05:02 +0200 Received: by quartz. (950511.SGI.8.6.12.PATCH526/940406.SGI) for info-performer@sgi.com id SAA03707; Thu, 7 Sep 1995 18:53:23 +0200 From: "Lionel Maiaux" Message-Id: <9509071853.ZM3705@quartz> Date: Thu, 7 Sep 1995 18:53:23 +0100 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Cost of two-sided lighting ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, I read several times that two-sided lighting (set with pfLModelTwoSide) is expensive (I suppose the extra-cost depend from IRIS or OPEN GL light model). Is it more expensive to draw 1 face with two-sided lighting and backface culling off, or to draw 2 oposite faces whith one-sided lighting and backface culling on to get the same results ? If yes, on which stage of the pipeline and why ??? From guest Thu Sep 7 11:29:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA18823; Thu, 7 Sep 1995 11:24:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA18820; Thu, 7 Sep 1995 11:24:30 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15904; Thu, 7 Sep 95 11:24:29 -0700 Received: from cs.sfu.ca by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA01944; Thu, 7 Sep 1995 11:24:26 -0700 From: halliday@cs.sfu.ca Received: from mayne (mayne.cs.sfu.ca) by cs.sfu.ca with SMTP id AA10254 (5.65c/IDA-1.4.4 for <@fornax.cs.sfu.ca:info-performer@sgi.com>); Thu, 7 Sep 1995 11:07:08 -0700 Received: by mayne (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id LAA01068; Thu, 7 Sep 1995 11:07:06 -0700 Message-Id: <199509071807.LAA01068@mayne> Subject: pfInit & pfInitClock To: info-performer@sgi.sgi.com Date: Thu, 7 Sep 1995 11:07:03 -0800 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1470 Status: O HELP! I am getting a very strange behaviour. Sometimes my program runs fine and other times I get a machine lockup. Just before the machine locks up, the CPU SYS activity goes way up and I can not kill -9 the process. I can do a kill -5 to get a core, but the process still doesn't die! Here is what I get from DBX: 0 _pause(0x0, 0x10157e40, 0x10157e50, 0x1) ["pause.s":15, 0xfae2478] 1 _pfWrapTime(0x5cf090, 0x10157e40, 0x10157e50, 0x1) ["../../../lib/libpr/time.c":385, 0x5cee0c] 2 pfInitClock(0x0, 0x10157e40, 0x10157e50, 0x1) ["../../../lib/libpr/time.c":285, 0x5ce970] 3 pfInit(0x0, 0x10157e40, 0x10157e50, 0x1) ["../../../lib/libpf/pfProcess.C":545, 0x56cdac] From guest Thu Sep 7 08:04:05 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA18210; Thu, 7 Sep 1995 08:00:55 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA18207; Thu, 7 Sep 1995 08:00:54 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02497; Thu, 7 Sep 95 08:00:53 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA10993; Thu, 7 Sep 1995 08:00:50 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/940406.SGI) id QAA02041; Thu, 7 Sep 1995 16:53:13 +0200 From: "Angus Dorbie" Message-Id: <9509071653.ZM2039@bitch.reading.sgi.com> Date: Thu, 7 Sep 1995 16:53:13 -0600 In-Reply-To: "Dr. Aris Christidis" "Swapbuffer control problems in multipipe mode" (Sep 5, 6:39pm) References: <4EB1C972ACF@aitec.de> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Dr. Aris Christidis" Subject: Re: Swapbuffer control problems in multipipe mode Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > Currently we are changing our application from single pipe > to multipipe mode and we found out that our workaround does not > work any more. The same effect occurs also when using PFPHASE_FLOAT > or PFPHASE_LIMIT and of course if we don't use any workaround. > > Any suggestions? > ???????????????????????????? Try using mswapbuffers with gangdraw. You should genlock the pipes -g + SYNC to GEN IN (GEN OUT to GEN IN & terminate last GEN OUT) and then wire up the swapready connections. -- Angus Dorbie, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Fri Sep 8 03:14:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA21255; Thu, 7 Sep 1995 23:47:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id XAA21252; Thu, 7 Sep 1995 23:47:16 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18264; Thu, 7 Sep 95 23:46:18 -0700 Received: from relay1.oleane.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id XAA28397; Thu, 7 Sep 1995 23:46:09 -0700 Received: from corysmailserv (mailhost.corys.fr [194.2.225.1]) by relay1.oleane.net (8.6.10/8.6.9) with SMTP id IAA26077 for ; Fri, 8 Sep 1995 08:46:07 +0200 Received: from quartz. by corysmailserv (5.x/SMI-SVR4) id AA27661; Fri, 8 Sep 1995 08:37:26 +0200 Received: by quartz. (950511.SGI.8.6.12.PATCH526/940406.SGI) for info-performer@sgi.com id IAA04320; Fri, 8 Sep 1995 08:25:45 +0200 From: "Lionel Maiaux" Message-Id: <9509080825.ZM4318@quartz> Date: Fri, 8 Sep 1995 08:25:44 +0100 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Backface culling ! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Sean, You don't reply to my question but I have another one for you. You said : > One thing I've done, is to have pre and post draw callbacks to > turn backface on and off on geometry that should have backfaces. Why don't you attach a Geostate with the PFSTATE_CULLFACE mode set to PF_OFF to these geometries ??? From guest Fri Sep 8 17:20:33 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA23569; Fri, 8 Sep 1995 17:13:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA23566; Fri, 8 Sep 1995 17:13:07 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14029; Fri, 8 Sep 95 17:12:55 -0700 Received: from rasputin.engr.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id RAA16012; Fri, 8 Sep 1995 17:12:59 -0700 Received: by rasputin.engr.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id RAA02388; Fri, 8 Sep 1995 17:16:59 -0700 From: "Susan Raskin" Message-Id: <9509081716.ZM2386@rasputin.engr.sgi.com> Date: Fri, 8 Sep 1995 17:16:54 -0700 X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: info-performer@sgihub.corp.sgi.com Subject: Iris Performer MTS Position at Silicon Graphics Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Silicon Graphics has an opening in its Performer development team for a software engineer with demonstrated design and programming skills. This engineer will focus on classic visual simulation issues such as light points, landing lights, atmospheric simulation, and terrain processing. This engineer will work as part of a small team to design and implement these features and will also travel as needed to interact with customers. This challenging position requires a broad background in visual simulation and a minimum of three years experience in C and C++ programming. Experience with real-time systems, multiprocessing, Iris Performer and the Unix programming environment are preferred. To apply for this position, email resume to sraskin@sgi.com, fax to 415-933-0980, or call Susan Raskin at 415-390-4523. Silicon Graphics is an equal opportunity employer. Principals only, please. From guest Fri Sep 8 17:58:10 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA23956; Fri, 8 Sep 1995 17:49:28 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA23953; Fri, 8 Sep 1995 17:49:27 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16962; Fri, 8 Sep 95 17:49:23 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id RAA27972; Fri, 8 Sep 1995 17:49:23 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA16952; Fri, 8 Sep 95 17:49:11 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id RAA16893; Fri, 8 Sep 1995 17:46:38 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199509090046.RAA16893@tubes.asd.sgi.com> Subject: Re: Fog with projected textures. To: guest (Robert Webb) Date: Fri, 8 Sep 95 17:46:38 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: ; from "Robert Webb" at Aug 3, 95 12:42 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > Hi guys, > > It's me again, and I'm still trying to get my projected textures working > properly. Just one problem left! (I think). > > I am doing two passes of pfDraw() in the one draw traversal callback. The > first pfDraw draws everything in a grey colour that represents the colour of > the ambient light, and resolves the zbuffer in preparation for the second > pass. > > The second pass uses zfunction(ZF_EQUAL) to ensure that each pixel is > touched only once, and also uses this: > blendfunction(BF_DC, BF_ZERO); > instead of the usual: > blendfunction(BF_ONE, BF_ZERO); > > This means instead of each pixel getting set to the SOURCE colour, it is set > to SOURCE*DEST, ie it is multiplied by the colour which is already there > (and represents the ambient lighting). > > HOWEVER! It seems the SOURCE colour includes the colour adjustment caused > by the fog, even though I really want fog to be added later. This means > that the fog colour is also being multiplied by the DEST colour, hence > making my fog seem darker for the geometry which goes through this projected > texture process (lightpoints etc do not, and hence have the normal fog, > making them appear light grey while everything else is a darker grey, for > very thick fog). > > HELP! Someone must have tackled this before. Someone must have used fog > with projected textures successfully. How is it done? > 2.0 has formal support for projected textures and is implemented as follows: 1. Clear screen. Place ambient in alpha bitplanes. 2. With wmpack(0x00ffffff), draw normal, textured, fogged scene. 3. With wmpack(0xffffffff), ZEQUAL, and blendfunction(BF_DC, BF_DA), draw projected texture scene. I'm not sure if you are using fog normally are as a means of range-attenuating the light source. Note that you don't need to clear to ambient color - instead you can place ambient in your projected texture. From guest Fri Sep 8 18:58:44 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA24388; Fri, 8 Sep 1995 18:45:28 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA24385; Fri, 8 Sep 1995 18:45:28 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20719; Fri, 8 Sep 95 18:45:20 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id SAA08279; Fri, 8 Sep 1995 18:45:21 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA20715; Fri, 8 Sep 95 18:45:12 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id SAA17121; Fri, 8 Sep 1995 18:42:39 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199509090142.SAA17121@tubes.asd.sgi.com> Subject: Re: Swapbuffer control problems in multipipe mode To: guest (Dr. Aris Christidis) Date: Fri, 8 Sep 95 18:42:39 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <4EB1C972ACF@aitec.de>; from "Dr. Aris Christidis" at Sep 5, 95 6:39 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > Hello! > > As Michael T. Jones had already confirmed, there is a bug concerning > the swapbuffer control in PF1.2; it consists in that, when the DRAW > process gets ready within 1/60 sec, the buffer swaps at the next > vertical retrace period, even if pfFrameRate is set to 30 and pfPhase > is PFPHASE_LOCK. > > While running our application in single pipe mode, we had our own > swap control function (declared in pfPipeSwapFunc), which forced the > DRAW process (from the second frame on) to wait until the next frame > boundary: > > void SwapPipe (pfPipe *pipe) > { > static double t1=0, t2=0; > t2 = pfGetTime (); > while ((t2-t1) < 1/30.) t2 = pfGetTime (); > t1 = t2; > swapbuffers(); > } > > Currently we are changing our application from single pipe > to multipipe mode and we found out that our workaround does not > work any more. The same effect occurs also when using PFPHASE_FLOAT > or PFPHASE_LIMIT and of course if we don't use any workaround. This should work in multipipe if you are genlocked which is an absolute requirement for proper operation. Another option is the following: while (((pfGetVClock() - startV) % fieldsPerFrame)) != fieldsPerFrame - 2) { sginap(1); } where startV is the vclock value when drawing begins. If you are using LOCK you may be able to omit the - startV. From guest Mon Sep 11 00:51:02 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA27209; Mon, 11 Sep 1995 00:46:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA27206; Mon, 11 Sep 1995 00:46:47 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05168; Mon, 11 Sep 95 00:46:45 -0700 Received: from relay1.oleane.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id AAA06760; Mon, 11 Sep 1995 00:46:40 -0700 Received: from corysmailserv (mailhost.corys.fr [194.2.225.1]) by relay1.oleane.net (8.6.10/8.6.9) with SMTP id JAA21840 for ; Mon, 11 Sep 1995 09:46:36 +0200 Received: from quartz. by corysmailserv (5.x/SMI-SVR4) id AA06336; Mon, 11 Sep 1995 09:22:02 +0200 Received: by quartz. (950511.SGI.8.6.12.PATCH526/940406.SGI) for info-performer@sgi.com id JAA10487; Mon, 11 Sep 1995 09:10:15 +0200 From: "Lionel Maiaux" Message-Id: <9509110910.ZM10485@quartz> Date: Mon, 11 Sep 1995 09:10:15 +0100 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: C++ allocation in arena ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, I want to use standard C++ allocation (new, delete) but I want these allocations to be in Performer arena. I suppose it's very simple with Performer 2.0 but I am not a beta tester and I must do it now (so, with 1.2). Any idea ? From guest Mon Sep 11 05:43:41 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA27551; Mon, 11 Sep 1995 05:41:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA27548; Mon, 11 Sep 1995 05:41:15 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12332; Mon, 11 Sep 95 05:41:13 -0700 Received: from dw3si.ess.harris.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA23481; Mon, 11 Sep 1995 05:41:12 -0700 From: bmcquear@dw3f.ess.harris.com Received: by dw3si.ess.harris.com (5.57/Ultrix3.0-C) id AA00315; Mon, 11 Sep 95 08:41:51 -0400 Message-Id: <9509111241.AA00315@dw3si.ess.harris.com> To: "Lionel Maiaux" Cc: info-performer@sgi.sgi.com, bmcquear@dw3f.ess.harris.com Subject: Re: C++ allocation in arena ? In-Reply-To: Your message of "Mon, 11 Sep 95 09:10:15 BST." <9509110910.ZM10485@quartz> Date: Mon, 11 Sep 95 08:41:48 -0400 X-Mts: smtp Status: O On Sep 11, 9:10am, Lionel Maiaux wrote: > Subject: C++ allocation in arena ? > Hi, > > I want to use standard C++ allocation (new, delete) but I want these > allocations to be in Performer arena. > I suppose it's very simple with Performer 2.0 but I am not a beta tester and I > must do it now (so, with 1.2). > Any idea ? > >-- End of excerpt from Lionel Maiaux Lionel, Here's one way to do it in 1.2 (excerpt from vrfly, which can be found at sgigate@sgi.com). You can use this as a parent class to all of your classes you want allocated from the arena, or you can overload the operator in each class. //////////////////////////////////////////// #ifndef __PFNEW__ #define __PFNEW__ #include #include class pfnew { public: void * operator new(size_t); void operator delete(void *); }; #endif /////////////////////////////////////////// #include "pfnew.h" #include void * pfnew::operator new(size_t s) { void * buff = pfMalloc(s, pfGetSharedArena()); return buff; } void pfnew::operator delete(void * p) { pfFree(p); } ----------------------------------------------------------- Bruce McQueary | Phone 407-984-5964 (Office) Harris Corporation, ISD | 407-984-6813 (Lab) P.O. Box 98000 | Fax 407-984-6323 W3-3207 | email: bmcquear@harris.com Melbourne, FL 32902 | ----------------------------------------------------------- From guest Mon Sep 11 07:24:35 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA27761; Mon, 11 Sep 1995 07:22:11 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA27758; Mon, 11 Sep 1995 07:22:10 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14659; Mon, 11 Sep 95 07:22:09 -0700 Received: from smtpgw by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA02808; Mon, 11 Sep 1995 07:22:04 -0700 Received: from callisto.geo.unizh.ch by smtpgw.unizh.ch with SMTP (PP) id <27800-0@smtpgw.unizh.ch>; Mon, 11 Sep 1995 16:21:33 +0200 Received: from icarus.geo.unizh.ch by callisto.geo.unizh.ch (5.x/SMI-SVR4) id AA16081; Mon, 11 Sep 1995 16:21:24 +0200 From: hilko@rsl.geogr.unizh.ch (Hilko Hoffmann) Received: by icarus.geo.unizh.ch (5.x) id AA00463; Mon, 11 Sep 1995 16:21:24 +0200 Message-Id: <9509111421.AA00463@icarus.geo.unizh.ch> Subject: subscribe To: info-performer@sgi.sgi.com Date: Mon, 11 Sep 1995 16:21:23 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: O Hi, would you please subscribe me to the info-performer@sgi.com mailing list! Best Regards, H. Hoffmann -- Hilko Hoffmann hilko@rsl.geogr.unizh.ch Phone: +41 - 1 / 257 51 63 Remote Sensing Laboratories FAX: +41 - 1 / 362 52 27 University of Zurich Winterthurerstrasse 190 CH-8057 Zurich; Switzerland From guest Mon Sep 11 10:03:33 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA28130; Mon, 11 Sep 1995 09:59:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA28127; Mon, 11 Sep 1995 09:59:31 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21578; Mon, 11 Sep 95 09:59:29 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA00734; Mon, 11 Sep 1995 09:59:27 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id JAA11170; Mon, 11 Sep 1995 09:45:36 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id JAA02204; Mon, 11 Sep 1995 09:44:42 -0700 From: "AnitaKishore" Message-Id: <9509110944.ZM2202@lee.electrogig.com> Date: Mon, 11 Sep 1995 09:44:40 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: C++ allocation in arena ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 11, 9:10am, Lionel Maiaux wrote: > Subject: C++ allocation in arena ? > Hi, > > I want to use standard C++ allocation (new, delete) but I want these > allocations to be in Performer arena. > I suppose it's very simple with Performer 2.0 but I am not a beta tester and I > must do it now (so, with 1.2). > Any idea ? >-- End of excerpt from Lionel Maiaux To allocate space from any place other than the default user heap which the C++ "new" operator does, you will have to override the default "new" operator to allocate space from where you want. Refer to any C++ book for this. So, if you want to allocate space out of the Performer arena, I think you can use pfMalloc in your "new" operator. Make sure you do this after pfInit. -anita From guest Mon Sep 11 09:57:23 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA28124; Mon, 11 Sep 1995 09:54:37 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA28121; Mon, 11 Sep 1995 09:54:37 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21290; Mon, 11 Sep 95 09:54:35 -0700 Received: from sgimco.orlando.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id JAA08463; Mon, 11 Sep 1995 09:54:34 -0700 Received: from dolphin.orlando.sgi.com by sgimco.orlando.sgi.com via ESMTP (940816.SGI.8.6.9/930416.SGI) id MAA15309; Mon, 11 Sep 1995 12:54:31 -0400 Received: by dolphin.orlando.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA00340; Mon, 11 Sep 1995 12:53:59 -0400 From: "Dennis Pierce" Message-Id: <9509111253.ZM338@dolphin.orlando.sgi.com> Date: Mon, 11 Sep 1995 12:53:55 -0400 X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: iris-performer@sgihub.corp.sgi.com Subject: Perf 2.0 inst Cc: dpierce@sgihub.corp.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O tried installing new Perf 2.0 beta and got the following... ERROR : Conflicts must be resolved. performer_eoe.sw32.igl_performer cannot be installed because of missing prerequisites: 1a. Do not install performer_eoe.sw32.igl_performer (0) 1b. Install c_eoe.sw32.lib (1000000000 - 2147483647) and performer_eoe.sw32.common_performer (1009000073 - 1009000073) (not on current distribution) 1c. Install c++_eoe.sw32.lib (1000000000 - 2147483647) and performer_eoe.sw32.common_performer (1009000073 - 1009000073) (not on current distribution) performer_eoe.sw32.igl_loader cannot be installed because of missing prerequisites: 2a. Do not install performer_eoe.sw32.igl_loader (0) 2b. Install c_eoe.sw32.lib (1000000000 - 2147483647) and performer_eoe.sw32.common_performer (1009000073 - 1009000073) (not on current distribution) 2c. Install c++_eoe.sw32.lib (1000000000 - 2147483647) and performer_eoe.sw32.common_performer (1009000073 - 1009000073) (not on current distribution) went looking for c_eoe.sw32.lib and c++_eoe.sw32.lib and all I found was c_eoe.sw.lib and c++_eoe.sw.lib on the 5.3 xFS CD and 5.3 CD ok, so what now? thanks ps, tried newsgroup but odin seems tempermental From guest Mon Sep 11 10:52:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA28262; Mon, 11 Sep 1995 10:49:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA28259; Mon, 11 Sep 1995 10:49:11 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24973; Mon, 11 Sep 95 10:49:10 -0700 Received: from rasputin.engr.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id KAA18396; Mon, 11 Sep 1995 10:49:11 -0700 Received: by rasputin.engr.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id KAA04497; Mon, 11 Sep 1995 10:47:56 -0700 From: "Susan Raskin" Message-Id: <9509111047.ZM4495@rasputin.engr.sgi.com> Date: Mon, 11 Sep 1995 10:47:52 -0700 X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: info-performer@sgihub.corp.sgi.com Subject: Open position on SGI's Iris Performer Team Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Silicon Graphics has an open position on its Performer Team for a software engineer familiar with the build and release cycle who also has documentation, presentation, and training skills. This engineer will be responsible for the software build and test process, sample programs, the currency of documentation and training courses, and on-line resources. This position requires travel as needed to support presentations and customers. Qualified candidates will have two years experience in C and C++ programming, an understanding of Silicon Graphics hardware and software, experience with 3D software libraries, and software documentation or other technical writing experience. To apply for this position, email resume to sraskin@sgi.com, fax to 415-933-0980, or call Susan Raskin at 415-390-4523. Silicon Graphics is an equal opportunity employer. Principals only, please. From guest Mon Sep 11 03:23:36 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA27397; Mon, 11 Sep 1995 03:21:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA27394; Mon, 11 Sep 1995 03:21:11 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08935; Mon, 11 Sep 95 03:21:10 -0700 Received: from nirvana.neu.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id DAA16134; Mon, 11 Sep 1995 03:20:57 -0700 Received: by nirvana.neu.sgi.com (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.sgi.com id MAA19226; Mon, 11 Sep 1995 12:20:41 +0200 From: "Simon Hayhurst" Message-Id: <9509111220.ZM19224@nirvana.neu.sgi.com> Date: Mon, 11 Sep 1995 12:20:41 -0600 X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: C++ allocation in arena ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 11, 9:10am, Lionel Maiaux wrote: > Subject: C++ allocation in arena ? > Hi, > > I want to use standard C++ allocation (new, delete) but I want these > allocations to be in Performer arena. > I suppose it's very simple with Performer 2.0 but I am not a beta tester and I > must do it now (so, with 1.2). > Any idea ? > >-- End of excerpt from Lionel Maiaux Lionel, I'm a Performer novice, so excuse me if I'm wide of the mark ... but I think that all you need to do is overload 'new' and 'delete'. I've used this in other projects to allow new and delete to use home grown routines to give X-Process objects / debug information. Most good C++ references talk about how to do this (eg "C++ the Complete Reference, 2nd Edition" by Osborne, ISBN 0-07-88212301, page 367). void *operator new( size_t size // , my_args Optional_Additional_Arguments ) { // Peform home grown allocation // eg switch on additional args to do pfuNewXyz return (void *)pointer_to_memory } similarly for delete void operator delete(void *p) { // Perform home grown de-allocation } Simon -- -------------------------------------------------------------------------------- Simon Hayhurst Phone (41)-38-433733 Supercomputing Technology Centre Fax (41)-38-433905 Core Technology Group Voice Mail 5-7269 SGI, Cortaillod, Switzerland Internet simon @ neu.sgi.com -------------------------------------------------------------------------------- From guest Mon Sep 11 12:23:36 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA28700; Mon, 11 Sep 1995 12:19:30 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA28697; Mon, 11 Sep 1995 12:19:29 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01225; Mon, 11 Sep 95 12:19:27 -0700 Received: from sgigate.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id MAA04821; Mon, 11 Sep 1995 12:19:27 -0700 Received: from VX.CIS.UMN.EDU by sgigate.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/940406.SGI) for id MAA07141; Mon, 11 Sep 1995 12:19:24 -0700 Received: from reality.psych.umn.edu by VX.CIS.UMN.EDU (PMDF V4.2-13 #2574) id <01HV5IMS09XCEFF529@VX.CIS.UMN.EDU>; Mon, 11 Sep 1995 14:23:02 CDT Received: by reality.psych.umn.edu; Mon, 11 Sep 1995 14:16:05 -0500 Date: Mon, 11 Sep 1995 14:16:05 -0500 From: Renee Maheshwari Subject: lower horizon In-Reply-To: "Susan Raskin" "Open position on SGI's Iris Performer Team" (Sep 11, 10:47am) To: info-performer@sgihub.corp.sgi.com Message-Id: <9509111416.ZM6018@reality.psych.umn.edu> Mime-Version: 1.0 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT References: <9509111047.ZM4495@rasputin.engr.sgi.com> Status: O Hello all, Is there a transformation or function call/command that will allow me to move the horizon lower on the screen for a scene I'm drawing? I don't want to change the perspective view or anything, so I don't want to move the eye around. I'm creating a driving scene, and my eye is the perfect height above the ground, about 3 feet or so, but it seems as if there's too much road in front of me-the horizon is too high. Is there a way to change this? I couldn't think of a way. Sorry if this is a really obvious one! Thanks in advance, Renee -- ___ _ _ _ ********************************************* /_) (_ /\ / (_ (_ Renee Maheshwari / \ (_ / \/ (_ (_ Programmer, Human Factors Research Laboratory University of Minnesota email: renee@reality.psych.umn.edu http://www.umn.edu/nlhome/g508/mahe0010 *********************************************************************** From guest Mon Sep 11 13:09:37 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA28834; Mon, 11 Sep 1995 12:59:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA28831; Mon, 11 Sep 1995 12:59:18 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03596; Mon, 11 Sep 95 12:59:16 -0700 Received: from sgigate.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id MAA09990; Mon, 11 Sep 1995 12:59:10 -0700 Received: from thor.ats.qc.ca by sgigate.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/940406.SGI) for id MAA02562; Mon, 11 Sep 1995 12:59:06 -0700 Received: (from jaydee@localhost) by thor.ats.qc.ca (8.6.12/atsgw-mf1) id PAA22973; Mon, 11 Sep 1995 15:58:56 -0400 Message-Id: <199509111958.PAA22973@thor.ats.qc.ca> From: jaydee@thor.ats.qc.ca (Jean Daigle) Date: Mon, 11 Sep 1995 15:58:56 -0400 In-Reply-To: Renee Maheshwari "lower horizon" (Sep 11, 2:16pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Renee Maheshwari Subject: Re: lower horizon Cc: info-performer@sgihub.corp.sgi.com Status: O Hello! On Sep 11, 2:16pm, Renee Maheshwari wrote: ... } Is there a transformation or function call/command that will allow me to move } the horizon lower on the screen for a scene I'm drawing? I don't want to } change the perspective view or anything, so I don't want to move the eye } around. I'm creating a driving scene, and my eye is the perfect height above } the ground, about 3 feet or so, but it seems as if there's too much road in } front of me-the horizon is too high. Is there a way to change this? I } couldn't think of a way. Sorry if this is a really obvious one! ... }-- End of excerpt from Renee Maheshwari Perhaps an asymmetric viewing frustum would serve your purpose. Check out the pfFrustum and pfChanFOV man pages. It boils down to using pfMakePerspFrust() calls instead of pfChanFOV() -- the former allows you to define separately the fields of view above and below the viewing direction, which addresses your concern. Regards, Jean Daigle. ----------------------------------------------------------------- | Jean Daigle ATS Aerospace Inc. | | Software Designer 1250 Boul Marie-Victorin | | St. Bruno, QC J3V 6B8 | | jaydee@ats.qc.ca Tel: (514) 441-9000 Fax: (514) 441-6789 | ----------------------------------------------------------------- From guest Tue Sep 12 10:02:41 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA00812; Tue, 12 Sep 1995 09:58:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA00809; Tue, 12 Sep 1995 09:58:46 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18182; Tue, 12 Sep 95 09:58:44 -0700 Received: from pike.cecer.army.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA18175; Tue, 12 Sep 1995 09:58:24 -0700 Received: from lee (lee.cecer.army.mil [129.229.32.11]) by pike.cecer.army.mil (8.6.9/8.6.9) with SMTP id XAA19196; Mon, 11 Sep 1995 23:02:25 -0500 From: "Eric S. Hirschorn" Message-Id: <199509120402.XAA19196@pike.cecer.army.mil> Subject: Setting x,y screen offsets for composite output To: info-performer@sgi.sgi.com Date: Mon, 11 Sep 1995 22:57:46 -0500 (CDT) Reply-To: erich@pike.cecer.army.mil X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 919 Status: O Hi, We have an Onyx RE2, and we currently can only control the x,y screen offsets for the composite output with "vout". Unfortunately, since vout does not take command line input, we are not able to change the screen offset from another program or from the command line. We would like to gain this type of control over the screen offsets. The Video Library of the Digital Media library is useless for a standard Onyx RE (no video daemon), and our local SGI rep says there is no SGI-approved procedure other than vout for setting the offsets on our type of system. Does anybody out there know how to overcome this problem, or know how vout works? Eric _____________________________________________________________________________ Eric S. Hirschorn, VE Group, USACERL, Champaign IL 61826-9005 TEL: (217) 373-6722, FAX: (217) 373-6724 email: erich@pike.cecer.army.mil, http://pike.cecer.army.mil/erich/erich.html From guest Thu Sep 14 06:25:59 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA08095; Thu, 14 Sep 1995 06:23:49 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA08092; Thu, 14 Sep 1995 06:23:48 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21943; Thu, 14 Sep 95 06:23:47 -0700 Received: from rs2.hrz.th-darmstadt.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA05571; Thu, 14 Sep 1995 06:19:00 -0700 From: reiners@igd.fhg.de Received: from igd.igd.fhg.de (dakeeper.igd.fhg.de) by rs2.hrz.th-darmstadt.de with SMTP id AA13961 (5.65c/IDA-1.4.4); Tue, 12 Sep 1995 12:29:36 +0200 Received: by igd.igd.fhg.de; Tue, 12 Sep 95 12:29:37 +0200 Received: by duerer.igd.fhg.de (940816.SGI.8.6.9/SMI-4.0) id MAA05405; Tue, 12 Sep 1995 12:25:36 +0200 Date: Tue, 12 Sep 1995 12:25:36 +0200 Message-Id: <9509121225.ZM5403@duerer> In-Reply-To: "Rob Jenkins" "Re: Swapbuffer control problems in multipipe mode" (Sep 11, 9:28) References: <4EB1C972ACF@aitec.de> <9509071653.ZM2039@bitch.reading.sgi.com> <9509071634.ZM8457@barney.reading.sgi.com> <9509091557.ZM642@duerer> <9509110928.ZM3958@barney.reading.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Rob Jenkins" Subject: Re: Swapbuffer control problems in multipipe mode Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Rob Jenkins wrote: > > > 6) Software Modifications > ------------------------- > > To modify an existing program to use the GangDraw mechanism is quite > easy. You change existing calls to swapbuffers() or mswapbuffers() to > include the GANGDRAW parameter. > > First, change all instances of > > swapbuffers(); > > to > > mswapbuffers(NORMALDRAW); > > which are exactly equivilent statements. Next, whenever you want to > have a synchronized swap (i.e. all pipes swap simultaneously), add > the GANGDRAW parameter to the mswapbuffers call; e.g. change > > mswapbuffers(NORMALDRAW); > > to > > mswapbuffers(NORMALDRAW | GANGDRAW); > >-- End of excerpt from Rob Jenkins Hmm, as I'm using OpenGL (because I couldn't use IRIS GL GLX on multiple pipes) I can't use mswapbuffers. Is there an OpenGL replacement for mswapbuffers? Maybe in a new feature patch or in IRIX 6.2? Any hints? I don't need it very badly as my software synchronisation with genlocked pipes works ok, but sometimes there are frames that have problems, and GANGDRAW would be a nice and easy way to get rid of them. Thanks Dirk From guest Tue Sep 12 16:18:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA02127; Tue, 12 Sep 1995 16:03:45 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA02124; Tue, 12 Sep 1995 16:03:45 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13847; Tue, 12 Sep 95 16:03:41 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA25870; Tue, 12 Sep 1995 16:03:33 -0700 Received: from tracey.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id PAA19067; Tue, 12 Sep 1995 15:58:27 -0700 Received: by tracey.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id PAA10403; Tue, 12 Sep 1995 15:55:53 -0700 From: "Anita Kishore" Message-Id: <9509121555.ZM10401@tracey.electrogig.com> Date: Tue, 12 Sep 1995 15:55:52 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: using shared memory in Performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Is it possible to have any type of conflict between the shared arena of Performer and other shared arenas obtained by "shmat" and "shmget" inside a Performer application? There seems to be a time lag between when the data is written in (non-performer) shared arena and reading from it. The reading is done inside Performer. Any help will be greatly appreciated. thanks -anita From guest Tue Sep 12 18:49:35 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA02930; Tue, 12 Sep 1995 18:45:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA02927; Tue, 12 Sep 1995 18:45:46 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24567; Tue, 12 Sep 95 18:45:40 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id SAA14733; Tue, 12 Sep 1995 18:45:33 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id KAA02067 (8.6.12/IDA-1.6); Wed, 13 Sep 1995 10:59:02 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA04875 (5.65c/IDA-1.5); Wed, 13 Sep 1995 10:34:01 +1000 Received: from krusty (krusty [8.0.0.31]) by aggro with SMTP id KAA29213 (8.6.12/IDA-1.6); Wed, 13 Sep 1995 10:41:26 +1000 Received: by krusty (5.65) id AA07068; Wed, 13 Sep 1995 10:41:25 +1000 Date: Wed, 13 Sep 1995 10:41:23 +1000 (EST) From: Simon Bennett Subject: Re: using shared memory in Performer To: Anita Kishore Cc: info-performer@sgi.sgi.com In-Reply-To: <9509121555.ZM10401@tracey.electrogig.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Status: O On Tue, 12 Sep 1995, Anita Kishore wrote: > Is it possible to have any type of conflict between the shared arena of > Performer and other shared arenas obtained by "shmat" and "shmget" inside > a Performer application? There seems to be a time lag between when the da= ta > is written in (non-performer) shared arena and reading from it. The readi= ng > is done inside Performer. There certainly is! For starters "shmat" and "shmget" are not IRIX arena IPC calls, but System V IPC calls... The two IPC paradigm's don't co-exist that happily. In addition the System V IPC calls are significantly slower and don't seem to be MP safe. Unless you really need to use Sys V IPC, I'd advise using IRIS arena memory with Performer applications, it's a much happier solution. You can use arena's either directly through IRIX (see th= e manpages for usinit et al) or through Performer - pfDataPools etc... From=20the "IRIX System Programming Guide" -- begin -- Types of Inter-Process Communication Available IRIX supports several types of IPC. Standard AT&T System V Release 4 IPC is available for making code portable. However, its implementation is fundamentally different from (and slower than) that of the IRIX-specific IP= C also provided with IRIX. BSD socket-based IPC is supported for compatibilit= y and, to allow IPC across a network, between processes running on different machines. Do not mix the various types of IPC in a given program. Use System V IPC=BE based on a mechanism called keys=BEfor code that must comply with the MIPS ABI, code that needs to be portable, or code that you're porting from anoth= er System V operating system. Use arena-based IRIX IPC for applications that require speed, ease of implementation, or multiprocessing ability. Socket-b= ased IPC is necessary only for code being ported from or to a BSD system, and fo= r network IPC. -- end -- Hope this helps... +--------------------------------------------------------------------------= --+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 9981 0611 (x51= 2) Meeting - an event where you take minutes and waste hours. From guest Wed Sep 13 01:31:07 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA03934; Wed, 13 Sep 1995 01:24:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA03931; Wed, 13 Sep 1995 01:24:34 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08971; Wed, 13 Sep 95 01:24:32 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA16148; Wed, 13 Sep 1995 01:24:31 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id BAA00273; Wed, 13 Sep 1995 01:24:18 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id JAA10705; Wed, 13 Sep 1995 09:20:56 +0100 From: "Rob Jenkins" Message-Id: <9509130920.ZM10703@barney.reading.sgi.com> Date: Wed, 13 Sep 1995 09:20:55 +0100 In-Reply-To: "Eric S. Hirschorn" "Setting x,y screen offsets for composite output" (Sep 11, 10:57pm) References: <199509120402.XAA19196@pike.cecer.army.mil> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: erich@pike.cecer.army.mil, info-performer@sgi.sgi.com Subject: Re: Setting x,y screen offsets for composite output Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O erich You should be able to use setmon -jgenlockdelay from man setmon: -jgenlockdelay Specifies number of pixels to adjust display, relative to genlock input signal. Currently, only supported on Iris Elan and Extreme for NTSC and PAL monitors. Positive values move display to the left, and negative values move display to the right. Must be used with the -g option. although the man page says Iris Elan and Extreme I know people have used it on an Onyx RE ok. I hope this does what you want. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Wed Sep 13 09:24:33 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA04369; Wed, 13 Sep 1995 09:18:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA04366; Wed, 13 Sep 1995 09:18:01 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20683; Wed, 13 Sep 95 09:18:02 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA06265; Wed, 13 Sep 1995 09:17:57 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id JAA02132; Wed, 13 Sep 1995 09:17:52 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id RAA13989; Wed, 13 Sep 1995 17:14:19 +0100 From: "Rob Jenkins" Message-Id: <9509131714.ZM13987@barney.reading.sgi.com> Date: Wed, 13 Sep 1995 17:14:18 +0100 In-Reply-To: "Ben Simons" "Indigo2 impact" (Sep 13, 3:37pm) References: <9509131537.ZM26294@moffatt.vislab.su.edu.au> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Ben Simons" , info-performer@sgi.sgi.com Subject: Re: Indigo2 impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 13, 3:37pm, Ben Simons wrote: > Subject: Indigo2 impact > I have a number of questions in regard to the indigo2 > impact hardware texture memory... > > Q1) Is it true that the texture download times have been reduced? > > Q2) Can someone compare the texture download times between an Re2/RM4 > and the high impact board. > > Q3) So, will demand paging of textures then be feasible? > > Q4) Does performer support this new hardware already, or > will it be included in the next release? > > It seems that the main bottleneck in our app is the downloading of > textures to our terrain - essentially we want to do "texture animation". > We have over 100MB of textures that we use overall (not all at once!). > > I have the idea that in fact, rather than chase the RM5 32MB texture boards > for an onyx, I could use an indigo2 impact with 4MB of texture RAM > because it will download textures faster. Is this so? > > I think many performer people would be interested in this one! > regards, > > ben. > > -- > _______________________________________________________ > Ben Simons Physics Building, A28, > VisLab Systems Manager Sydney University. NSW. > Phone +61-2-351-3005 AUSTRALIA. 2006. >-- End of excerpt from Ben Simons Ben I have some good Impact info ( see forwarded email from John Burwell/Svend Tang-Petersen below ). It doesn't answer your question directly but I think does a good job of putting the whole Impact vs Reality Engine comparision into perspective. Cheers Rob On Aug 11, 3:01pm, John Burwell wrote: > Subject: Onyx/RE2 vs. Indigo2 Impact > > Greetings. > > Many have requested more information as to how the new Indigo2 Impact > compares with Onyx RE2 in the vis sim market. I have developed the > following as a guideline: > > > Impact verses Onyx RealityEngine2 in Vis Sim. > > Multi-processing. > > Indigo2 Impact only supports a single R4400 or R8000 processor. > This has implications in terms of overall processing power, graphics > performance, and real-time determinism. > > Obviously, a single processor on the Indigo2 limits the usse of the > product to applications which are not overwhelmingly compute > intensive. In the case where high performance computing is > required, and application software supports multi-processing, Onyx > is a better solution. However, in cases where applications are not > well suited for multi-threaded software, or where software is not > available, multi-processing is not critial. > > Not as obvious is the direct relationship between graphics > performance and CPU performance. Significant processing is > required to obtain optimum performance from a pipeline mostly > related to processing ensuring that only polygons which contribute > significantly to the sceen are rendered or load management. This > pre-processing of the graphics data is ideally suited for the CPU but > only in cases where the CPU is not busy doing other computing. The > solution lends itself well to a multi-processing environment directly > supported by the Onyx and IRIS Performer. Indigo2 Impact does > support a pull model architecture where grahpics data is pulled from > the memory rather than requiring a CPU to push data to the pipe. > This does reduce CPU processing requirements and is a major > advance which helps with a sigle processor front end. > > Real-time computing where determinism is critical is supported by > IRIX and React but is optimized for multi-processing. React > supports real-time processing by segregating all non-deterministic > processing to a single processor, leaving the others free for absolute > determinism. In a single processor system, non-degrading priorities, > interrupt handling, and other real-time tasking are supported, but > absolute determinism is largely based on the complexity of the > application and demands closer scrutiny. > > Memory Capacity. > > On-line memory capacity of the Indigo2 is limited to 384 MB (640 for Power > Indigo2) which is suitable for a wide variety of applications. In cases > where larger on-line memory capacities are required, Onyx is the obvious > choice offering up to 2 GB on the deskside and 16 GB on the rack. > > VME. > > Onyx supports VME and all the associated interfaces. VME is key > for many customers interested in standard, open system interfaces. > Although not the fastest, VME is very widely used. If a customer > needs VME, Onyx or Challenge are the answers. > > Pixel fill rates. > > Impact has impressive polygon capacities similar to the RE2 but > cannot match the pixel fill rates of RE2. This is significant for > applications where high resolution, high depth complexities, and > multiple channels are required. Impact supports one or two raster > engines each with a fill rate of 65 million pixels per second for a total > fill rate of 130 million pixels/second. The RealityEngine2 supports 1, > 2 or 4 raster managers each supporting 80 million > pixels/second/raster manager for a grand total of 320 million > pixels/second. > > With 130 million pixels/second, Indigo2 Impact will be suited for > applications with lower update rate requirements, low resolution > multi-channel requirements, and applications which can be > supported with low depth complexities. > > Anti-Aliasing. > > Generating high fidelity imagery free of distracting visual anomalies > caused by digital processing (more commonly known as jaggies) is > essential for many applications in visual simulation, virtual reality, > and high end design. Indigo2 Impact does not support multi-sample > antialiasing so lower price points can be achieved. This is very > apparent on polygon edges and when viewing narrow polygons edge on. > For applications where image quality is essential in real-time > processing, RealityEngine2 is the suitable choice. > > Video Output Formats. > > Indigo2 Impact supports a number of commonly used video formats > including field sequential video making it scalable for a wide variety > of applications. However, the Onyx RealityEngine2 supports an > even wider range of formats and combinations, especially in multi- > pipe configurations. > > Texture Memory. > > Indigo2 Impact support 1 or 4 MB of on-line texture memory making > it suitable for many visual simulation and imaging applications. > Onyx RealityEngine2 supports 4 or 16 MB of on-line texture memory > making it more suitable for high end applications involving large > amounts of high resolution image data, 3D texture, and projected > texture. > > Indigo2 Impact in Visual Simulation. > > Indigo2 Impact is a powerful new addition to the broad product line > of systems and software offered by Silicon Graphics for the > simulation and training industry. It is designed to support 4 primary > areas: simulation authoring, basic image generation, C3I, and > distributed interactive simulation. In the simulation industry, Impact > complements the existing Onyx product line and greatly enhances > the utility of the Indigo2 product line. > > What it will support: > > Basic image generation, database development, cockpit display > prototyping, image generation software development, numerous > DIS applications, instructor/operator displays, basic mission > planning. > > What it wonUt support: > > Host computing or Host integrated computer image generation - > Needs multi-processing. > > High performance image generation - Needs multi-processing, > sophisticated load management, anti-aliasing, and additional pixel > fill. > > > > > > -- > ============================================================================== > _/_/_/ _/ _/ _/ _/_/ _/_/_/ _/ _/ > _/ _/ _/ _/ _/ _/ _/ _/ _/ > _/_/_/ _/ _/ _/ _/ _/ _/ _/_/_/ > _/ _/ _/ _/ _/ _/ _/ _/ _/ > _/_/_/ _/ _/_/_/ _/ _/_/ _/_/_/ _/ _/ > > _/ _/ _/ _/_/ _/_/_/ _/_/_/ _/_/_/ _/ _/ > _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ > _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ > _/ / _/ _/ _/ _/ _/ _/_/ _/ > _/ _/ _/_/_/ _/ _/_/_/ _/ _/ _/ > > John M. Burwell > Visual Simulation Market Manager > Advanced Systems Division > (415) 390-1743 > (415) 964-8671 fax > ============================================================================== > >-- End of excerpt from John Burwell -- Regards Svend ********************************************************************* * Svend Tang-Petersen Email: svend@copen.sgi.com * * Silicon Graphics Denmark Fax: (+45) 43438606 * * Herstedoestervej 27-29 Phone: (+45) 43438600 * * 2620 Albertslund Voice mail: 5-7507 * * DENMARK * ********************************************************************* -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Wed Sep 13 09:59:34 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA04410; Wed, 13 Sep 1995 09:54:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA04407; Wed, 13 Sep 1995 09:54:53 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22822; Wed, 13 Sep 95 09:54:51 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA15072; Wed, 13 Sep 1995 09:54:50 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id JAA22310; Wed, 13 Sep 1995 09:54:23 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id JAA04040; Wed, 13 Sep 1995 09:53:49 -0700 From: "AnitaKishore" Message-Id: <9509130953.ZM4038@lee.electrogig.com> Date: Wed, 13 Sep 1995 09:53:47 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Indigo2 impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > > It seems that the main bottleneck in our app is the downloading of > textures to our terrain - essentially we want to do "texture animation". > We have over 100MB of textures that we use overall (not all at once!). > > I have the idea that in fact, rather than chase the RM5 32MB texture boards > for an onyx, I could use an indigo2 impact with 4MB of texture RAM > because it will download textures faster. Is this so? I don't know about Impact, but as suggested by SGI I am able to manage hardware texture memory loading and unloading at will on a RE2 RM5, through the beta version of Performer2.0. It seems to have improved our texture downloading speed significantly. -anita From guest Wed Sep 13 10:28:54 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA04533; Wed, 13 Sep 1995 10:25:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA04530; Wed, 13 Sep 1995 10:25:58 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA25023; Wed, 13 Sep 95 10:25:54 -0700 Received: from copernicus.hpc.org by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA22629; Wed, 13 Sep 1995 10:25:53 -0700 Received: from galileo.hpc.org by copernicus.hpc.org (4.1/SMI-4.1) id AA21823; Wed, 13 Sep 95 13:33:52 EDT Received: by galileo.hpc.org (950215.SGI.8.6.10/930416.SGI) id NAA01745; Wed, 13 Sep 1995 13:37:42 -0400 Date: Wed, 13 Sep 1995 13:37:42 -0400 (EDT) From: Michael Kelley X-Sender: kelleym@galileo.hpc.org To: Performer Subject: Indigo2 Impact In-Reply-To: <9509130953.ZM4038@lee.electrogig.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Another question on Indigo2 Impact, Does the Impact support the quad buffered 1024x768 stereo mode that the Onyx RE has? Thanks! ____________________________________________________________________ Michael Kelley Systems Programmer Information Sciences Institute kelleym@csto.snap.org (703) 243-9422 ____________________________________________________________________ From guest Wed Sep 13 11:23:52 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA04712; Wed, 13 Sep 1995 11:14:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA04709; Wed, 13 Sep 1995 11:14:05 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28735; Wed, 13 Sep 95 11:14:01 -0700 Received: from pike.cecer.army.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id LAA04668; Wed, 13 Sep 1995 11:13:58 -0700 Received: from lee (lee.cecer.army.mil [129.229.32.11]) by pike.cecer.army.mil (8.6.9/8.6.9) with SMTP id NAA29224; Wed, 13 Sep 1995 13:15:28 -0500 From: "Eric S. Hirschorn" Message-Id: <199509131815.NAA29224@pike.cecer.army.mil> Subject: Re: Setting x,y screen offsets for composite output To: info-performer@sgi.sgi.com Date: Wed, 13 Sep 1995 13:10:48 -0500 (CDT) Cc: robj@barney.reading.sgi.com In-Reply-To: <9509130920.ZM10703@barney.reading.sgi.com> from "Rob Jenkins" at Sep 13, 95 09:20:55 am Reply-To: erich@pike.cecer.army.mil X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2047 Status: O Hi Rob, Thanks for your reply, but I think we have miscommunicated. Here's a better explanation from the man page of vout: The IRIS RealityEngine provides two video outputs: a RGB video output (which is normally connected to the graphics monitor), and a composite video output. vout provides an easy-to-use graphical interface to control the composite output. It also controls several parameters of the RGB video output. The composite output is available at the BNC connector labeled `composite', and at the S-Video connector. I was referring to the video composite output that goes to the S-Video connector, rather than the RGB output to the monitor. The composite output is usually a 646 x 486 portion of the RGB output, if NTSC format is chosen for the composite signal. So the offsets that I referred to in my previous note are offsets within the larger RGB output image to the smaller composite output image. A note at the bottom of the vout man page says: The composite output may not be genlocked. And according to the setmon man page: The setmon command does not control the composite output of RealityEngine, which is controlled by the vout command. I tried out your suggestion with setmon, but the man pages appear to be correct. Eric _____________________________________________________________________________ Eric S. Hirschorn, VE Group, USACERL, Champaign IL 61826-9005 TEL: (217) 373-6722, FAX: (217) 373-6724 email: erich@pike.cecer.army.mil, http://pike.cecer.army.mil/erich/erich.html > You should be able to use setmon -jgenlockdelay from man setmon: > > -jgenlockdelay Specifies number of pixels to adjust display, > relative to genlock input signal. Currently, only > supported on Iris Elan and Extreme for NTSC and PAL > monitors. Positive values move display to the left, > and negative values move display to the right. Must > be used with the -g option. From guest Wed Sep 13 11:52:46 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA04900; Wed, 13 Sep 1995 11:45:40 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA04897; Wed, 13 Sep 1995 11:45:40 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01724; Wed, 13 Sep 95 11:45:35 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA13854; Wed, 13 Sep 1995 11:45:35 -0700 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA01716; Wed, 13 Sep 95 11:45:26 -0700 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA29086; Wed, 13 Sep 1995 11:45:28 -0700 From: "Javier Castellar" Message-Id: <9509131145.ZM29084@sixty.asd.sgi.com> Date: Wed, 13 Sep 1995 11:45:28 -0700 In-Reply-To: "Ben Simons" "Indigo2 impact" (Sep 13, 3:37pm) References: <9509131537.ZM26294@moffatt.vislab.su.edu.au> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Ben Simons" , info-performer@sgi.sgi.com Subject: Re: Indigo2 impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O It is true that the speed on texture loading is very fast on Impact. But it is also true that in RE/RE2 you have a good speed when you page bilinear textures using in gl subtexload and in ogl glTexSubImage2DEXT. I have seen applications running a very high frame rates with texture paging enought to meet most of the vissim related needs. In order to do it it is mandatory the use of preDraw/PostDraw callbacks the the above mentioned gl/ogl API. -Javier -- o <\> (Fix and Create or Die) / \ ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-390-1589 * * Real-Time Graphics * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8U-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "The violence is the resource of non competent people." Hari Seldon From guest Tue Sep 12 22:40:21 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA03488; Tue, 12 Sep 1995 22:37:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA03485; Tue, 12 Sep 1995 22:37:50 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05029; Tue, 12 Sep 95 22:37:49 -0700 Received: from redgate.vislab.su.edu.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA29926; Tue, 12 Sep 1995 22:37:42 -0700 Received: from moffatt.vislab.su.edu.au by redgate.vislab.su.edu.au via ESMTP (950215.SGI.8.6.10/940406.SGI) for id PAA13273; Wed, 13 Sep 1995 15:37:19 +1000 Received: by moffatt.vislab.su.edu.au (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id PAA26296; Wed, 13 Sep 1995 15:37:19 +1000 From: "Ben Simons" Message-Id: <9509131537.ZM26294@moffatt.vislab.su.edu.au> Date: Wed, 13 Sep 1995 15:37:18 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Indigo2 impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I have a number of questions in regard to the indigo2 impact hardware texture memory... Q1) Is it true that the texture download times have been reduced? Q2) Can someone compare the texture download times between an Re2/RM4 and the high impact board. Q3) So, will demand paging of textures then be feasible? Q4) Does performer support this new hardware already, or will it be included in the next release? It seems that the main bottleneck in our app is the downloading of textures to our terrain - essentially we want to do "texture animation". We have over 100MB of textures that we use overall (not all at once!). I have the idea that in fact, rather than chase the RM5 32MB texture boards for an onyx, I could use an indigo2 impact with 4MB of texture RAM because it will download textures faster. Is this so? I think many performer people would be interested in this one! regards, ben. -- _______________________________________________________ Ben Simons Physics Building, A28, VisLab Systems Manager Sydney University. NSW. Phone +61-2-351-3005 AUSTRALIA. 2006. From guest Wed Sep 13 12:46:18 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA05166; Wed, 13 Sep 1995 12:42:25 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA05163; Wed, 13 Sep 1995 12:42:24 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05464; Wed, 13 Sep 95 12:42:21 -0700 Received: from ldsa.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA28285; Wed, 13 Sep 1995 12:42:16 -0700 Received: by ldsa.com (5.x/SMI-SVR4) id AA09302; Wed, 13 Sep 1995 15:40:13 -0400 Date: Wed, 13 Sep 1995 15:40:13 -0400 From: kslezak@ldsa.com (Ken Slezak) Message-Id: <9509131940.AA09302@ ldsa.com> To: info-performer@sgi.sgi.com Subject: Re: Setting x,y screen offsets for composite output Status: O Eric S. Hirschorn is having the same problem we had with vout-- lack of control from the command line. Our first work-around was to allow the NTSC capture frame to default to whatever location it wanted to, then move the Performer graphic window around instead of moving the capture frame. This worked on the Indigo2 we started with but was a problem when we had to change to an Onyx... the capture frame defaulted to a different position. The folks at the SGI help line offered the following suggestion which seems to work... use the .Xdefaults geometry resource. The line that must be added is vout*geometry: +800+100 where the 800 and 100 are offsets to the corner (bottom left, I believe) of the capture window. This defaults line can either be added to the .Xdefaults file in the user's home directory to make the change for a single user, or to the /usr/lib/X11/app-defaults/Vout file to affect all users. (If either of those files do not already exist, you will have to create a new file with just the geometry command in it. We tried modifying the .Xdefaults file with vout*geometry: +0+0 and sure enough, the capture frame moved to the top left of the screen :-) [Now that I think about it, the offset may be to the top left corner of the capture window... I don't remember for sure.] Hope this helps! Ken Slezak kslezak@ldsa.com From guest Wed Sep 13 13:19:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA05319; Wed, 13 Sep 1995 13:14:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA05316; Wed, 13 Sep 1995 13:14:43 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07623; Wed, 13 Sep 95 13:14:38 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA05380; Wed, 13 Sep 1995 13:14:37 -0700 Received: from flash.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA00725; Wed, 13 Sep 95 16:14:30 EDT Received: by flash.vsl.ist.ucf.edu (940816.SGI.8.6.9) id QAA22809; Wed, 13 Sep 1995 16:14:29 -0400 Date: Wed, 13 Sep 1995 16:14:28 -0400 (EDT) From: "Michael J. Smith" To: Simon Bennett Cc: Anita Kishore , info-performer@sgi.sgi.com Subject: Re: using shared memory in Performer In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Wed, 13 Sep 1995, Simon Bennett wrote: > On Tue, 12 Sep 1995, Anita Kishore wrote: > > > Is it possible to have any type of conflict between the shared arena of > > Performer and other shared arenas obtained by "shmat" and "shmget" inside > > a Performer application? There seems to be a time lag between when the data > > is written in (non-performer) shared arena and reading from it. The reading > > is done inside Performer. > > There certainly is! For starters "shmat" and "shmget" are not IRIX arena > IPC calls, but System V IPC calls... The two IPC paradigm's don't co-exist > that happily. In addition the System V IPC calls are significantly slower > and don't seem to be MP safe. Unless you really need to use Sys V IPC, I'd > advise using IRIS arena memory with Performer applications, it's a much > happier solution. You can use arena's either directly through IRIX (see the > manpages for usinit et al) or through Performer - pfDataPools etc... > Well, I'm not sure why you say that IPC calls don't co-exist happily with IRIX REACT semaphores and shared memory. This just doesn't follow what system I have running. For my underlying drivers that I have ported to about 4 different UNIX platforms, I use System V IPC semaphores and shared memory segments and have had absolutely no problems using it under a performer 1.2 application. The speed hit may be true, but since the SYS V semaphores are portable its just a matter of what you are after on your product and what your programmers are familiar with. I have to, however, agree that the IRIX REACT seamphores and shared memory segments are faster, and a preferred choice on SGI platforms -- its just I hate to write code that is completely unusable on other platforms unless I have a resource bottleneck by that choice. ----------------------------------------------------------------------------- | Michael J. Smith University Of Central Florida | | Visual Systems Laboratory Institute for Simulation & Training | | Graduate Research Assistant 3280 Progress Drive | | smith@vsl.ist.ucf.edu Orlando, FL 32826-0544 | | @cs.ucf.edu | | Codesmith for hire | ----------------------------------------------------------------------------- From guest Wed Sep 13 14:08:16 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA05778; Wed, 13 Sep 1995 13:57:58 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA05775; Wed, 13 Sep 1995 13:57:56 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11034; Wed, 13 Sep 95 13:57:52 -0700 Received: from sgimco.orlando.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id NAA17955; Wed, 13 Sep 1995 13:57:48 -0700 Received: from dolphin.orlando.sgi.com by sgimco.orlando.sgi.com via ESMTP (940816.SGI.8.6.9/930416.SGI) for <@sgimco.orlando.sgi.com:iris-performer@sgi.com> id QAA29796; Wed, 13 Sep 1995 16:57:43 -0400 Received: by dolphin.orlando.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for iris-performer@sgi.com id QAA03711; Wed, 13 Sep 1995 16:57:20 -0400 From: "Dennis Pierce" Message-Id: <9509131657.ZM3709@dolphin.orlando.sgi.com> Date: Wed, 13 Sep 1995 16:57:16 -0400 X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: iris-performer@sgihub.corp.sgi.com Subject: good 2.0 snap? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O what's the best 2.0 snap on crusty? thanks! From guest Wed Sep 13 13:16:36 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA05294; Wed, 13 Sep 1995 13:11:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA05291; Wed, 13 Sep 1995 13:11:58 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07374; Wed, 13 Sep 95 13:11:53 -0700 Received: from cs.sfu.ca by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA04787; Wed, 13 Sep 1995 13:11:44 -0700 From: halliday@cs.sfu.ca Received: from mayne (mayne.cs.sfu.ca) by cs.sfu.ca with SMTP id AA00820 (5.65c/IDA-1.4.4 for <@fornax.cs.sfu.ca:info-performer@sgi.com>); Wed, 13 Sep 1995 13:11:39 -0700 Received: by mayne (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id NAA04157; Wed, 13 Sep 1995 13:11:33 -0700 Message-Id: <199509132011.NAA04157@mayne> Subject: videout & flicker filter To: info-performer@sgi.sgi.com Date: Wed, 13 Sep 1995 13:11:29 -0800 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 167 Status: O Maybe someone also knows how to start videoout with flicker filter turned off. I am using the Virtual I-glasses in stereo mode. -- Sean Halliday halliday@cs.sfu.ca From guest Wed Sep 13 10:58:41 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA04637; Wed, 13 Sep 1995 10:55:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA04634; Wed, 13 Sep 1995 10:55:16 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27104; Wed, 13 Sep 95 10:55:13 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA00558; Wed, 13 Sep 1995 10:55:04 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/940406.SGI) id TAA08970; Wed, 13 Sep 1995 19:33:24 +0200 From: "Angus Dorbie" Message-Id: <9509131933.ZM8968@bitch.reading.sgi.com> Date: Wed, 13 Sep 1995 19:33:23 -0600 In-Reply-To: "Rob Jenkins" "Re: Indigo2 impact" (Sep 13, 5:14pm) References: <9509131537.ZM26294@moffatt.vislab.su.edu.au> <9509131714.ZM13987@barney.reading.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Rob Jenkins" , "Ben Simons" , info-performer@sgi.sgi.com Subject: Re: Indigo2 impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O It should also be noted that RM5s have 16MB of texture memory not 32. On Sep 13, 5:14pm, Rob Jenkins wrote: > Subject: Re: Indigo2 impact > On Sep 13, 3:37pm, Ben Simons wrote: > > Subject: Indigo2 impact > > I have a number of questions in regard to the indigo2 > > impact hardware texture memory... > > > > Q1) Is it true that the texture download times have been reduced? > > > > Q2) Can someone compare the texture download times between an Re2/RM4 > > and the high impact board. > > > > Q3) So, will demand paging of textures then be feasible? > > > > Q4) Does performer support this new hardware already, or > > will it be included in the next release? > > > > It seems that the main bottleneck in our app is the downloading of > > textures to our terrain - essentially we want to do "texture animation". > > We have over 100MB of textures that we use overall (not all at once!). > > > > I have the idea that in fact, rather than chase the RM5 32MB texture boards > > for an onyx, I could use an indigo2 impact with 4MB of texture RAM > > because it will download textures faster. Is this so? > > > > I think many performer people would be interested in this one! > > regards, > > > > ben. > > > > -- > > _______________________________________________________ > > Ben Simons Physics Building, A28, > > VisLab Systems Manager Sydney University. NSW. > > Phone +61-2-351-3005 AUSTRALIA. 2006. > >-- End of excerpt from Ben Simons > > Ben > > I have some good Impact info ( see forwarded email from John Burwell/Svend > Tang-Petersen below ). It doesn't answer your question directly but I think > does a good job of putting the whole Impact vs Reality Engine comparision into > perspective. > > Cheers > Rob > > On Aug 11, 3:01pm, John Burwell wrote: > > Subject: Onyx/RE2 vs. Indigo2 Impact > > > > Greetings. > > > > Many have requested more information as to how the new Indigo2 Impact > > compares with Onyx RE2 in the vis sim market. I have developed the > > following as a guideline: > > > > > > Impact verses Onyx RealityEngine2 in Vis Sim. > > > > Multi-processing. > > > > Indigo2 Impact only supports a single R4400 or R8000 processor. > > This has implications in terms of overall processing power, graphics > > performance, and real-time determinism. > > > > Obviously, a single processor on the Indigo2 limits the usse of the > > product to applications which are not overwhelmingly compute > > intensive. In the case where high performance computing is > > required, and application software supports multi-processing, Onyx > > is a better solution. However, in cases where applications are not > > well suited for multi-threaded software, or where software is not > > available, multi-processing is not critial. > > > > Not as obvious is the direct relationship between graphics > > performance and CPU performance. Significant processing is > > required to obtain optimum performance from a pipeline mostly > > related to processing ensuring that only polygons which contribute > > significantly to the sceen are rendered or load management. This > > pre-processing of the graphics data is ideally suited for the CPU but > > only in cases where the CPU is not busy doing other computing. The > > solution lends itself well to a multi-processing environment directly > > supported by the Onyx and IRIS Performer. Indigo2 Impact does > > support a pull model architecture where grahpics data is pulled from > > the memory rather than requiring a CPU to push data to the pipe. > > This does reduce CPU processing requirements and is a major > > advance which helps with a sigle processor front end. > > > > Real-time computing where determinism is critical is supported by > > IRIX and React but is optimized for multi-processing. React > > supports real-time processing by segregating all non-deterministic > > processing to a single processor, leaving the others free for absolute > > determinism. In a single processor system, non-degrading priorities, > > interrupt handling, and other real-time tasking are supported, but > > absolute determinism is largely based on the complexity of the > > application and demands closer scrutiny. > > > > Memory Capacity. > > > > On-line memory capacity of the Indigo2 is limited to 384 MB (640 for Power > > Indigo2) which is suitable for a wide variety of applications. In cases > > where larger on-line memory capacities are required, Onyx is the obvious > > choice offering up to 2 GB on the deskside and 16 GB on the rack. > > > > VME. > > > > Onyx supports VME and all the associated interfaces. VME is key > > for many customers interested in standard, open system interfaces. > > Although not the fastest, VME is very widely used. If a customer > > needs VME, Onyx or Challenge are the answers. > > > > Pixel fill rates. > > > > Impact has impressive polygon capacities similar to the RE2 but > > cannot match the pixel fill rates of RE2. This is significant for > > applications where high resolution, high depth complexities, and > > multiple channels are required. Impact supports one or two raster > > engines each with a fill rate of 65 million pixels per second for a total > > fill rate of 130 million pixels/second. The RealityEngine2 supports 1, > > 2 or 4 raster managers each supporting 80 million > > pixels/second/raster manager for a grand total of 320 million > > pixels/second. > > > > With 130 million pixels/second, Indigo2 Impact will be suited for > > applications with lower update rate requirements, low resolution > > multi-channel requirements, and applications which can be > > supported with low depth complexities. > > > > Anti-Aliasing. > > > > Generating high fidelity imagery free of distracting visual anomalies > > caused by digital processing (more commonly known as jaggies) is > > essential for many applications in visual simulation, virtual reality, > > and high end design. Indigo2 Impact does not support multi-sample > > antialiasing so lower price points can be achieved. This is very > > apparent on polygon edges and when viewing narrow polygons edge on. > > For applications where image quality is essential in real-time > > processing, RealityEngine2 is the suitable choice. > > > > Video Output Formats. > > > > Indigo2 Impact supports a number of commonly used video formats > > including field sequential video making it scalable for a wide variety > > of applications. However, the Onyx RealityEngine2 supports an > > even wider range of formats and combinations, especially in multi- > > pipe configurations. > > > > Texture Memory. > > > > Indigo2 Impact support 1 or 4 MB of on-line texture memory making > > it suitable for many visual simulation and imaging applications. > > Onyx RealityEngine2 supports 4 or 16 MB of on-line texture memory > > making it more suitable for high end applications involving large > > amounts of high resolution image data, 3D texture, and projected > > texture. > > > > Indigo2 Impact in Visual Simulation. > > > > Indigo2 Impact is a powerful new addition to the broad product line > > of systems and software offered by Silicon Graphics for the > > simulation and training industry. It is designed to support 4 primary > > areas: simulation authoring, basic image generation, C3I, and > > distributed interactive simulation. In the simulation industry, Impact > > complements the existing Onyx product line and greatly enhances > > the utility of the Indigo2 product line. > > > > What it will support: > > > > Basic image generation, database development, cockpit display > > prototyping, image generation software development, numerous > > DIS applications, instructor/operator displays, basic mission > > planning. > > > > What it wonUt support: > > > > Host computing or Host integrated computer image generation - > > Needs multi-processing. > > > > High performance image generation - Needs multi-processing, > > sophisticated load management, anti-aliasing, and additional pixel > > fill. > > > > > > > > > > > > -- > > ============================================================================== > > _/_/_/ _/ _/ _/ _/_/ _/_/_/ _/ _/ > > _/ _/ _/ _/ _/ _/ _/ _/ _/ > > _/_/_/ _/ _/ _/ _/ _/ _/ _/_/_/ > > _/ _/ _/ _/ _/ _/ _/ _/ _/ > > _/_/_/ _/ _/_/_/ _/ _/_/ _/_/_/ _/ _/ > > > > _/ _/ _/ _/_/ _/_/_/ _/_/_/ _/_/_/ _/ _/ > > _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ > > _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ > > _/ / _/ _/ _/ _/ _/ _/_/ _/ > > _/ _/ _/_/_/ _/ _/_/_/ _/ _/ _/ > > > > John M. Burwell > > Visual Simulation Market Manager > > Advanced Systems Division > > (415) 390-1743 > > (415) 964-8671 fax > > ============================================================================== > > > >-- End of excerpt from John Burwell > > > > -- > > Regards Svend > > > ********************************************************************* > * Svend Tang-Petersen Email: svend@copen.sgi.com * > * Silicon Graphics Denmark Fax: (+45) 43438606 * > * Herstedoestervej 27-29 Phone: (+45) 43438600 * > * 2620 Albertslund Voice mail: 5-7507 * > * DENMARK * > ********************************************************************* > > > -- > ________________________________________________________________ > Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. > 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. > tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, > > >-- End of excerpt from Rob Jenkins -- Angus Dorbie, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Wed Sep 13 20:08:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id UAA07231; Wed, 13 Sep 1995 20:02:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA07228; Wed, 13 Sep 1995 20:02:34 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03222; Wed, 13 Sep 95 20:02:32 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id UAA11745; Wed, 13 Sep 1995 20:02:26 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id NAA01252 (8.6.12/IDA-1.6); Thu, 14 Sep 1995 13:01:33 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA08356 (5.65c/IDA-1.5); Thu, 14 Sep 1995 12:11:01 +1000 Received: from murad (murad [8.0.0.108]) by aggro with SMTP id MAA03095 (8.6.12/IDA-1.6); Thu, 14 Sep 1995 12:18:29 +1000 Received: by murad (5.65) id AA19549; Thu, 14 Sep 1995 12:21:15 +1000 Date: Thu, 14 Sep 1995 12:21:15 +1000 (EST) From: Simon Bennett X-Sender: simonb@murad To: "Michael J. Smith" Cc: Anita Kishore , info-performer@sgi.sgi.com Subject: Re: using shared memory in Performer In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Wed, 13 Sep 1995, Michael J. Smith wrote: > > happier solution. You can use arena's either directly through IRIX (see the > > manpages for usinit et al) or through Performer - pfDataPools etc... > Well, I'm not sure why you say that IPC calls don't co-exist happily with > IRIX REACT semaphores and shared memory. This just doesn't follow what > system I have running. Two reasons: 1) The IRIX System Programming Guide says they don't 2) We we're orginally using SysV IPC, and although it worked, it was slow and a "bit dodgy" (for want of a better expression) when we moved to IRIX arena IPC, speed and reliability went up. I'm not saying you can't use SysV IPC, (you can, we did, and you obviously do), it's just that there seems to be some pitfalls ( and they don't seem to be MP-safe either - I'd be very interested to hear your experiences with this). To be completely fair, when we were using SysV IPC, we were on IRIX 5.0 - which wasn't entirely stable in itself, so maybe the "incohabitability" problems have been solved? > For my underlying drivers that I have ported to > about 4 different UNIX platforms, I use System V IPC semaphores and > shared memory segments and have had absolutely no problems using it under > a performer 1.2 application. The speed hit may be true, but since the > SYS V semaphores are portable its just a matter of what you are after on > your product and what your programmers are familiar with. I have to, > however, agree that the IRIX REACT seamphores and shared memory segments > are faster, and a preferred choice on SGI platforms -- its just I hate to > write code that is completely unusable on other platforms unless I have a > resource bottleneck by that choice. Fair enough. I agree with you 100%. For our applications, speed is the main thrust. Portability is irrelevant - we're not going to be running Performer on anything else besides SGI's in the near future. Just for interests sake, what version of IRIX have you been running on? What platforms? Maybe that's where the problem lies? I still think thou, that if portability is not an issue, then IRIX arenas are the way to go. It's faster and (I think) simpler (for programmers not familiar with either - I think arenas are easier to grasp - peronal opinion only - I'd been using sockets and SysV IPC for years before I moved to VisSim and found the arena IPC refreshingly simple and efficient). (This isn't an invitation to start a flame war on winopen() vs X BTW) :) +----------------------------------------------------------------------------+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 9981 0611 (x512) Meeting - an event where you take minutes and waste hours. From guest Wed Sep 13 21:24:43 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA07345; Wed, 13 Sep 1995 21:20:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA07342; Wed, 13 Sep 1995 21:20:44 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06090; Wed, 13 Sep 95 21:20:42 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id VAA20488; Wed, 13 Sep 1995 21:20:40 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA06080; Wed, 13 Sep 95 21:20:37 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id VAA17842; Wed, 13 Sep 1995 21:20:36 -0700 Message-Id: <199509140420.VAA17842@surreal.asd.sgi.com> To: bmcquear@dw3f.ess.harris.com Cc: "Lionel Maiaux" , info-performer@sgi.sgi.com Subject: Re: C++ allocation in arena ? In-Reply-To: Your message of "Mon, 11 Sep 95 08:41:48 EDT." <9509111241.AA00315@dw3si.ess.harris.com> Date: Wed, 13 Sep 95 21:20:36 -0700 From: Jim Helman Status: O New and delete are a full three rings of fun. In general global new and delete operators are bad. They are not very extensible since there is only ONE global delete operator, and it must know how to delete anything created by any global new operator. Performer 1.2 creates an overloaded new operator with an extra argument and also overrides THE global delete operator. So if you define an additional global new operator that returns pfMalloc(size_t), DON'T overload the global delete operator, we have special magic in ours. Lionel's suggestion is better because it creates new and delete operators scoped to a class. This is what Performer 2.0 does internally (we no longer muck with global new and delete). But this doesn't help for newing atomic types like float, int, etc. Also, note that if you do overload a new operator whether globally or locally in a class, DO NOT "new" arrays. The following sequence with a user-defined new operator: foos = new((arena *)NULL) foo[n]; delete[] foos; is a really bad idea. The "new" works fine, but the "delete" could end up invoking foo's destructor on the wrong pointers some number of times (n: 0 <= n < 2<<31) and will then attempt to free a bogus address. Surprise. Surprise. Surprise. The compiler guys tell me this is not a bug in SGI's C++ compiler, but a "feature" of the language. When the C++ language was changed so that 'delete [n] foos;' became 'delete [] foos;', inside C++ arrays now needed to cache their lengths. Unfortunately, C++ semantics do not allow this to be not supported for an overloaded new operator. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Sep 13 22:01:26 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA07432; Wed, 13 Sep 1995 21:58:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA07429; Wed, 13 Sep 1995 21:58:05 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07483; Wed, 13 Sep 95 21:58:04 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id VAA25255; Wed, 13 Sep 1995 21:58:03 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA07473; Wed, 13 Sep 95 21:57:59 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id VAA18043; Wed, 13 Sep 1995 21:57:58 -0700 Message-Id: <199509140457.VAA18043@surreal.asd.sgi.com> To: "Michael J. Smith" Cc: Simon Bennett , Anita Kishore , info-performer@sgi.sgi.com Subject: Re: using shared memory in Performer In-Reply-To: Your message of "Wed, 13 Sep 95 16:14:28 EDT." Date: Wed, 13 Sep 95 21:57:57 -0700 From: Jim Helman Status: O In the use of shared memory, regardless of whether it's from Performer or shmget, you should never see a "time lag" between processes, i.e. data not identical in both processes, nor should there be anything that could slow down reads from shared memory once it's in use. It is possible for initial accesses to slow things down a bit when a memory mapped file is involved, but we see this even in Performer when using fPFTMPDIR instead of the default shared memory allocation from swap space (/dev/zero). But there is a very significant speed difference between the IRIX semaphores and locks (usinit(), ussetlock(), uspsema(), ...) and the System V IPC semget()/semop(). The former are highly tuned and really try to avoid a trip into the kernel, which takes a relatively long time. But from a quick look at libc, it looks to me as though every semop() call drops into the kernel, which can be deadly if you are trying to synchronize frequently or at a fine grain. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Sep 13 22:30:46 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA07517; Wed, 13 Sep 1995 22:28:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA07514; Wed, 13 Sep 1995 22:28:09 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08463; Wed, 13 Sep 95 22:28:08 -0700 Received: from cs.tamu.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAB28527; Wed, 13 Sep 1995 22:28:07 -0700 Received: from photon.cs.tamu.edu (424@photon.cs.tamu.edu [128.194.134.1]) by cs.tamu.edu (8.6.10/8.6.4) with ESMTP id AAA25575 for ; Thu, 14 Sep 1995 00:27:54 -0500 From: Jeff Trinkle Received: (trink@localhost) by photon.cs.tamu.edu (8.6.10/8.6.4) id AAA27849 for info-performer@sgi.sgi.com; Thu, 14 Sep 1995 00:27:46 -0500 Date: Thu, 14 Sep 1995 00:27:46 -0500 Message-Id: <199509140527.AAA27849@photon.cs.tamu.edu> To: info-performer@sgi.sgi.com Subject: Showcase 3D models saved in inventor format Status: O Can anyone tell me why Showcase saves 3D models in inventor 1.0 binary format instead of 2.0 binary? My ivcat program seems to handle 2.0, but not 1.0. As it stands, I can't read 3d models produced by Showcase into my Performer application. Help! Jeff Trinkle From guest Thu Sep 14 06:42:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA08120; Thu, 14 Sep 1995 06:40:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA08117; Thu, 14 Sep 1995 06:40:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22441; Thu, 14 Sep 95 06:39:58 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA07904; Thu, 14 Sep 1995 06:39:55 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id GAA02581; Thu, 14 Sep 1995 06:39:49 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id OAA16624; Thu, 14 Sep 1995 14:35:24 +0100 From: "Rob Jenkins" Message-Id: <9509141435.ZM16622@barney.reading.sgi.com> Date: Thu, 14 Sep 1995 14:35:24 +0100 In-Reply-To: reiners@igd.fhg.de "Re: Swapbuffer control problems in multipipe mode" (Sep 12, 12:25pm) References: <4EB1C972ACF@aitec.de> <9509071653.ZM2039@bitch.reading.sgi.com> <9509071634.ZM8457@barney.reading.sgi.com> <9509091557.ZM642@duerer> <9509110928.ZM3958@barney.reading.sgi.com> <9509121225.ZM5403@duerer> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: reiners@igd.fhg.de Subject: Re: Swapbuffer control problems in multipipe mode Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 12, 12:25pm, reiners@igd.fhg.de wrote: > Hmm, as I'm using OpenGL (because I couldn't use IRIS GL GLX on multiple pipes) > I can't use mswapbuffers. > > Is there an OpenGL replacement for mswapbuffers? Maybe in a new feature patch > or > in IRIX 6.2? Any hints? > > I don't need it very badly as my software synchronisation with genlocked pipes > works ok, but sometimes there are frames that have problems, and GANGDRAW would > be a nice and easy way to get rid of them. > > Thanks > > Dirk >-- End of excerpt from reiners@igd.fhg.de mswapbuffers Not supported. Swapping multiple windows (e.g. main and overlay buffers, or windows on separate displays) can be accomplished with multiple calls to though this involves a race condition. so I guess you can do it using the display argument to glXSwapBuffers - if it works OK :-), if not :-( I'll see if I can find any more info. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Thu Sep 14 07:23:35 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA08271; Thu, 14 Sep 1995 07:21:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA08268; Thu, 14 Sep 1995 07:21:25 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23725; Thu, 14 Sep 95 07:21:23 -0700 Received: from beyond.clubfed.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id HAA13513; Thu, 14 Sep 1995 07:21:20 -0700 Received: from hotsauce.clubfed.sgi.com by beyond.clubfed.sgi.com via ESMTP (940816.SGI.8.6.9/911001.SGI) id KAA05872; Thu, 14 Sep 1995 10:19:07 -0400 Received: by hotsauce.clubfed.sgi.com (940816.SGI.8.6.9/930416.SGI.AUTO) id HAA08807; Thu, 14 Sep 1995 07:21:13 -0700 From: "Brian Furtaw" Message-Id: <9509140721.ZM8805@hotsauce.clubfed.sgi.com> Date: Thu, 14 Sep 1995 07:21:09 -0700 In-Reply-To: reiners@igd.fhg.de "Re: Swapbuffer control problems in multipipe mode" (Sep 12, 12:25pm) References: <4EB1C972ACF@aitec.de> <9509071653.ZM2039@bitch.reading.sgi.com> <9509071634.ZM8457@barney.reading.sgi.com> <9509091557.ZM642@duerer> <9509110928.ZM3958@barney.reading.sgi.com> <9509121225.ZM5403@duerer> X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: reiners@igd.fhg.de, "Rob Jenkins" Subject: Re: Swapbuffer control problems in multipipe mode Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 12, 12:25pm, reiners@igd.fhg.de wrote: > Subject: Re: Swapbuffer control problems in multipipe mode > > > Rob Jenkins wrote: > > > > > > 6) Software Modifications > > ------------------------- > > > > To modify an existing program to use the GangDraw mechanism is quite > > easy. You change existing calls to swapbuffers() or mswapbuffers() to > > include the GANGDRAW parameter. > > > > First, change all instances of > > > > swapbuffers(); > > > > to > > > > mswapbuffers(NORMALDRAW); > > > > which are exactly equivilent statements. Next, whenever you want to > > have a synchronized swap (i.e. all pipes swap simultaneously), add > > the GANGDRAW parameter to the mswapbuffers call; e.g. change > > > > mswapbuffers(NORMALDRAW); > > > > to > > > > mswapbuffers(NORMALDRAW | GANGDRAW); > > > >-- End of excerpt from Rob Jenkins > > Hmm, as I'm using OpenGL (because I couldn't use IRIS GL GLX on multiple pipes) > I can't use mswapbuffers. > > Is there an OpenGL replacement for mswapbuffers? Maybe in a new feature patch > or > in IRIX 6.2? Any hints? > > I don't need it very badly as my software synchronisation with genlocked pipes > works ok, but sometimes there are frames that have problems, and GANGDRAW would > be a nice and easy way to get rid of them. > > Thanks > > Dirk >-- End of excerpt from reiners@igd.fhg.de Dirk, Try this to get you by until a permanent solution comes out with 6.2. Create some semaphores: usptr_t* arena = usinit("/usr/tmp/swap_arena"); usema_t* pipe0ready = usnewsema(arena, 0); usema_t* pipe1ready = usnewsema(arena, 0); After the process for pipe 0 finishes its frame, it signals its completion and waits for pipe1. When pipe1 is also ready, pipe0 swaps: usvsema(pipe0ready); uspsema(pipe1ready); glXSwapBuffers(dpy, drawable); The process for pipe 1 does the converse: usvsema(pipe1ready); uspsema(pipe0ready); glXSwapBuffers(dpy, drawable); It's not perfect synchronization but it will disallow one of the pipes to proceed with swapping unless the other pipe is also ready to swap. This should work for you. 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 Brian Furtaw (brian@sgi.com) RSE Graphics/Communications Office: (301) 572-3293 Silver Spring, MD Fax: (301) 572-3280 From guest Thu Sep 14 10:07:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA08763; Thu, 14 Sep 1995 10:03:24 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA08760; Thu, 14 Sep 1995 10:03:22 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01515; Thu, 14 Sep 95 10:03:20 -0700 Received: from nova.unix.portal.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA19299; Thu, 14 Sep 1995 10:03:18 -0700 Received: from uucp1.unix.portal.com ([156.151.4.11]) by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id JAA00222; Thu, 14 Sep 1995 09:59:51 -0700 Received: from buggy.coryphaeus.com (uucp@localhost) by uucp1.unix.portal.com (8.6.11/8.6.5) with UUCP id JAA16693; Thu, 14 Sep 1995 09:54:41 -0700 Received: from buggy. coryphaeus.com by cory via SMTP (920330.SGI/911001.SGI) for portal!wormald.com.au!simonb id AA22146; Thu, 14 Sep 95 09:51:09 -0700 Received: by buggy (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA27471; Thu, 14 Sep 1995 09:51:09 -0700 From: "Kowsik Guruswamy" Message-Id: <9509140951.ZM27469@buggy.coryphaeus.com> Date: Thu, 14 Sep 1995 09:51:08 -0700 In-Reply-To: Simon Bennett "Re: using shared memory in Performer" (Sep 14, 12:21pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Simon Bennett , "Michael J. Smith" Subject: Re: using shared memory in Performer Cc: Anita Kishore , info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 14, 12:21pm, Simon Bennett wrote: > Subject: Re: using shared memory in Performer > I still think thou, that if portability is not an issue, then IRIX arenas > are the way to go. It's faster and (I think) simpler (for programmers not > familiar with either - I think arenas are easier to grasp - peronal opinion > only - I'd been using sockets and SysV IPC for years before I moved to > VisSim and found the arena IPC refreshingly simple and efficient). (This > isn't an invitation to start a flame war on winopen() vs X BTW) :) > > +----------------------------------------------------------------------------+ > Simon Bennett simonb@wormald.com.au Definitely. Take a look at 'Unix Network Programming' by Richard Stevens and there's a whole bunch of overhead just to set up the semaphores/locks which either you write once and reuse or write every time... Personally, I think it's easy to just to do pfGetSemaArena() and then usnewsema() and concentrate on your application rather than look up the man pages for every teeny-tiny setting possible. [I just can't remember the structures!]. K. -- kowsik@coryphaeus.com From guest Thu Sep 14 11:07:50 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA08987; Thu, 14 Sep 1995 11:02:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA08984; Thu, 14 Sep 1995 11:02:17 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05363; Thu, 14 Sep 95 11:02:16 -0700 Received: from ligsg7.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA03831; Thu, 14 Sep 1995 11:01:58 -0700 Received: by ligsg7.epfl.ch (Smail3.1.29.1 #28) id m0stINO-000ESSC; Thu, 14 Sep 95 19:47 MET DST Message-Id: Date: Thu, 14 Sep 95 19:47 MET DST From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) To: info-performer@sgi.sgi.com Subject: reading models in 2.0 Reply-To: matomira@epfl.ch Status: O Will it be possible in 2.0 to read a model from a string (not only from files) ? eg: for cut & pasting inventor models across applications via the X buffer. Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch GVRAI d* s: a- C++++ UI++ !L P-- E W+++ N+++ K? w--- !O M-- V p--- PS+++ PE++ Y+ PGP- t+ 5? X? tv+ b!+++ DI? D+ G- e+++ h-- r++ s !g w+ y* A07 HH PP--- v+++ M[o]+++ (((()))) From guest Thu Sep 14 08:53:36 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA08572; Thu, 14 Sep 1995 08:51:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA08569; Thu, 14 Sep 1995 08:51:15 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27447; Thu, 14 Sep 95 08:51:13 -0700 Received: from gatekeeper.bvr.co.il by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA01059; Thu, 14 Sep 1995 08:50:58 -0700 Received: (from uucp@localhost) by gatekeeper.bvr.co.il (8.6.12/8.6.9) id PAA02961; Thu, 14 Sep 1995 15:51:57 GMT Received: from unknown(192.114.85.105) by gatekeeper.bvr.co.il via smap (V1.3) id sma002959; Thu Sep 14 17:51:39 1995 Received: by genie.bvr.co.il (940816.SGI.8.6.9/911001.SGI) id RAA17697; Thu, 14 Sep 1995 17:50:39 +0200 From: "Ran Yakir" Message-Id: <9509141750.ZM17695@genie.bvr.co.il> Date: Thu, 14 Sep 1995 17:50:38 +0000 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: bryan@control.mdc.com Subject: Re: Bluring in Performer Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Bryan, 1. You should configure the Accumulation Buffer if you want to use it. You do so by calling acsize(16) in your Pipe init function. You'll need to call gconfig() afterwards. If you work with GLX, there is a different way to do so. acsize() may fail if you don't have enough bitplanes. You have to configure the rest of the bitplanes eating features accordingly. If you are using something which is not RE, the situation is different. On Indigos and such, the accumulation buffer is implemented in software, in the host memory. However, you should initialize it by acsize(). 2. If you are running on RE, you might want to try the convolve() function. It gives you convolutions of images in high speed. You'll have to consult the man page for convolve() to see all its features. Basicly, it does a convolution for images that are being rectcopy()id or rectwrite()n. You can set a conolution kernel that blures an image. Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | From guest Thu Sep 14 11:22:58 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA09029; Thu, 14 Sep 1995 11:14:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA09026; Thu, 14 Sep 1995 11:14:14 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06463; Thu, 14 Sep 95 11:14:12 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA08485; Thu, 14 Sep 1995 11:14:10 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA06448; Thu, 14 Sep 95 11:14:05 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA18298; Thu, 14 Sep 1995 11:11:29 -0700 From: "John Rohlf" Message-Id: <9509141111.ZM18296@tubes.asd.sgi.com> Date: Thu, 14 Sep 1995 11:11:29 -0700 In-Reply-To: "Javier Castellar" "Re: Indigo2 impact" (Sep 13, 11:45am) References: <9509131537.ZM26294@moffatt.vislab.su.edu.au> <9509131145.ZM29084@sixty.asd.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Javier Castellar" , "Ben Simons" , info-performer@sgi.sgi.com Subject: Re: Indigo2 impact Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Sep 13, 11:45am, Javier Castellar wrote: > Subject: Re: Indigo2 impact > It is true that the speed on texture loading is very fast on Impact. But it is > also true that in RE/RE2 you have a good speed when you page bilinear textures > using in gl subtexload and in ogl glTexSubImage2DEXT. > > I have seen applications running a very high frame rates with texture paging > enought to meet most of the vissim related needs. > > In order to do it it is mandatory the use of preDraw/PostDraw callbacks the the > above mentioned gl/ogl API. > Note that Performer 2.0 supports subtexloading in both IrisGL and OpenGL. From guest Thu Sep 14 11:28:39 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA09061; Thu, 14 Sep 1995 11:24:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA09058; Thu, 14 Sep 1995 11:24:50 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07333; Thu, 14 Sep 95 11:24:43 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA12139; Thu, 14 Sep 1995 11:24:41 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA07322; Thu, 14 Sep 95 11:24:36 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA02728; Thu, 14 Sep 1995 11:24:37 -0700 Message-Id: <199509141824.LAA02728@surreal.asd.sgi.com> To: reiners@igd.fhg.de Cc: "Rob Jenkins" , info-performer@sgi.sgi.com Subject: Re: Swapbuffer control problems in multipipe mode In-Reply-To: Your message of "Tue, 12 Sep 95 12:25:36 +0200." <9509121225.ZM5403@duerer> Date: Thu, 14 Sep 95 11:24:36 -0700 From: Jim Helman Status: O > Is there an OpenGL replacement for mswapbuffers? Maybe in a new feature patch > or in IRIX 6.2? If you have to do your own swapbuffers synchronization across multiple pipes without Performer, the application semaphore approach is the best. Perfomer uses something similar internally, and it works 99.99% of the time especially when your processes are locked on isolated CPUs. The GANGDRAW and swapready wire approach works 100%, but is only useful for machines in dedicated applications because GANGDRAW imposes significant limitations. Most notably, it does not allow cursor changes (such as are usually caused by moving the mouse between windows) and will crash graphics if you do or if things are not wired correctly. You really do need GANGDRAW when trying to synchronize pipes across one or more separate Onyxes. But in most other cases, host-side synchronization works well enough. GANGDRAW is not yet available via an OpenGL extension. But if you *really* need it in a Performer 2.0 OpenGL-based application, contact us directly. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Sep 14 12:03:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA09267; Thu, 14 Sep 1995 11:58:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA09264; Thu, 14 Sep 1995 11:58:37 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09641; Thu, 14 Sep 95 11:58:36 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA21535; Thu, 14 Sep 1995 11:58:33 -0700 Received: from crusader.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA05964; Thu, 14 Sep 95 14:33:24 EDT Received: by crusader.vsl.ist.ucf.edu (940816.SGI.8.6.9) id OAA10828; Thu, 14 Sep 1995 14:33:23 -0400 From: "Lance Marrou" Message-Id: <9509141433.ZM10826@crusader.vsl.ist.ucf.edu> Date: Thu, 14 Sep 1995 14:33:22 -0400 In-Reply-To: "Ran Yakir" "Synchronized node data" (Sep 14, 6:52pm) References: <9509141852.ZM18825@genie.bvr.co.il> X-Face: GS1@^5kB"i$q<%Li4wMO3Pi#%MpaisQ+U"+@PC7*#(v9jnraY`3+fM7@+4iRV$:QflwXB^N/k7D?#x!T|:Owmj6H,L=lC_oC)'T%J@PC$]Oxr<"M`'o&[1_G|R=!8-pr^K\\_hZ.g>t,fb}z4^o!0NU@c+pJ2Kpe4,Ke\K&[W'$|B*7"|\(TQ%MKj0?`II)-N}a$-sd>aoV=wnH'&q9t8U(&a X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Ran Yakir" , info-performer@sgi.sgi.com Subject: Re: Synchronized node data Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 14, 6:52pm, Ran Yakir wrote: > Subject: Synchronized node data > Hi, > > It seems that there is no (clean, API'd) way to access the frame synchronized > ChanData from within a node draw callback. This data is passed to the main draw > callback, but is not passed on to the callbacks of the nodes themselves, unless > global variables are used ? > Is there a solution to that problem ? > >-- End of excerpt from Ran Yakir I haven't tried it myself yet, but I would think you could use pfGetTravChan() in the node draw callback to get a handle on the channel, then use pfGetChanData() to get a pointer to the channel pass through data. I would hope that the copy of the pass through data is the correct, frame-synchronized data of the draw process, but I couldn't find confirmation in the man pages. Did pfGetChanData() not return frame accurate data? -- ______________________________________________________________________________ /\ ______ /\____ ______ ______ E-mail: marrou@vsl.ist.ucf.edu Visual / / / _ / / __ // ____// ____/ VSL: (407)658-5073 Systems / /__ / /_/ / / / / // /___ / __/_ R. Marrou Fax: (407)658-5059 Lab /____//____/\\/_/ /_//_____//_____/ http://www.vsl.ist.ucf.edu/~marrou "Reap the whirlwind." "We don't need no thought control." From guest Thu Sep 14 11:47:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA09148; Thu, 14 Sep 1995 11:42:58 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA09145; Thu, 14 Sep 1995 11:42:58 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08660; Thu, 14 Sep 95 11:42:55 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA18600; Thu, 14 Sep 1995 11:42:53 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA08654; Thu, 14 Sep 95 11:42:49 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA18369; Thu, 14 Sep 1995 11:40:12 -0700 From: "John Rohlf" Message-Id: <9509141140.ZM18367@tubes.asd.sgi.com> Date: Thu, 14 Sep 1995 11:40:11 -0700 In-Reply-To: "Ran Yakir" "Synchronized node data" (Sep 14, 6:52pm) References: <9509141852.ZM18825@genie.bvr.co.il> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Ran Yakir" , info-performer@sgi.sgi.com Subject: Re: Synchronized node data Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Sep 14, 6:52pm, Ran Yakir wrote: > Subject: Synchronized node data > Hi, > > It seems that there is no (clean, API'd) way to access the frame synchronized > ChanData from within a node draw callback. This data is passed to the main draw > callback, but is not passed on to the callbacks of the nodes themselves, unless > global variables are used ? > Is there a solution to that problem ? > 2.0 has pfGetTravChan() but in 1.2 you will have to set up a global pointer. From guest Thu Sep 14 09:56:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA08746; Thu, 14 Sep 1995 09:53:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA08743; Thu, 14 Sep 1995 09:53:09 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00924; Thu, 14 Sep 95 09:53:07 -0700 Received: from gatekeeper.bvr.co.il by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA16417; Thu, 14 Sep 1995 09:52:37 -0700 Received: (from uucp@localhost) by gatekeeper.bvr.co.il (8.6.12/8.6.9) id QAA03121 for <@gatekeeper.bvr.co.il:info-performer@sgi.com>; Thu, 14 Sep 1995 16:53:50 GMT Received: from unknown(192.114.85.105) by gatekeeper.bvr.co.il via smap (V1.3) id sma003119; Thu Sep 14 18:53:32 1995 Received: by genie.bvr.co.il (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.com id SAA18827; Thu, 14 Sep 1995 18:52:32 +0200 From: "Ran Yakir" Message-Id: <9509141852.ZM18825@genie.bvr.co.il> Date: Thu, 14 Sep 1995 18:52:30 +0000 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Synchronized node data Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, It seems that there is no (clean, API'd) way to access the frame synchronized ChanData from within a node draw callback. This data is passed to the main draw callback, but is not passed on to the callbacks of the nodes themselves, unless global variables are used ? Is there a solution to that problem ? Thanks Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | From guest Thu Sep 14 13:02:19 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA09920; Thu, 14 Sep 1995 12:55:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA09917; Thu, 14 Sep 1995 12:55:32 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13457; Thu, 14 Sep 95 12:55:29 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA06671; Thu, 14 Sep 1995 12:55:29 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA13453; Thu, 14 Sep 95 12:55:22 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA08756; Thu, 14 Sep 1995 12:55:22 -0700 Message-Id: <199509141955.MAA08756@surreal.asd.sgi.com> To: matomira@epfl.ch Cc: info-performer@sgi.sgi.com Subject: Re: reading models in 2.0 In-Reply-To: Your message of "Thu, 14 Sep 95 19:47:00 +0700." Date: Thu, 14 Sep 95 12:55:22 -0700 From: Jim Helman Status: O > Will it be possible in 2.0 to read a model > from a string (not only from files) ? > > eg: for cut & pasting inventor models across applications > via the X buffer. The Perfomer 2.0 IV loader uses Inventor 2.0 or 2.1 to read files and translate the resulting Inventor scene graph into a Performer scene graph. The conversion operation is performed by an exposed routine, pfdConvert_iv(), so you can have Inventor translate the string into an Inventor scene graph and then call pfdConvert_iv() to convert it to a Performer scene graph. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Sep 14 13:23:22 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA10055; Thu, 14 Sep 1995 13:17:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA10052; Thu, 14 Sep 1995 13:17:14 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14962; Thu, 14 Sep 95 13:17:08 -0700 Received: from atc.boeing.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA11379; Thu, 14 Sep 1995 13:17:03 -0700 Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA27135; Thu, 14 Sep 1995 13:19:42 -0700 Received: from aw545.iasl.ca.boeing.com.iasl.ca.boeing.com (aw545.iasl.ca.boeing.com) by aw101.iasl.ca.boeing.com with SMTP id AA10218 (5.67a/IDA-1.4.4 for ); Thu, 14 Sep 1995 13:16:47 -0700 From: "David H. Whittington" Received: by aw545.iasl.ca.boeing.com.info-performer@sgi.sgi.com (5.65c/client-1.3) id AA05484; Thu, 14 Sep 1995 13:16:45 -0700 Message-Id: <199509142016.AA05484@aw545.iasl.ca.boeing.com.info-performer@sgi.sgi.com> Subject: More sample Performer programs To: info-performer@sgi.sgi.com Date: Thu, 14 Sep 1995 13:16:44 -0700 (PDT) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2360 Status: O To: Performerites and PfVictims I tried this idea once before earlier this summer but got no response. So here I go again. I do not want to tread on the proprietary work of anyone, but I just think that we all could get further,faster if we could take the time to post to sgigate a large number of example Performer programs that demonstrate how to get Performer to really shine. I have coded considerable size applications in gl for several years but seem to spend a lot of time experimenting(hacking) with Performer to get a new idea up and running. These short experimental programs (maybe snippets inside of adapted versions of perfly) could be sent in to SGI for anonymous ftp(WWW) access with the qualification to "use at your own risk". I think the areas of computer usage that have advanced the fastest in recent years are the ones where there was much interchange and while I certainly appreciate this user group(I have learned much), many solutions are better expressed in small chunks of code(that really work). Small applications would be welcome as well. I would provide a simple set of changes to perfly that load a terrain model from MULTIGEN or DWB, add an aircraft model(.flt,.medit,.iv,etc...), add some gl based 2D instruments, and give the user an external viewpoint as the aircraft flies with the instruments also being driven. This app sounds trivial but still took me several weeks to do even after lots of gl experience. It just takes a while to get Performerized. SGI did a wonderful thing several years ago and released a set of example programs together called SST. This saved me a lot of development time - some of us are better at the application than the actual low level coding and plenty of example code really helps. I am asking the Performer folks at SGI to consider this request and provide some dialogue on the subject. Thanks to you all! .=========================================================================. / David H. Whittington | Voice: (206) 662-4923 (work) \ | Boeing Commercial Airplane | (206) 662-3425 (lab) | | P.O. Box 3707, M/S 19-MH | Internet: dhw3314@aw101.iasl.ca.boeing.com | \ Seattle, WA 98124-2207 | #include "/boeing/sw/std_disclaimer.h" / `=========================================================================' From guest Fri Sep 15 13:15:37 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA27254; Fri, 15 Sep 1995 13:10:11 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA27251; Fri, 15 Sep 1995 13:10:10 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13764; Fri, 15 Sep 95 13:10:09 -0700 Received: from stealth.afit.af.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA21600; Fri, 15 Sep 1995 13:09:59 -0700 Received: from gecko.afit.af.mil by stealth.afit.af.mil with SMTP id AA14754 (5.65c/IDA-1.4.4 for ); Fri, 15 Sep 1995 16:09:43 -0400 From: Lynda D Myers Received: (ldmyers@localhost) by gecko.afit.af.mil (8.6.12/8.6.9) id QAA06320 for info-performer@sgi.com; Fri, 15 Sep 1995 16:09:39 -0400 Date: Fri, 15 Sep 1995 16:09:39 -0400 Message-Id: <199509152009.QAA06320@gecko.afit.af.mil> To: info-performer@sgi.sgi.com Subject: Morphing Status: O I need to fade one image while bringing in another image. Both images are in .flt format. Is there a function that can do this using these two files as inputs? If not, is there any other way to do it? If ilDilaeImg and ilErodeImg would apply in this case can someone explain how it works. Thank you, Lynda D. Myers e-mail ldmyers@afit.af.mil From guest Fri Sep 15 13:18:01 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA27259; Fri, 15 Sep 1995 13:14:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA27256; Fri, 15 Sep 1995 13:14:10 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13943; Fri, 15 Sep 95 13:14:03 -0700 Received: from stealth.afit.af.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA22429; Fri, 15 Sep 1995 13:13:48 -0700 Received: from gecko.afit.af.mil by stealth.afit.af.mil with SMTP id AA14912 (5.65c/IDA-1.4.4 for ); Fri, 15 Sep 1995 16:13:41 -0400 From: Lynda D Myers Received: (ldmyers@localhost) by gecko.afit.af.mil (8.6.12/8.6.9) id QAA06348 for info-performer@sgi.com; Fri, 15 Sep 1995 16:13:36 -0400 Date: Fri, 15 Sep 1995 16:13:36 -0400 Message-Id: <199509152013.QAA06348@gecko.afit.af.mil> To: info-performer@sgi.sgi.com Subject: Transparency Status: O I am having touble seeing one transparent object through another when rendering objects in performer. Using the no_occlude option in pfTransparency did not solve the problem. Is there another way to do this? Thank you, Lynda D. Myers e-mail ldmyers@afit.af.mil From guest Mon Sep 18 02:25:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA09536; Mon, 18 Sep 1995 02:21:30 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA09533; Mon, 18 Sep 1995 02:21:30 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15499; Mon, 18 Sep 95 02:21:23 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA00746; Mon, 18 Sep 1995 02:21:18 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id CAA27453; Mon, 18 Sep 1995 02:21:16 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id KAA01073; Mon, 18 Sep 1995 10:12:40 +0100 From: "Rob Jenkins" Message-Id: <9509181012.ZM1071@barney.reading.sgi.com> Date: Mon, 18 Sep 1995 10:12:40 +0100 In-Reply-To: Lynda D Myers "Transparency" (Sep 15, 4:13pm) References: <199509152013.QAA06348@gecko.afit.af.mil> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Lynda D Myers , info-performer@sgi.sgi.com Subject: Re: Transparency Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Lynda I found a previous posting by Angus Dorbie that covers this subject very well: ------------------start of Angus's posting----------------------- To determine surface visibility the Z value in the framebuffer the 'destination' pixels is compared with the Z of any incoming pixels being written to because of a polygon surface 'source' pixels. Typically the pixel value whose Z distance is nearest the eye (either 'source' or 'destination') determines what ends up being displayed in the framebuffer. The snag occurs when you write transparent pixels to the framebuffer. If you can imagine a scene where you look through smoked glass, you effectively have a single framebuffer colour, obtained by blending the pixel in the scene beyond the glass with the colour of the glass, you also have a single Z value. Unfortunately these values are derived from two colours and two depth values, both of which are still visible in the scene. First we should consider the problem of rendering this simple scene. If we render the glass first then because of it's nearer Z value it will occlude pixels from polygons beyond it in the scene. We can avoid this by disabling the zbuffer write by the glass, in otherwords it has no Z value and cannot subsequently occlude any polygon pixels. The problem with this solution is that the glass cannot be blended with pixels from subsequently rendered polygons (actually it can but this involves other blendfunctions with their own particular foibles, we'll keep it simple here). The solution which works is to draw the glass last and then everything works without any problems. Performer supports this type of transparency sorting. e.g. pfChanTravMode(Pchan, PFTRAV_CULL , PFCULL_VIEW | PFCULL_SORT); Next we can consider the situation where we've sorted the transparent stuff and we've rendered the scene and the smoked glass correctly, but there is another transparent object in the scene which has been sorted with the smoked glass. If this object is nearer than the smoked glass it will be drawn correctly, but if it is farther away we are back to our original problem; either it is occluded by the glass (glass has Z) or it cannot be partially occluded with the glass (glass has no Z). Previously we solved this problem by drawing transparent objects after opaque objects in the scene, we could occlude the transparent with the opaque and there wasn't a problem. However, here we have to sort transparent objects by Z distance and draw them back to front to produce an accurate scene. Performer doesn't automatically support this kind of transparency sorting. You have to provide it yourself. A quick way to sort your transparent objects is to build them in the scene sorted and attach pre and post draw callbacks to a common parent node to stop them being reshuffled, but this isn't a complete solution (the eye could move!!). Specific situations like alpha keying such as that used when billboarding trees can be greatly improved by culling transparent and/or semi-transparent pixels using ALPHAFUNC and ALPHAREF states. Under many circumstances if the transparent objects are drawn last without sorting they will look reasonable if you ensure the transparent objects don't write to the Z buffer, especially if the alpha values are low, that is what PFTR_NO_OCCLUDE is for. So far we've assumed blendfunction parameters of (BF_SA, BF_MSA) but for layered alpha using the 'destination' alpha value can be of some use in various circumstances when used in conjunction with the equivalent of PFTR_NO_OCCLUDE, but it's slow and isn't a generic solution. Finally there is multisampled transparency, this uses the Reality Engines ability to store more than one colour and one Z value for each pixel to avoid some of the pitfalls of blended transparency. The main problem is that more transparent objects are not visible through more opaque (if you stick with the same mask) and a limited number of transparency values are possible due to the small number of samples per pixel, causing quantisation. -- Angus Dorbie ---------------------------------- end of Angus's posting ----------------- You can get these archives by anonymous ftp from sgigate.sgi.com at: ~ftp/Performer/monthly-archives the posting above was in perf-95-05 Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Mon Sep 18 01:23:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA09313; Mon, 18 Sep 1995 01:18:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA09310; Mon, 18 Sep 1995 01:18:26 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14149; Mon, 18 Sep 95 01:18:25 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA26987; Mon, 18 Sep 1995 01:18:20 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/940406.SGI) id KAA12985; Mon, 18 Sep 1995 10:09:15 +0200 From: "Angus Dorbie" Message-Id: <9509181009.ZM12983@bitch.reading.sgi.com> Date: Mon, 18 Sep 1995 10:09:14 -0600 In-Reply-To: Lynda D Myers "Transparency" (Sep 15, 4:13pm) References: <199509152013.QAA06348@gecko.afit.af.mil> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Lynda D Myers , info-performer@sgi.sgi.com Subject: Re: Transparency Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 15, 4:13pm, Lynda D Myers wrote: > Subject: Transparency > I am having touble seeing one transparent > object through another when rendering objects > in performer. Using the no_occlude option in > pfTransparency did not solve the problem. > Is there another way to do this? > > Thank you, > Lynda D. Myers > e-mail > ldmyers@afit.af.mil > >-- End of excerpt from Lynda D Myers This sounds like youre using multisample transparency on an RE2. If this is the case then you could try PFTR_BLEND_ALPHA | PFTR_NO_OCCLUDE, otherwise the transparency may not show up, depending on drawing order and opacity. -- Angus Dorbie, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Tue Sep 19 10:10:25 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA12724; Tue, 19 Sep 1995 10:07:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA12721; Tue, 19 Sep 1995 10:07:09 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02266; Tue, 19 Sep 95 10:07:07 -0700 Received: from chx400.switch.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA25178; Tue, 19 Sep 1995 10:06:59 -0700 From: ipandzic@cui.unige.ch X400-Received: by mta chx400.switch.ch in /PRMD=Switch/ADMD=Arcom/C=Ch/; Relayed; Tue, 19 Sep 1995 10:57:55 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Tue, 19 Sep 1995 10:57:34 +0200 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Tue, 19 Sep 1995 10:56:48 +0200 Date: Tue, 19 Sep 1995 10:56:48 +0200 X400-Originator: ipandzic@cui.unige.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;950919105648] X400-Content-Type: P2-1984 (2) Content-Identifier: 1037 Alternate-Recipient: Allowed Message-Id: <1037*/S=ipandzic/OU=cui/O=unige/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: info-performer@sgi.sgi.com Subject: GL lines in performer Status: O Hello, I am trying to draw some simple GL lines (bgnline - v3f - endline) in a Performer node's draw traversal function. These lines are sort of markers so I don't want them to be influenced by light, i.e. I want them to have an absolute color, defined by RGBcolor command. To do this I call pfDisable(PFEN_LIGHTING) before, and pfEnable(PFEN_LIGHTING) after drawing the lines. This works fine on a single processor machine like Indigo or Indy, but I get problems on the Onyx - the lines sometimes still don't have the color I want, but get influenced by the light. I don't seem to find on what it depends. Does someone know a better way to draw simple GL lines with absolute color? Thanks, Igor From guest Tue Sep 19 10:55:09 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA12852; Tue, 19 Sep 1995 10:50:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA12849; Tue, 19 Sep 1995 10:50:58 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04243; Tue, 19 Sep 95 10:50:56 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA07302; Tue, 19 Sep 1995 10:50:55 -0700 Received: from nirvana.neu.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id CAA06949; Tue, 19 Sep 1995 02:01:32 -0700 Received: by nirvana.neu.sgi.com (940816.SGI.8.6.9/911001.SGI) id LAA18633; Tue, 19 Sep 1995 11:00:12 +0200 From: "Simon Hayhurst" Message-Id: <9509191100.ZM18631@nirvana.neu.sgi.com> Date: Tue, 19 Sep 1995 11:00:12 -0600 X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: info-performer@sgi.sgi.com, dhw3314@aw101.iasl.ca.boeing.com Subject: More sample Performer programs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O David, >> You said basically, 'lets share more basic Performer snippets ' I couldn't agree more .... I hate re-inventing the wheel, and anything that gets the standard stuff out of the way quickly makes more time for everyone to get on with doing really cool stuff. I'm a newbie so I can't start the ball rolling yet, but its a principle I highly recommend. So out of desperation to have something to offer (money where mouth is and all that), if anyone has been trying to put arrays of objects in shared memory (performer or otherwise) you'll have noticed that SGI compilers default to ::new for array allocation, and its usually undesirable to have the entire world in shared memory .... there is a solution using templates which has some drawbacks, but does make the process of arrays in shared memory at least code-able, and usable ..... anyone want it ? Simon -- -------------------------------------------------------------------------------- Simon Hayhurst Phone (41)-38-433733 Supercomputing Technology Centre Fax (41)-38-433905 Core Technology Group Voice Mail 5-7269 SGI, Cortaillod, Switzerland Internet simon @ neu.sgi.com -------------------------------------------------------------------------------- From guest Tue Sep 19 09:27:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA12634; Tue, 19 Sep 1995 09:24:13 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA12631; Tue, 19 Sep 1995 09:24:12 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00641; Tue, 19 Sep 95 09:24:11 -0700 Received: from cs.sfu.ca by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA13422; Tue, 19 Sep 1995 09:24:04 -0700 From: halliday@cs.sfu.ca Received: from bowen (bowen.cs.sfu.ca) by cs.sfu.ca with SMTP id AA26075 (5.65c/IDA-1.4.4 for <@fornax.cs.sfu.ca:info-performer@sgi.com>); Tue, 19 Sep 1995 09:13:43 -0700 Received: by bowen (940816.SGI.8.6.9/930416.SGI.AUTO) id JAA03602; Tue, 19 Sep 1995 09:13:42 -0700 Message-Id: <199509191613.JAA03602@bowen> Subject: Re: videout & flicker filter To: stereo@well.com (Tim Crane) Date: Tue, 19 Sep 1995 09:13:39 -0800 (PDT) Cc: info-performer@sgi.sgi.com In-Reply-To: from "Tim Crane" at Sep 19, 95 07:56:19 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 450 Status: O > > How do you like those glasses? Are they easy to use. How is the resolution? > does the stereo work well? Thanks The Virtual I-glasses (for those who want to know): I like the resolution 180,000 pixels/eye and the stereo works great. The immersive feeling is not very good because the field of view is narrow and you can see a lot of the real world if you look down (screen is not that close to eye). -- Sean Halliday halliday@cs.sfu.ca From guest Tue Sep 19 08:56:06 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA12549; Tue, 19 Sep 1995 08:50:02 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA12546; Tue, 19 Sep 1995 08:50:01 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29630; Tue, 19 Sep 95 08:50:00 -0700 Received: from mail.Germany.EU.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA05977; Tue, 19 Sep 1995 08:49:53 -0700 Received: by mail.Germany.EU.net with SMTP (5.59:8/EUnetD-2.5.2.b) via EUnet id RAA03037; Tue, 19 Sep 1995 17:43:43 +0200 Received: from AITEC/TEMPQ by aitec.de (Mercury 1.13); Tue, 19 Sep 95 17:43:01 GMT Received: from TEMPQ by AITEC (Mercury 1.13); Tue, 19 Sep 95 17:42:38 GMT From: "Dr. Aris Christidis" Organization: AITEC GmbH & Co KG To: info-performer@sgi.sgi.com Date: Tue, 19 Sep 1995 17:42:38 GMT+1 Subject: Performance problems for root X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <63A32FD2054@aitec.de> Status: O Hello! We have a remarkable problem with a multiprocess-Performer application running with root privileges (setuid or started by root) on a 12 CPU, 3 pipes Onyx under Performer 1.2 and IRIX 5.3: When started in privileged mode, the obtained performance is much lower than when being run by a non-privileged user (intermittent frame delay, 10-30 msec). Any suggestions? Best regards, Aris ChristidisAITEC GmbH & CO Informationstechnologie KG Dr. Aris Christidis Alter Hellweg 50 D-44379 Dortmund Tel.: +49 231 9646545 Fax.: +49 231 9646598 EMail: ac@aitec.de From guest Tue Sep 19 10:59:31 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA12857; Tue, 19 Sep 1995 10:53:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA12854; Tue, 19 Sep 1995 10:53:25 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04332; Tue, 19 Sep 95 10:53:24 -0700 Received: from nova.unix.portal.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA08733; Tue, 19 Sep 1995 10:53:20 -0700 Received: from uucp1.unix.portal.com ([156.151.4.11]) by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id KAA14625; Tue, 19 Sep 1995 10:52:08 -0700 Received: from buggy.coryphaeus.com (uucp@localhost) by uucp1.unix.portal.com (8.6.11/8.6.5) with UUCP id KAA17768; Tue, 19 Sep 1995 10:44:21 -0700 Received: from buggy. coryphaeus.com by cory via SMTP (920330.SGI/911001.SGI) for portal!cui.unige.ch!ipandzic id AA06462; Tue, 19 Sep 95 10:45:26 -0700 Received: by buggy (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA10319; Tue, 19 Sep 1995 10:45:26 -0700 From: "Kowsik Guruswamy" Message-Id: <9509191045.ZM10317@buggy.coryphaeus.com> Date: Tue, 19 Sep 1995 10:45:25 -0700 In-Reply-To: ipandzic@cui.unige.ch "GL lines in performer" (Sep 19, 10:56am) References: <1037*/S=ipandzic/OU=cui/O=unige/PRMD=switch/ADMD=arcom/C=ch/@MHS> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: ipandzic@cui.unige.ch, info-performer@sgi.sgi.com Subject: Re: GL lines in performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 19, 10:56am, ipandzic@cui.unige.ch wrote: > Subject: GL lines in performer > Hello, > > I am trying to draw some simple GL lines (bgnline - v3f - endline) in a > Performer node's draw traversal function. These lines are sort of markers > so I don't want them to be influenced by light, i.e. I want them to have > an absolute color, defined by RGBcolor command. To do this I call > pfDisable(PFEN_LIGHTING) before, and pfEnable(PFEN_LIGHTING) after > drawing the lines. This works fine on a single processor machine like > Indigo or Indy, but > I get problems on the Onyx - the lines sometimes still don't > have the color I want, but get influenced by the light. I don't > seem to find on what it depends. > > Does someone know a better way to draw simple GL lines with absolute color? How about pfPushState(); pfBasicState(); // draw lines here pfPopState(); K. -- kowsik@coryphaeus.com From guest Tue Sep 19 13:59:22 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA13415; Tue, 19 Sep 1995 13:55:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA13412; Tue, 19 Sep 1995 13:55:53 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10168; Tue, 19 Sep 95 13:55:52 -0700 Received: from martinique by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA10667; Tue, 19 Sep 1995 13:55:47 -0700 Received: by martinique (931110.SGI/920502.SGI) for info-performer@sgi.com id AA15438; Tue, 19 Sep 95 14:51:26 -0400 Date: Tue, 19 Sep 95 14:51:26 -0400 From: cfyock@martinique (Christina Fyock) Message-Id: <9509191851.AA15438@martinique> To: info-performer@sgi.sgi.com Subject: Re: GL lines in performer Reply-To: cfyock@martinique.ndhm.gtegsc.com Status: O On Sep 19, 10:56am, ipandzic@cui.unige.ch wrote: > Subject: GL lines in performer > Hello, > > I am trying to draw some simple GL lines (bgnline - v3f - endline) in a > Performer node's draw traversal function. These lines are sort of markers > so I don't want them to be influenced by light, i.e. I want them to have > an absolute color, defined by RGBcolor command. To do this I call > pfDisable(PFEN_LIGHTING) before, and pfEnable(PFEN_LIGHTING) after > drawing the lines. This works fine on a single processor machine like > Indigo or Indy, but > I get problems on the Onyx - the lines sometimes still don't > have the color I want, but get influenced by the light. I don't > seem to find on what it depends. > > Does someone know a better way to draw simple GL lines with absolute color? Try using the call c3f() to set the RGB value of the vector before you call bgnline/v3f/endline. I have had success doing this in Performer in the past when drawing GL lines. ----------------------------------------------------------------------- Christina Fyock GTE Government Systems Needham, MA Email: cfyock@martinique.ndhm.gtegsc.com fyock.christina@mail.ndhm.gtegsc.com From guest Tue Sep 19 11:43:50 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA12945; Tue, 19 Sep 1995 11:39:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA12942; Tue, 19 Sep 1995 11:39:50 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05754; Tue, 19 Sep 95 11:39:49 -0700 Received: from vm.gmd.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA00294; Tue, 19 Sep 1995 11:39:23 -0700 Received: from bogart.mpib-tuebingen.mpg.de by vm.gmd.de (IBM VM SMTP V2R2) with TCP; Tue, 19 Sep 95 20:00:06 +0200 Received: from pumpkin.mpik-tueb.mpg.de by bogart.mpib-tuebingen.mpg.de; (5.65/1.1.8.2/19Dec94-0609PM) id AA02122; Tue, 19 Sep 1995 20:04:38 +0100 Received: by pumpkin (940816.SGI.8.6.9/930416.SGI) for info-performer@sgi.com id UAA03066; Tue, 19 Sep 1995 20:01:56 +0200 From: "Hartwig Distler" Message-Id: <9509192001.ZM3064@pumpkin.mpik-tueb.mpg.de> Date: Tue, 19 Sep 1995 20:01:56 +0000 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: react and performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, I think I already saw the following question concerning react and performer sometime ago on this list, but don't remember any reply. Does anybody know if its possible to use REACT and Performer side by side to optimize performance of real-time applications or do the two libraries conflict in their process scheduling (frame scheduling, interrupt handling, memory locking, etc ..) ? If performer and REACT can be used side by side I would appreciate if somebody could give me a pointer on how to setup up the whole processing environment. hartwig -- @@@@@@@@@@ @@@@@@@ @@@ Hartwig Distler @@@@@@@@@@@ @@@@@@@@ @@@ MPI for Biological Cybernetics @@! @@! @@! @@! @@@ @@! Spemannstr. 38 !@! !@! !@! !@! @!@ !@! 72076 Tuebingen, Germany @!! !!@ @!@ @!@@!@! !!@ FON: +49-7071/601-622 !@! ! !@! !!@!!! !!! FAX: +49-7071/601-616 !!: !!: !!: !!: email: mad@mpik-tueb.mpg.de :!: :!: :!: :!: ::: :: :: :: : : : : www: http://www.mpik-tueb.mpg.de/people/personal/mad/mad.html From guest Tue Sep 19 13:50:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA13372; Tue, 19 Sep 1995 13:48:02 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA13369; Tue, 19 Sep 1995 13:48:01 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09908; Tue, 19 Sep 95 13:47:59 -0700 Received: from gatekeeper.ray.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA09084; Tue, 19 Sep 1995 13:47:56 -0700 Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id QAA02318 for ; Tue, 19 Sep 1995 16:42:45 -0400 Received: from swlgza.msd.ray.com by gatekeeper.ray.com; Tue Sep 19 16:47:44 1995 Received: (from tjc@localhost) by swlgza.msd.ray.com (950215.SGI.8.6.10/8.6.12) id QAA14483 for info-performer@sgi.com; Tue, 19 Sep 1995 16:47:20 -0400 From: "Timothy Cormier" Message-Id: <9509191647.ZM14481@swlgza.msd.ray.com> Date: Tue, 19 Sep 1995 16:47:20 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Image Library effects through Performer calls Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Are there Performer calls that would allow for bluring/dirtying an image before being displayed. I have a flight database and am using a Performer application to view the scene. I now would like to alter that same scene, possibly in a preDraw callback. Thanks in advance for any hints! From guest Tue Sep 19 17:47:55 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA14639; Tue, 19 Sep 1995 17:33:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA14636; Tue, 19 Sep 1995 17:33:21 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18302; Tue, 19 Sep 95 17:33:18 -0700 Received: from internet-mail.ford.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id RAA15737; Tue, 19 Sep 1995 17:29:29 -0700 Message-Id: <199509200029.RAA15737@sgi.sgi.com> Received: by internet-mail.ford.com id (InterLock SMTP Gateway 3.0 for info-performer@sgi.com); Tue, 19 Sep 1995 20:29:28 -0400 Received: by internet-mail.ford.com (Protected-side Proxy Mail Agent-1); Tue, 19 Sep 1995 20:29:28 -0400 Received: by internet-mail.ford.com (Protected-side Proxy Mail Agent-0); Tue, 19 Sep 1995 20:29:28 -0400 From: "Russ Navarre" Date: Tue, 19 Sep 1995 17:40:41 -0400 X-Mailer: Z-Mail (3.2.1 15feb95) To: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > Virtual I-glasses > resolution 180,000 pixels/eye That resolution seems very poor to do anything with. Most HMD's are at least VGA (640x480=307200 pixels). -- ------------------------------------------------------------------------------ Russ Navarre Phone: (313) 322-9588 Adv. Graphics Software Developer Fax: (313) 594-1193 Ford Motor Company Email: rnavarre@ford.com Room 1122, Building#5 20000 Rotunda Drive Dearborn, MI 48121 ------------------------------------------------------------------------------ From guest Tue Sep 19 14:49:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA13678; Tue, 19 Sep 1995 14:45:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA13675; Tue, 19 Sep 1995 14:45:30 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12147; Tue, 19 Sep 95 14:45:24 -0700 Received: from banshee.camberva.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA26012; Tue, 19 Sep 1995 14:45:19 -0700 Received: by banshee.camberva.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id RAA06035; Tue, 19 Sep 1995 17:47:50 -0400 From: plevy@banshee.camberva.com (Paul Levy) Message-Id: <199509192147.RAA06035@banshee.camberva.com> Subject: Positional Accuracy To: info-performer@sgi.sgi.com Date: Tue, 19 Sep 1995 17:47:46 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 615 Status: O We are flying around a relatively large database that was created from DTED data. The database has been translated to its correct lat lon position. The problem we have is the X,Y,Z numbers are so large, the image seems to jitter eventhough the eyepoint is stationary. I would appreciate any existing solutions or workarounds. Thanks ================================================================================ Paul A. Levy Interactive Simulation Group Camber Corporation E-mail: plevy@camberva.com 7411 Alban Station Court, Ste B250 Voice: (703)866-5404 Springfield, Virginia 22150 Fax: (703)866-5409 From guest Tue Sep 19 15:03:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA13874; Tue, 19 Sep 1995 14:58:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA13871; Tue, 19 Sep 1995 14:58:40 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12621; Tue, 19 Sep 95 14:58:37 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA00473; Tue, 19 Sep 1995 14:58:35 -0700 Received: from tracey.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id OAA05406; Tue, 19 Sep 1995 14:56:06 -0700 Received: by tracey.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id OAA01343; Tue, 19 Sep 1995 14:53:23 -0700 From: "Anita Kishore" Message-Id: <9509191453.ZM1341@tracey.electrogig.com> Date: Tue, 19 Sep 1995 14:53:22 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Help on converting image data to performer pfTexture type Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19509191453.ZM1341.electrogig.com" Status: O -- --PART-BOUNDARY=.19509191453.ZM1341.electrogig.com Content-Type: text/plain; charset=us-ascii Can someone help me with the following: I generate an image that looks like a checkerboard ( as given in the open GL book, page 261) and use that image in pfTexImage API hoping to be able to map this new texture on to my geometry which is a square facing the user. But instead of a check image I get a solid purple square. If I change the number of components/pixel in the API, then I don't get anything. What am I doing wrong? I am enclosing a small smaple program to demo this. Thanks for any help. -anita --PART-BOUNDARY=.19509191453.ZM1341.electrogig.com X-Zm-Content-Name: texPF.c Content-Description: Text Content-Type: text/plain ; name="texPF.c" ; charset=us-ascii #include #include #include #include #include int xsize, ysize; pfTexture *tex; void *arena; void makeTexture(void); pfGroup *MkScene(); pfGeoSet *makeGeometry(void); int main(int argc, char *argv[]) { pfPipe *p; pfChannel *chan; pfScene *scene; pfGroup *root; pfCoord view; pfPipeWindow *pw; pfInit(); pfConfig(); arena = pfGetSharedArena(); makeTexture(); scene = pfNewScene(); if ((root = MkScene()) == NULL) { printf("Unable to create scene data base....\n"); pfExit(); exit(-1); } pfAddChild(scene, root); p = pfGetPipe(0); pw = pfNewPWin(p); pfPWinType(pw, PFWIN_TYPE_X); pfPWinName(pw, "Textures"); pfPWinOriginSize(pw, 100, 100, 100+720, 100+486); pfOpenPWin(pw); chan = pfNewChan(p); pfChanScene(chan, scene); pfChanNearFar(chan, 1.0f, 10000.0f); pfChanFOV(chan, 10.0f, -1.0f); pfSetVec3(view.hpr, 0, 0, 0); pfSetVec3(view.xyz, 0, -50, 0); pfChanView(chan, view.xyz, view.hpr); while (1) { pfSync(); pfFrame(); } pfExit(); exit(0); } void makeTexture() { int i, j, r, c; unsigned long img[64][64][3]; tex = pfNewTex(arena); xsize = ysize = 64; /* make check image : from openGL book */ for ( i = 0; i < ysize; i++ ) for ( j = 0; j < xsize; j++ ) { c = ((((i&0x8)==0)^((j&0x8))==0)) * 255; img[i][j][0] = (unsigned long) c; img[i][j][1] = (unsigned long) c; img[i][j][2] = (unsigned long) c; } pfTexImage(tex, img, 2, xsize, ysize, 1); } pfGroup *MkScene() { pfGroup *group; pfGeode *geode; pfGeoSet *geometry; group = pfNewGroup(); geode = pfNewGeode(); geometry = makeGeometry(); pfAddGSet(geode, geometry); pfAddChild(group, geode); return group; } #define GEO_SIZE 1.0f pfGeoSet *makeGeometry(void) { pfGeoSet *gset; pfGeoState *gst; pfTexEnv *tenv; static pfVec3 verts[] ={{-GEO_SIZE, 0, -GEO_SIZE}, { GEO_SIZE, 0, -GEO_SIZE}, { GEO_SIZE, 0, GEO_SIZE}, {-GEO_SIZE, 0, GEO_SIZE}}; static ushort vindex[] ={0, 1, 2, 3}; /* front */ static pfVec3 norms[] ={{ 0.0f, -1.0f, 0.0f}}; static ushort nindex[] ={0}; static pfVec2 tcoords[] ={{0.0f, 0.0f}, {1.0f, 0.0f}, {1.0f, 1.0f}, {0.0f, 1.0f}}; static ushort tindex[] ={0, 1, 2, 3}; gset = pfNewGSet(arena); pfGSetAttr(gset, PFGS_COORD3, PFGS_PER_VERTEX, verts, vindex); pfGSetAttr(gset, PFGS_NORMAL3, PFGS_PER_PRIM, norms, nindex); pfGSetAttr(gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, tcoords, tindex); pfGSetPrimType(gset, PFGS_QUADS); pfGSetNumPrims(gset, 1); gst = pfNewGState(arena); pfGStateMode(gst, PFSTATE_ENTEXTURE, 1); pfGSetGState(gset, gst); /*tex = pfNewTex(arena); pfLoadTexFile(tex, "/disk4/people/kishore/performer/data/smallGlobeDesat.rgb"); */ pfGStateAttr(gst, PFSTATE_TEXTURE, tex); tenv = pfNewTEnv(arena); pfTEnvMode(tenv, PFTE_DECAL); pfGStateAttr(gst, PFSTATE_TEXENV, tenv); return gset; } --PART-BOUNDARY=.19509191453.ZM1341.electrogig.com-- From guest Tue Sep 19 20:16:40 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id UAA16144; Tue, 19 Sep 1995 20:13:49 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA16141; Tue, 19 Sep 1995 20:13:48 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03521; Tue, 19 Sep 95 20:13:47 -0700 Received: from iss.nus.sg by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA04466; Tue, 19 Sep 1995 20:09:56 -0700 Received: from whitehead.iss.nus.sg by iss.nus.sg (5.x/SMI-SVR4) id AA02435; Wed, 20 Sep 1995 10:55:26 +0800 Date: Wed, 20 Sep 1995 10:55:26 +0800 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9509200255.AA02435@iss.nus.sg> Received: by whitehead.iss.nus.sg (5.0/SMI-SVR4) id AA00919; Wed, 20 Sep 95 10:55:26 SST To: info-performer@sgi.sgi.com Subject: Video images of people in Performer Status: O Hi, We are doing an experiment with placing video images of people in VRs. We are collecting the live image with a Indy (by the way, the Indy camera is just about junk, sorry SGI folks). What we would like to do is separate out the "talking head" from the background without using something like chroma-key, since we hope that people can use the technique in their offices (so we want to advoid placing a blue curtain behind people). We are having problems with our simple algorithm of sampling the background and then doing a delta when the "talking head" starts to get the pixels that are different. Just wondering if any of you have already tried this and have some suggestions on the best way to cut out the person from the background. thanks, Kim. From guest Tue Sep 19 20:37:29 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id UAA16531; Tue, 19 Sep 1995 20:34:30 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA16528; Tue, 19 Sep 1995 20:34:29 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04076; Tue, 19 Sep 95 20:34:28 -0700 Received: from iss.nus.sg by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA12876; Tue, 19 Sep 1995 20:34:21 -0700 Received: from whitehead.iss.nus.sg by iss.nus.sg (5.x/SMI-SVR4) id AA02458; Wed, 20 Sep 1995 10:59:16 +0800 Date: Wed, 20 Sep 1995 10:59:16 +0800 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9509200259.AA02458@iss.nus.sg> Received: by whitehead.iss.nus.sg (5.0/SMI-SVR4) id AA00920; Wed, 20 Sep 95 10:58:48 SST To: rnavarre@ford.com Cc: info-performer@sgi.sgi.com In-Reply-To: <199509200029.RAA15737@sgi.sgi.com> (rnavarre@ford.com) Status: O We have quite a few of the Virtual I/O glasses. The 180k pixel resolution is actually quite nice. I don't have too much problem reading the text for the performer GUI for example. The only real problem is field of view. From a cost, resolution, durability standpoint the HMD is the best ever, but field-of-view is not there yet. Kim. From guest Tue Sep 19 20:51:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id UAA16986; Tue, 19 Sep 1995 20:49:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA16983; Tue, 19 Sep 1995 20:49:25 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04535; Tue, 19 Sep 95 20:49:24 -0700 Received: from Crazypete.AI.SRI.COM by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id UAA16118; Tue, 19 Sep 1995 20:49:22 -0700 Received: by Crazypete.AI.SRI.COM (950511.SGI.8.6.12.PATCH526/940406.SGI.AUTO) id UAA09545; Tue, 19 Sep 1995 20:49:17 -0700 From: "Stephen Lau" Message-Id: <9509192049.ZM9543@Crazypete.AI.SRI.COM> Date: Tue, 19 Sep 1995 20:49:15 -0700 In-Reply-To: trdecarlo@tasc.com "Re: Positional Accuracy" (Sep 19, 11:19pm) References: <9509200419.AA15542@sun.aitc.rest.tasc.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com, plevy@banshee.camberva.com Subject: Re: Positional Accuracy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O >We are flying around a relatively large database that was created from >DTED data. The database has been translated to its correct lat lon position. >The problem we have is the X,Y,Z numbers are so large, the image seems >to jitter eventhough the eyepoint is stationary. I would appreciate any >existing solutions or workarounds. We have an application that allows a person wander over a very large database and our solution is to keep track of the eyepoint but always draw as though the eye was always at 0,0,0. The polygon vertices are all offsets from the eyepoint. This eliminates the eye jitter problem and curvature of the Earth/clipping plane elminates the rest. Steve From guest Tue Sep 19 20:32:01 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id UAA16381; Tue, 19 Sep 1995 20:28:28 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA16375; Tue, 19 Sep 1995 20:28:27 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03975; Tue, 19 Sep 95 20:28:26 -0700 Received: from sun.aitc.rest.tasc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA11638; Tue, 19 Sep 1995 20:28:19 -0700 From: trdecarlo@tasc.com Received: from remote3.is.rest.tasc.com by sun.aitc.rest.tasc.com (NX5.67e/NX3.0M-TASCnet-003) id AA15542; Tue, 19 Sep 95 23:19:16 -0500 Date: Tue, 19 Sep 95 23:19:16 -0500 Message-Id: <9509200419.AA15542@sun.aitc.rest.tasc.com> Subject: Re: Positional Accuracy To: plevy@banshee.camberva.com (Paul Levy), info-performer@sgi.sgi.com X-Mailer: AIR Mail 3.X (SPRY, Inc.) Status: O One solution I've seen used is to translate your world origin nearer to your dataset position by some constant value. Then it is easy to recalculate to "actual" coords from the offset coords, and you'll avoid the floating point round-off. (This assumes that you are using the center of the earth as the world origin.) Thom <---- Begin Included Message ----> Date: Tue, 19 Sep 1995 17:47:46 -0400 (EDT) From: plevy@banshee.camberva.com (Paul Levy) Subject: Positional Accuracy To: info-performer@sgi.com We are flying around a relatively large database that was created from DTED data. The database has been translated to its correct lat lon position. The problem we have is the X,Y,Z numbers are so large, the image seems to jitter eventhough the eyepoint is stationary. I would appreciate any existing solutions or workarounds. Thanks ============================================================================== == Paul A. Levy Interactive Simulation Group Camber Corporation E-mail: plevy@camberva.com 7411 Alban Station Court, Ste B250 Voice: (703)866-5404 Springfield, Virginia 22150 Fax: (703)866-5409 <---- End Included Message ----> 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 email: trdecarlo@tasc.com * email: thom@dogwood.tec.army.mil ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ . . . Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is not-deterministic. The question of the existence of my views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal polytheism is beyond the scope of this article.) ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ From guest Tue Sep 19 20:42:19 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id UAA16652; Tue, 19 Sep 1995 20:39:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA16648; Tue, 19 Sep 1995 20:39:31 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04212; Tue, 19 Sep 95 20:39:30 -0700 Received: from sun.aitc.rest.tasc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA14313; Tue, 19 Sep 1995 20:39:23 -0700 From: trdecarlo@tasc.com Received: from remote3.is.rest.tasc.com by sun.aitc.rest.tasc.com (NX5.67e/NX3.0M-TASCnet-003) id AA15575; Tue, 19 Sep 95 23:30:20 -0500 Date: Tue, 19 Sep 95 23:30:20 -0500 Message-Id: <9509200430.AA15575@sun.aitc.rest.tasc.com> Subject: Re: Transparency To: Lynda D Myers , info-performer@sgi.sgi.com X-Mailer: AIR Mail 3.X (SPRY, Inc.) Status: O I have seen similar problems when loading Multigen models which contain transparent parts (though i'm sure it will happen with other models, too). I think the problem is the order of rendering. I don't think Performer does any pre-sorting of transparent parts, and to get transparent parts to render correctly, they should probably be rendered after all opaque parts and sorted to render back to front. The MultiGen modeller allows priority to be applied to parts, this can change the order of rendering. I'm sure that something within Performer will let you assign higher priority to your transparent parts so they can be drawn last. I just don't know if you can sort them easily. Thom <---- Begin Included Message ----> Date: Fri, 15 Sep 1995 16:13:36 -0400 From: Lynda D Myers Subject: Transparency To: info-performer@sgi.com I am having touble seeing one transparent object through another when rendering objects in performer. Using the no_occlude option in pfTransparency did not solve the problem. Is there another way to do this? Thank you, Lynda D. Myers e-mail ldmyers@afit.af.mil <---- End Included Message ----> 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 email: trdecarlo@tasc.com * email: thom@dogwood.tec.army.mil ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ . . . Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is not-deterministic. The question of the existence of my views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal polytheism is beyond the scope of this article.) ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ From guest Tue Sep 19 22:12:50 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA18592; Tue, 19 Sep 1995 22:06:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA18588; Tue, 19 Sep 1995 22:06:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06668; Tue, 19 Sep 95 22:06:04 -0700 Received: from chx400.switch.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA26006; Tue, 19 Sep 1995 22:05:57 -0700 From: ipandzic@cui.unige.ch X400-Received: by mta chx400.switch.ch in /PRMD=Switch/ADMD=Arcom/C=Ch/; Relayed; Wed, 20 Sep 1995 07:05:44 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Wed, 20 Sep 1995 07:05:41 +0200 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Wed, 20 Sep 1995 07:05:36 +0200 Date: Wed, 20 Sep 1995 07:05:36 +0200 X400-Originator: ipandzic@cui.unige.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;950920070536] X400-Content-Type: P2-1984 (2) Content-Identifier: 1042 Alternate-Recipient: Allowed Message-Id: <1042*/S=ipandzic/OU=cui/O=unige/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: info-performer@sgi.sgi.com In-Reply-To: <9509200255.AA02435@iss.nus.sg> Subject: RE: Video images of people in Performer Status: O > Hi, > We are doing an experiment with placing video images of people in VRs. > We are collecting the live image with a Indy (by the way, the Indy > camera is just about junk, sorry SGI folks). > What we would like to do is separate out the "talking head" from the > background without using something like chroma-key, since we hope that > people can use the technique in their offices (so we want to advoid > placing a blue curtain behind people). > We are having problems with our simple algorithm of sampling the > background and then doing a delta when the "talking head" starts to > get the pixels that are different. > Just wondering if any of you have already tried this and have some > suggestions on the best way to cut out the person from the background. > thanks, Kim. Hi, We are about the same thing in a quite simple way - just take an image of the background WITHOUT the talking head and store it in memory. Then in each frame we compare the backgroung with the current frame and the head is where we find a significant difference. This is simple to implement and works not-too-badly. It requires a static backgroung, i.e. if a colegue is working behind you in the camera field of view it won't work. Hope this helps, Igor +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Igor Pandzic ipandzic@cui.unige.ch MIRALab University of Geneva tel. +41/22/705 76 56 24, rue General-Dufour 705 77 63 CH-1211 GENEVE 4 SWITZERLAND fax +41/22/705 77 80 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From guest Tue Sep 19 23:28:34 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA20105; Tue, 19 Sep 1995 23:21:11 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id XAA20102; Tue, 19 Sep 1995 23:21:10 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08187; Tue, 19 Sep 95 23:21:09 -0700 Received: from iss.nus.sg by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id XAA05622; Tue, 19 Sep 1995 23:17:37 -0700 Received: from whitehead.iss.nus.sg by iss.nus.sg (5.x/SMI-SVR4) id AA05109; Wed, 20 Sep 1995 14:20:14 +0800 Date: Wed, 20 Sep 1995 14:20:14 +0800 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9509200620.AA05109@iss.nus.sg> Received: by whitehead.iss.nus.sg (5.0/SMI-SVR4) id AA01073; Wed, 20 Sep 95 14:20:09 SST To: ipandzic@cui.unige.ch Cc: info-performer@sgi.sgi.com In-Reply-To: <1042*/S=ipandzic/OU=cui/O=unige/PRMD=switch/ADMD=arcom/C=ch/@MHS> Subject: RE: Video images of people in Performer Status: O Hi, >> >> Hi, >> >> We are about the same thing in a quite simple way - just take an image >> of the background WITHOUT the talking head and store it in memory. Then >> in each frame we compare the backgroung with the current frame and the >> head is where we find a significant difference. This is simple to implement >> and works not-too-badly. It requires a static backgroung, i.e. if a >> colegue is working behind you in the camera field of view it won't work. >> >> Hope this helps, >> Igor >> Sorry, I think I didn't state the problem clearly in the first message. This is the same approach that we tried. Our problem seems to be that 1) the indy camera is terrible, the iris is so small we have to light the person to get it to work. 2) the Indy seems to "pulse", the values aren't stable and so we get problems like the dark hair of people fading in and out of the background. Do you do any cleanup algorithm to look for isolated pixels? What machine do you use, Indy or PC? Love to share code. thanks, Kim. From guest Wed Sep 20 02:02:26 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA23272; Wed, 20 Sep 1995 01:55:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA23269; Wed, 20 Sep 1995 01:55:09 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11894; Wed, 20 Sep 95 01:55:07 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA22896; Wed, 20 Sep 1995 01:55:06 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id BAA25606; Wed, 20 Sep 1995 01:54:59 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id JAA09196; Wed, 20 Sep 1995 09:44:02 +0100 From: "Rob Jenkins" Message-Id: <9509200944.ZM9194@barney.reading.sgi.com> Date: Wed, 20 Sep 1995 09:44:01 +0100 In-Reply-To: "Timothy Cormier" "Image Library effects through Performer calls" (Sep 19, 4:47pm) References: <9509191647.ZM14481@swlgza.msd.ray.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Timothy Cormier" , info-performer@sgi.sgi.com Subject: Re: Image Library effects through Performer calls Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19509200944.ZM9194.reading.sgi.com" Status: O -- --PART-BOUNDARY=.19509200944.ZM9194.reading.sgi.com Content-Type: text/plain; charset=us-ascii Timothy There is a discussion on the subject of image processing effects in the monthly archives. You can get the archives by anonymous ftp from: sgigate.sgi.com:~ftp/Performer/monthly-archives the attached posting from Ran Yakir is on the subject of convolve and is in perf-95-05. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, --PART-BOUNDARY=.19509200944.ZM9194.reading.sgi.com X-Zm-Content-Name: convolveUsage Content-Description: Text Content-Type: text/plain ; name="convolveUsage" ; charset=us-ascii Kathy, I'm afraid that doing image processing with the host CPU, will get you nowhere. As you said, only the lrectread() and lrectwrite() is bad enough. That is, ofcourse, for a resolution of 640 X 480. If you are willing to render the image at a lower resolution when the defocus is on, you might be able to do this. Using the convolve() function of the RE will have better results. I've tried bluring an OTW image with convolve() and those are the results : kernel size resolution time (milisec) ----------- ---------- ---- 3X3 seperable 640X480 10 5X5 seperable 640X480 12 7X7 seperable 640X480 15 If your application is drawing the scene in less than 15 milisec, you might have 30 Hz with 7X7 convlution. Note that I've used the CV_SEPERABLE convolution which is less accurate, but faster. I can measure the CV_GENERAL convolution if you like. A substantial performance gain is achieved by using 8 bit pixel operations instead of 24 bit. This is possible in your case since you use monochrome image. The following code does the job : ... static float kernel3[] = { 1/6, 1/6, 1/6, 1/6, 1/6, 1/6 }; static float kernel5[] = { 1/10, 1/10, 1/10, 1/10, 1/10, 1/10, 1/10, 1/10, 1/10, 1/10 }; static float kernel7[] = { 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14 }; float *kernel; /* * select the appropriate kernel */ switch (shared->blur_kernel_size) { case 3 : kernel = kernel3; break; case 5 : kernel = kernel3; break; case 7 : kernel = kernel3; break; default : return; } /* * set up the convolution params */ convolve (CV_SEPARABLE, CV_REDUCE, shared->blur_kernel_size, shared->blur_kernel_size, kernel, 0.0f); /* * set up pixel op. mode to monochrome (input - I, output - RGB) */ pixmode (PM_SIZE, 8); pixmode (PM_INPUT_TYPE, PM_UNSIGNED_BYTE); pixmode (PM_INPUT_FORMAT, PM_LUMINANCE); pixmode (PM_OUTPUT_FORMAT, PM_BGR); /* * copy the original image to another part of the screen */ rectcopy (mx0, my0, mx1, my1, to_x, to_y); /* * restore everithing to normal */ pixmode (PM_SIZE, 32); pixmode (PM_INPUT_FORMAT, PM_ABGR); pixmode (PM_OUTPUT_FORMAT, PM_ABGR); convolve (CV_OFF, CV_REDUCE, 3, 3, kernel, 0.0f); } As for the accumulation buffer, anything you do with it requires multiple rendering. You can have realtime performance only if you scene is drawn _very_ fast. Regards, Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | --PART-BOUNDARY=.19509200944.ZM9194.reading.sgi.com-- From guest Wed Sep 20 05:51:40 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA27355; Wed, 20 Sep 1995 05:44:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA27352; Wed, 20 Sep 1995 05:44:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15284; Wed, 20 Sep 95 05:44:05 -0700 Received: from gothamcity.jsc.nasa.gov by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA11443; Wed, 20 Sep 1995 05:43:59 -0700 Received: from robin (robin.jsc.nasa.gov) by gothamcity.jsc.nasa.gov (4.1/25) id AA02792; Wed, 20 Sep 95 07:42:00 CDT Date: Wed, 20 Sep 95 07:42:00 CDT From: lac@gothamcity.jsc.nasa.gov (Lac Nguyen) Message-Id: <9509201242.AA02792@gothamcity.jsc.nasa.gov> Apparently-To: Status: O David, >> You said basically, 'lets share more basic Performer snippets ' I think many performer users would agree your idea. From guest Wed Sep 20 01:52:13 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA23067; Wed, 20 Sep 1995 01:44:14 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA23064; Wed, 20 Sep 1995 01:44:13 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11764; Wed, 20 Sep 95 01:44:04 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA22016; Wed, 20 Sep 1995 01:44:00 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/940406.SGI) id KAA08678; Wed, 20 Sep 1995 10:30:13 +0200 From: "Angus Dorbie" Message-Id: <9509201030.ZM8676@bitch.reading.sgi.com> Date: Wed, 20 Sep 1995 10:30:13 -0600 In-Reply-To: ipandzic@cui.unige.ch "GL lines in performer" (Sep 19, 10:56am) References: <1037*/S=ipandzic/OU=cui/O=unige/PRMD=switch/ADMD=arcom/C=ch/@MHS> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: ipandzic@cui.unige.ch, info-performer@sgi.sgi.com Subject: Re: GL lines in performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O The problem here is probably the material mode. You must ensure that the RGBcolor call is setting a colour value and not simply modifying some material properties. Look at the manual entry for lmcolor() and pfMtlColorMode(). A call like lmcolor(LMC_COLOR); should fix your lines, but you probably want to ensure that you reinstate the previous mode afterwards. On Sep 19, 10:56am, ipandzic@cui.unige.ch wrote: > Subject: GL lines in performer > Hello, > > I am trying to draw some simple GL lines (bgnline - v3f - endline) in a > Performer node's draw traversal function. These lines are sort of markers > so I don't want them to be influenced by light, i.e. I want them to have > an absolute color, defined by RGBcolor command. To do this I call > pfDisable(PFEN_LIGHTING) before, and pfEnable(PFEN_LIGHTING) after > drawing the lines. This works fine on a single processor machine like > Indigo or Indy, but > I get problems on the Onyx - the lines sometimes still don't > have the color I want, but get influenced by the light. I don't > seem to find on what it depends. > > Does someone know a better way to draw simple GL lines with absolute color? > > Thanks, > Igor > >-- End of excerpt from ipandzic@cui.unige.ch -- Angus Dorbie, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Wed Sep 20 02:46:32 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA24223; Wed, 20 Sep 1995 02:39:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA24220; Wed, 20 Sep 1995 02:39:07 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12488; Wed, 20 Sep 95 02:39:03 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA26953; Wed, 20 Sep 1995 02:38:58 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/940406.SGI) id LAA08742; Wed, 20 Sep 1995 11:24:52 +0200 From: "Angus Dorbie" Message-Id: <9509201124.ZM8740@bitch.reading.sgi.com> Date: Wed, 20 Sep 1995 11:24:52 -0600 In-Reply-To: fair@iss.nus.sg (Kim Michael Fairchild) "RE: Video images of people in Performer" (Sep 20, 2:20pm) References: <9509200620.AA05109@iss.nus.sg> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: fair@iss.nus.sg (Kim Michael Fairchild), ipandzic@cui.unige.ch Subject: Re: Video images of people in Performer Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 20, 2:20pm, Kim Michael Fairchild wrote: > Subject: RE: Video images of people in Performer > Hi, > > >> > >> Hi, > >> > >> We are about the same thing in a quite simple way - just take an image > >> of the background WITHOUT the talking head and store it in memory. Then > >> in each frame we compare the backgroung with the current frame and the > >> head is where we find a significant difference. This is simple to implement > >> and works not-too-badly. It requires a static backgroung, i.e. if a > >> colegue is working behind you in the camera field of view it won't work. > >> > >> Hope this helps, > >> Igor > >> > > Sorry, I think I didn't state the problem clearly in the first > message. > > This is the same approach that we tried. Our problem seems to be that > 1) the indy camera is terrible, the iris is so small we have to light > the person to get it to work. Lighting the subject isn't unusual practice. If the camera isn't good enough for what you want to do you could try connecting a better camera to the composite or S-video input at the rear of the box and select an analog source using the video control panel. > > 2) the Indy seems to "pulse", the values aren't stable and so we get > problems like the dark hair of people fading in and out of the > background. >From the video control panel select IndyCam->SignalControls, and select a different shutter speed. Also turn off AGC Enable (automatic gain control) this should eliminate any pulsing. > > Do you do any cleanup algorithm to look for isolated pixels? > > What machine do you use, Indy or PC? Love to share code. > > thanks, Kim. > > > >-- End of excerpt from Kim Michael Fairchild -- Angus Dorbie, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Wed Sep 20 13:24:27 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA03558; Wed, 20 Sep 1995 13:20:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA03555; Wed, 20 Sep 1995 13:20:02 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00657; Wed, 20 Sep 95 13:20:01 -0700 Received: from vision.arc.nasa.gov by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA14466; Wed, 20 Sep 1995 13:19:53 -0700 Received: from descartes.arc.nasa.gov (descartes.arc.nasa.gov [128.102.121.143]) by vision.arc.nasa.gov (8.6.12/8.6.5) with ESMTP id NAA28134 for ; Wed, 20 Sep 1995 13:15:36 -0700 Received: (carlo@localhost) by descartes.arc.nasa.gov (8.6.12/8.6.5) id NAA28805 for info-performer@sgi.com; Wed, 20 Sep 1995 13:15:37 -0700 Date: Wed, 20 Sep 1995 13:15:37 -0700 From: "Carlo L. Tiana" Message-Id: <199509202015.NAA28805@descartes.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: documentation pointers Status: O Could anyone please point me to any existing documentation/man pages for any of the following calls: pfSelectCtab() (as mentioned in pf Prog Guide, page 258) pfGSetCtabMode() (mentioned as above) Thank you very much, Carlo. From guest Wed Sep 20 13:19:41 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA03548; Wed, 20 Sep 1995 13:15:45 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA03545; Wed, 20 Sep 1995 13:15:44 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00500; Wed, 20 Sep 95 13:15:42 -0700 Received: from mailhost.multigen.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA13507; Wed, 20 Sep 1995 13:15:36 -0700 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 NAA15066 for ; Wed, 20 Sep 1995 13:15:45 -0700 Received: from royalflush.engr.multigen.com (royalflush.engr.multigen.com [204.119.70.54]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id UAA10629 for <@plateau.engr.multigen.com:info-performer@holodeck.asd.sgi.com>; Wed, 20 Sep 1995 20:10:17 GMT Received: by royalflush.engr.multigen.com (950511.SGI.8.6.12.PATCH526/940406.SGI) id NAA26209; Wed, 20 Sep 1995 13:22:06 -0700 From: "Marcus Barnes" Message-Id: <9509201322.ZM26207@royalflush.engr.multigen.com> Date: Wed, 20 Sep 1995 13:22:05 -0700 In-Reply-To: Lynda D Myers "Transparency" (Sep 15, 4:13pm) References: <199509152013.QAA06348@gecko.afit.af.mil> Organization: MultiGen Inc. X-Phones: 1-408-556-2654 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer Subject: Re: Transparency Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 15, 4:13pm, Lynda D Myers wrote: > Subject: Transparency > I am having touble seeing one transparent > object through another when rendering objects > in performer. Using the no_occlude option in > pfTransparency did not solve the problem. > Is there another way to do this? > > Thank you, > Lynda D. Myers > e-mail > ldmyers@afit.af.mil >-- End of excerpt from Lynda D Myers If you are using the OpenFlight loader ... one thing it has never supported is object and face bead transparency. If this is what you're trying, you need to instead use a transparent material (or texture) on the appropriate faces. I am adding support for face transparency today as a matter of fact :) . The next loader update will be available from MultiGen Technical Support by next week. It'll be revision R14_2d for Performer 1.2. Object bead transparency is going to be removed from the OpenFlight specification at some point in the future. -- Regards, Marcus Barnes, Member Technical Staff MultiGen Inc, 550 S. Winchester Blvd. STE 500, San Jose CA 95128 PH: 1-408-556-2654 FX: 1-408-261-4102 EMAIL: marcus@engr.multigen.com From guest Wed Sep 20 14:33:39 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA04133; Wed, 20 Sep 1995 14:26:53 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA04130; Wed, 20 Sep 1995 14:26:52 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03887; Wed, 20 Sep 95 14:26:50 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA00573; Wed, 20 Sep 1995 14:26:47 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA03879; Wed, 20 Sep 95 14:26:42 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA28941; Wed, 20 Sep 1995 14:26:42 -0700 Message-Id: <199509202126.OAA28941@surreal.asd.sgi.com> To: trdecarlo@tasc.com Cc: Lynda D Myers , info-performer@sgi.sgi.com Subject: Re: Transparency In-Reply-To: Your message of "Tue, 19 Sep 95 23:30:20 CDT." <9509200430.AA15575@sun.aitc.rest.tasc.com> Date: Wed, 20 Sep 95 14:26:36 -0700 From: Jim Helman Status: O > I don't think Performer does any pre-sorting of transparent parts, > and to get transparent parts to render correctly, they should > probably be rendered after all opaque parts and sorted to render > back to front. Performer 2.0 does depth sorting of transparent objects. -jim From guest Wed Sep 20 15:03:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA04333; Wed, 20 Sep 1995 14:57:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA04330; Wed, 20 Sep 1995 14:57:36 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05200; Wed, 20 Sep 95 14:57:34 -0700 Received: from cs.sfu.ca by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA09599; Wed, 20 Sep 1995 14:57:31 -0700 From: halliday@cs.sfu.ca Received: from mayne (mayne.cs.sfu.ca) by cs.sfu.ca with SMTP id AA29975 (5.65c/IDA-1.4.4 for <@fornax.cs.sfu.ca:info-performer@sgi.com>); Wed, 20 Sep 1995 14:57:29 -0700 Received: by mayne (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id OAA29115; Wed, 20 Sep 1995 14:57:27 -0700 Message-Id: <199509202157.OAA29115@mayne> Subject: Re: Transparency To: info-performer@sgi.sgi.com Date: Wed, 20 Sep 1995 14:57:23 -0800 (PDT) In-Reply-To: <199509202126.OAA28941@surreal.asd.sgi.com> from "Jim Helman" at Sep 20, 95 02:26:36 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 462 Status: O > > > I don't think Performer does any pre-sorting of transparent parts, > > and to get transparent parts to render correctly, they should > > probably be rendered after all opaque parts and sorted to render > > back to front. > > Performer 2.0 does depth sorting of transparent objects. Can it do it by face, or just by object. For example a taurus must be sorted by face to get proper blending. > > -jim > > > -- Sean Halliday halliday@cs.sfu.ca From guest Wed Sep 20 16:27:24 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA11602; Wed, 20 Sep 1995 16:18:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA11556; Wed, 20 Sep 1995 16:18:19 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09501; Wed, 20 Sep 95 16:18:13 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA01042; Wed, 20 Sep 1995 16:18:11 -0700 Received: from cats.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA16013; Wed, 20 Sep 1995 19:06:37 -0400 Received: by cats.cae.ca (931110.SGI/930416.SGI.AUTO) for @poster.cae.ca:info-performer@sgi.com id AA25236; Wed, 20 Sep 95 19:02:10 -0400 From: "Bernard Leclerc" Message-Id: <9509201902.ZM25234@cats.cae.ca> Date: Wed, 20 Sep 1995 19:02:05 -0400 In-Reply-To: "Carlo L. Tiana" "documentation pointers" (Sep 20, 1:15pm) References: <199509202015.NAA28805@descartes.arc.nasa.gov> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Carlo L. Tiana" , info-performer@sgi.sgi.com Subject: Re: documentation pointers Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Sep 20, 1:15pm, Carlo L. Tiana wrote: > Could anyone please point me to any existing documentation/man pages for > any of the following calls: > > pfSelectCtab() (as mentioned in pf Prog Guide, page 258) > pfGSetCtabMode() (mentioned as above) Carlo, take a look at pfColortable and pfGeoSet respectively... you'll find the man pages you're looking for. -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Wed Sep 20 16:15:11 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA04348; Wed, 20 Sep 1995 16:08:08 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA04274; Wed, 20 Sep 1995 16:08:07 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08901; Wed, 20 Sep 95 16:08:00 -0700 Received: from gsaup.ucla.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id QAA28006; Wed, 20 Sep 1995 16:07:57 -0700 Received: from goff by gsaup.ucla.edu (5.x/SMI-SVR4) id AA21128; Wed, 20 Sep 1995 16:06:56 -0700 Received: by goff (940816.SGI.8.6.9) id QAA05639; Wed, 20 Sep 1995 16:06:04 -0700 From: "Scott A. Friedman" Message-Id: <9509201606.ZM5637@goff> Date: Wed, 20 Sep 1995 16:06:03 -0700 X-Mailer: Z-Mail (3.2.1 6apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Determining the number of rendering pipelines Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O What's the best way to determine the number of rendering pipelines a system has? Thanks, Scott -- Scott A. Friedman UCLA Department of Architecture + Urban Design Staff Researcher v 310.825.6294 friedman@ucla.edu Urban Simulation Team f 310.825.7745 www.gsaup.ucla.edu/people/scott From guest Thu Sep 21 01:32:07 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA15469; Thu, 21 Sep 1995 01:28:02 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA15466; Thu, 21 Sep 1995 01:28:01 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24768; Thu, 21 Sep 95 01:27:56 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA21615; Thu, 21 Sep 1995 01:27:54 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id BAA15919; Thu, 21 Sep 1995 01:27:53 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id JAA15249; Thu, 21 Sep 1995 09:16:16 +0100 From: "Rob Jenkins" Message-Id: <9509210916.ZM15247@barney.reading.sgi.com> Date: Thu, 21 Sep 1995 09:16:16 +0100 In-Reply-To: "Scott A. Friedman" "Determining the number of rendering pipelines" (Sep 20, 4:06pm) References: <9509201606.ZM5637@goff> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Scott A. Friedman" , info-performer@sgi.sgi.com Subject: Re: Determining the number of rendering pipelines Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 20, 4:06pm, Scott A. Friedman wrote: > Subject: Determining the number of rendering pipelines > > What's the best way to determine the number of rendering pipelines > a system has? > > Thanks, > Scott > > > -- > Scott A. Friedman UCLA Department of Architecture + Urban Design > > Staff Researcher v 310.825.6294 friedman@ucla.edu > Urban Simulation Team f 310.825.7745 www.gsaup.ucla.edu/people/scott >-- End of excerpt from Scott A. Friedman >From the command line /usr/gfx/gfxinfo, in GL use getgdesc() and something like GD_MUXPIPES or GD_NSCRNS. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Thu Sep 21 04:51:49 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id EAA15705; Thu, 21 Sep 1995 04:50:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id EAA15702; Thu, 21 Sep 1995 04:50:05 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27894; Thu, 21 Sep 95 04:50:04 -0700 Received: from chx400.switch.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id EAA06606; Thu, 21 Sep 1995 04:49:59 -0700 From: ipandzic@cui.unige.ch X400-Received: by mta chx400.switch.ch in /PRMD=Switch/ADMD=Arcom/C=Ch/; Relayed; Thu, 21 Sep 1995 13:49:10 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Thu, 21 Sep 1995 13:49:05 +0200 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Thu, 21 Sep 1995 13:49:01 +0200 Date: Thu, 21 Sep 1995 13:49:01 +0200 X400-Originator: ipandzic@cui.unige.ch X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;950921134901] X400-Content-Type: P2-1984 (2) Content-Identifier: 1050 Alternate-Recipient: Allowed Message-Id: <1050*/S=ipandzic/OU=cui/O=unige/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: info-performer@sgi.sgi.com Subject: Blocking application Status: O Hello, I have a strange problem with my application. I have a quite complex scene, around 800000 triangles. However, most of the complexity is concentrated in rather small objects. I use LOD to switch the objects off when they are not needed (I can't get simplified models for real LOD management). The problem is the following: when I start walking around the program blocks for several seconds when a complex object gets into the viewing frustum or when it is switched on by LOD. This happens only on the first encounter with each object, so once i have walked through the whole environment the things go smoothly. Still, this is quite annoying. I run an an Onyx RE2. The behaviour is the same with or without textures. Does anyone have an idea what I might be doing wrong? Thanks, Igor +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Igor Pandzic ipandzic@cui.unige.ch MIRALab University of Geneva tel. +41/22/705 76 56 24, rue General-Dufour 705 77 63 CH-1211 GENEVE 4 SWITZERLAND fax +41/22/705 77 80 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From guest Thu Sep 21 06:13:38 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA15852; Thu, 21 Sep 1995 06:11:11 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA15849; Thu, 21 Sep 1995 06:11:10 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29278; Thu, 21 Sep 95 06:11:09 -0700 Received: from vr1.engin.umich.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA12748; Thu, 21 Sep 1995 06:11:07 -0700 Received: by vr1.engin.umich.edu (940816.SGI.8.6.9/930416.SGI.AUTO) id JAA05920; Thu, 21 Sep 1995 09:13:11 -0400 From: "Keith Fry" Message-Id: <9509210913.ZM5918@vr1.engin.umich.edu> Date: Thu, 21 Sep 1995 09:13:03 -0400 In-Reply-To: ipandzic@cui.unige.ch "Blocking application" (Sep 21, 1:49pm) References: <1050*/S=ipandzic/OU=cui/O=unige/PRMD=switch/ADMD=arcom/C=ch/@MHS> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com, ipandzic@cui.unige.ch Subject: Re: Blocking application Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 21, 1:49pm, ipandzic@cui.unige.ch wrote: > Subject: Blocking application > Hello, > The problem is the following: when I start walking around the program blocks for > several seconds when a complex object gets into the viewing frustum or > when it is switched on by LOD. This happens only on the first encounter > with each object..... Sounds like Performer is trying to build up a display list for the object when it comes into the scene. If this is a large object, it will take a few seconds. Once the display list is created for the object, however, it doesn't need to be created again (unless geometry or display attributes change, of course). To resolve this problem it seems like you would want to build the display list for each object before beginning the simulation. However, I'm not exactly sure if you can do this or how to do it. A good place to start looking would be the man pages for pfDispList. -- -------------------------------------------------------------------- Keith Fry http://www.engin.umich.edu/~keithfry University of Michigan email: keithfry@engin.umich.edu Virtual Reality Lab work phone: (313) 763-7798 From guest Thu Sep 21 08:15:38 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA16162; Thu, 21 Sep 1995 08:11:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA16159; Thu, 21 Sep 1995 08:11:13 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02175; Thu, 21 Sep 95 08:11:01 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA27396; Thu, 21 Sep 1995 08:10:55 -0700 Received: from vklm.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA26838; Thu, 21 Sep 1995 10:55:18 -0400 Received: by vklm.cae.ca (931110.SGI/930416.SGI.AUTO) for @poster.cae.ca:info-performer@sgi.com id AA02190; Thu, 21 Sep 95 10:49:39 -0400 From: "Jean-Luc Dery" Message-Id: <9509211049.ZM2188@vklm.cae.ca> Date: Thu, 21 Sep 1995 10:49:32 -0400 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: reading frame buffer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I'm working on a project that involves image processing in realtime. The machine used is a Onyx with 2 RE2s. My problem comes from the fact that I need to read and write the frame buffer content for processing because the RE2's don't offer the features needed for the type of processing I want. I'm using the lrectread and lrectwrite functions to get data of a 640x480 channel. I've timed these functions as follows: lrectread normal buffer, 32 bits : 12-18 msec lrectread z buffer, 32 bits : 42-75 msec lrectwrite normal buffer, 32 bits : 10-15 msec These values are way to high; would anyone know tricks or hints, software or hardware (ex. more POWERchannel-2-Board), to reduce these values, and to what extend these values might be reduced. Thanks in advance for any information. -- ___________________________________________________________________ ____ ___ __ Jean-Luc Dery / \ /_ /__) \__/ System engineer __/___/ /___ / \ / CAE Electronics Ltd. GRAPHICS SOFTWARE TECHNOLOGY Phone: (514)341-6780 x2275 e-mail: dery@cae.ca FAX: (514)340-5496 ___________________________________________________________________ From guest Thu Sep 21 05:55:20 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA15827; Thu, 21 Sep 1995 05:53:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA15824; Thu, 21 Sep 1995 05:53:35 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28958; Thu, 21 Sep 95 05:53:34 -0700 Received: from gatekeeper.bvr.co.il by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA11219; Thu, 21 Sep 1995 05:53:29 -0700 Received: (from uucp@localhost) by gatekeeper.bvr.co.il (8.6.12/8.6.9) id MAA18434 for <@gatekeeper.bvr.co.il:info-performer@sgi.com>; Thu, 21 Sep 1995 12:54:40 GMT Received: from unknown(192.114.85.105) by gatekeeper.bvr.co.il via smap (V1.3) id sma018432; Thu Sep 21 14:54:13 1995 Received: by genie.bvr.co.il (940816.SGI.8.6.9/931108.SGI.AUTO.ANONFTP) for info-performer@sgi.com id OAA01017; Thu, 21 Sep 1995 14:53:09 +0200 From: "Ran Yakir" Message-Id: <9509211453.ZM1015@genie.bvr.co.il> Date: Thu, 21 Sep 1995 14:53:09 +0000 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Synchronized node data Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, It seems that there is no (clean, API'd) way to access the frame synchronized ChanData from within a node draw callback. This data is passed to the main draw callback, but is not passed on to the callbacks of the nodes themselves, unless global variables are used ? Is there a solution to that problem ? Thanks Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | From guest Thu Sep 21 08:46:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA16208; Thu, 21 Sep 1995 08:43:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA16205; Thu, 21 Sep 1995 08:43:47 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03065; Thu, 21 Sep 95 08:43:44 -0700 Received: from noc.belwue.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA02280; Thu, 21 Sep 1995 08:43:19 -0700 Received: from awstar.rus.uni-stuttgart.de (awstar-fd.rus.uni-stuttgart.de [129.69.18.51]) by noc.belwue.de with SMTP id RAA26473 (8.6.12/IDA-1.6 for ); Thu, 21 Sep 1995 17:42:48 +0200 Received: by awstar.rus.uni-stuttgart.de (950215.SGI.8.6.10/BelWue-1.0SG(subsidiary)) (for info-performer@sgi.com) id RAA18207; Thu, 21 Sep 1995 17:42:47 +0200 From: "Andreas Wierse" Message-Id: <9509211742.ZM18205@awstar.rus.uni-stuttgart.de> Date: Thu, 21 Sep 1995 17:42:47 +0000 Organization: Visualization Group Comp.Center (RUS) U of Stuttgart, FRG Reply-To: wierse@RUS.Uni-Stuttgart.DE X-Mailer: Z-Mail (3.2.1 6apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: What does Performer do with his memories? :-) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, yesterday we compared the memory usage of our Inventor-based renderer with a (very simple) Performer-based renderer. The Inventor-based renderer received its data out of shared memory and created its inventor nodes from it. The data is geometry data (209 parts per data set; five data sets) with colour information. To monitor the memory usage we used gmemusage (really nice tool :-) When the renderer started its work the memory part labeled "Break" grew from a few MB to 88 MB (I guess this is malloced memory?). The shared memory added about 50 MB. When we switched on the lighting, the "Break"-part grew to ~ 194 MB!! I guess there is some space needed to compute the normals. Cacheing is also switched on. Then we saved our five data sets (timesteps) into Inventor files, approx. 8 MB each and wrote a small Performer program (crash) that uses LoadFile to load the data. First, the total size of each of the two process that Performer starts was reported with approx. 250 MB. No surprise so far :-), since the resident part stayed small; we checked that Performer created a shared arena of ~ 250 MB. After loading the data sets we had about 56 MB really used (resident), 21 of which were listed under "Break", 31 under RW. Here the exact numbers of the gmemusage output (shortened to the "interesting" ones): ---------------------------------------------------------------------- All Programs: Name Size Res Phys Priv Copies Free 109200 109200 109200 109200 1 crash.OPT 529300 56606 55394 54776 2 Irix 81684 81684 81684 81684 1 Totals: 1082292 274782 262140 259203 ---------------------------------------------------------------------- crash.OPT: Name Type Size Res Phys Priv crash.OPT Break 21868 21852 21852 21852 zero RW 484472 31532 31528 31524 Totals: 529686 56670 55394 54776 The interesting point now is that the FS-Cache listed by gmemusage grew rather large (67 MB) and shrunk to 36 MB exactly in the moment we cancelled the Performer-based renderer: ---------------------------------------------------------------------- Irix: before crash runs Name Type Size Res Phys Priv FS Cache Irix 0 0 29183 29183 Heap Irix 0 0 7761 7761 Totals: 0 0 42966 42966 ---------------------------------------------------------------------- Irix: while crash runs Name Type Size Res Phys Priv FS Cache Irix 0 0 67598 67598 Heap Irix 0 0 7841 7841 Totals: 0 0 81685 81685 ---------------------------------------------------------------------- Irix: after crash has finished Name Type Size Res Phys Priv FS Cache Irix 0 0 36613 36613 Heap Irix 0 0 7843 7843 Totals: 0 0 50392 50392 Ok, if we count the two numbers (56 and 31 MB) together we are still far below what Inventor needs, but it would be nice to know why the FS-Cache grows that much. Maybe there are some surprises hidden which will strike us, when we try to load really large data sets. So please let us know if you have any explanations or comments concerning the memory usage of both, the Inventor-based and the Performer-based renderer. Thanks in Advance Andreas -- Andreas Wierse | Computer Center University of Stuttgart wierse@rus.uni-stuttgart.de | Allmandring 30, D-70550 Stuttgart, Germany +49 711-6855796 (FAX:-682357) | '90 VFR750F (red, of course!) rrr#9 DoD#SUE6 http://www.uni-stuttgart.de/People/wierse.html From guest Thu Sep 21 11:57:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA16747; Thu, 21 Sep 1995 11:51:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA16744; Thu, 21 Sep 1995 11:51:30 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12132; Thu, 21 Sep 95 11:51:10 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA02652; Thu, 21 Sep 1995 11:51:11 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id LAA11337; Thu, 21 Sep 1995 11:38:45 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA11358; Thu, 21 Sep 95 11:37:17 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA23171; Thu, 21 Sep 1995 11:37:12 -0700 Message-Id: <199509211837.LAA23171@surreal.asd.sgi.com> To: halliday@cs.sfu.ca Cc: info-performer@sgi.sgi.com Subject: Re: Transparency In-Reply-To: Your message of "Wed, 20 Sep 95 14:57:23 -0800." <199509202157.OAA29115@mayne> Date: Thu, 21 Sep 95 11:37:04 -0700 From: Jim Helman Status: O It does the sorting by pfGeoSet. Sorting by face would be very expensive. If you *really* need sorting by face, you'll need to create 1 geoset per face. -jim From guest Thu Sep 21 11:56:41 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA16742; Thu, 21 Sep 1995 11:51:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA16739; Thu, 21 Sep 1995 11:51:16 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12134; Thu, 21 Sep 95 11:51:12 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA02650; Thu, 21 Sep 1995 11:51:10 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id LAA11597; Thu, 21 Sep 1995 11:41:11 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA11411; Thu, 21 Sep 95 11:39:47 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA23180; Thu, 21 Sep 1995 11:39:47 -0700 Message-Id: <199509211839.LAA23180@surreal.asd.sgi.com> To: "Ran Yakir" Cc: info-performer@sgi.sgi.com Subject: Re: Synchronized node data In-Reply-To: Your message of "Thu, 21 Sep 95 14:53:09 -0000." <9509211453.ZM1015@genie.bvr.co.il> Date: Thu, 21 Sep 95 11:39:46 -0700 From: Jim Helman Status: O > ChanData from within a node draw callback. pfGetChanData(pfGetTravChan(trav)). -jim From guest Thu Sep 21 11:50:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA16726; Thu, 21 Sep 1995 11:45:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA16723; Thu, 21 Sep 1995 11:45:19 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11676; Thu, 21 Sep 95 11:45:17 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA00345; Thu, 21 Sep 1995 11:45:12 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA11637; Thu, 21 Sep 95 11:45:05 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA23189; Thu, 21 Sep 1995 11:45:04 -0700 Message-Id: <199509211845.LAA23189@surreal.asd.sgi.com> To: "Keith Fry" Cc: info-performer@sgi.sgi.com, ipandzic@cui.unige.ch Subject: Re: Blocking application In-Reply-To: Your message of "Thu, 21 Sep 95 09:13:03 EDT." <9509210913.ZM5918@vr1.engin.umich.edu> Date: Thu, 21 Sep 95 11:45:04 -0700 From: Jim Helman Status: O Since Performer's immediate mode rendering is fast enough to keep an RE2 fully occupied, we *do not* build up any GL display lists by default. This saves both time and memory. If you want GL display lists for some reason, you can set the pfGSetDrawMode accordingly. The Performer pfDispList that communicates between the cull and draw doesn't contain any actual geometry (only pointers to pfGeoSets) and is built every frame anyway. If the system is pausing when an object comes into view, my first guess would be that the object is textured and the texture needed to be paged down to the graphics pipe. If your entire texture database will fit in the pipe, you should pre-download all of your textures. See pfuDownLoadTexList in libpfutil/download.c rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Sep 21 12:31:19 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA16982; Thu, 21 Sep 1995 12:22:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA16979; Thu, 21 Sep 1995 12:22:16 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13508; Thu, 21 Sep 95 12:22:04 -0700 Received: from cs.sfu.ca by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA13310; Thu, 21 Sep 1995 12:21:51 -0700 From: halliday@cs.sfu.ca Received: from mayne (mayne.cs.sfu.ca) by cs.sfu.ca with SMTP id AA10461 (5.65c/IDA-1.4.4 for <@fornax.cs.sfu.ca:info-performer@sgi.com>); Thu, 21 Sep 1995 12:21:44 -0700 Received: by mayne (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id MAA03257; Thu, 21 Sep 1995 12:21:43 -0700 Message-Id: <199509211921.MAA03257@mayne> Subject: Virtual I/O Head Tracker To: info-performer@sgi.sgi.com Date: Thu, 21 Sep 1995 12:21:37 -0800 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 399 Status: O Hi, I have written a head tracker driver library for the Virtual I/O Glasses. I found that the tracker is very noisy. I do an sproc so that I can collect data faster than I am using it. This allows me to average a few samples before they are used. I have written a filter but I still get a lot of jitter. Has anyone else written a decent filter for it? -- Sean Halliday halliday@cs.sfu.ca From guest Thu Sep 21 14:36:39 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA17962; Thu, 21 Sep 1995 14:34:24 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA17959; Thu, 21 Sep 1995 14:34:23 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20345; Thu, 21 Sep 95 14:34:21 -0700 Received: from lgc.lgc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA15573; Thu, 21 Sep 1995 14:34:20 -0700 Received: from oasis.zycor.lgc.com by lgc.lgc.com (5.65b/lgc.%I%) id AA03617; Thu, 21 Sep 95 16:34:22 -0500 Received: from godzilla.zycor.lgc.com by oasis.zycor.lgc.com (4.1/lgc.1.20) id AA28542; Thu, 21 Sep 95 16:34:03 CDT Received: by godzilla.zycor.lgc.com (940816.SGI.8.6.9/lgc.1.9) id QAA04578; Thu, 21 Sep 1995 16:34:03 -0500 From: "Randy Clarke" Message-Id: <9509211634.ZM4576@godzilla.zycor.lgc.com> Date: Thu, 21 Sep 1995 16:34:03 -0500 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: load .rgb file as opengl texture map? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi... Subject line pretty well sums it up...any have a simple code snippet which demonstrates how to load a .rgb file into an opengl texture map? Thanks, Randy -- ----------------------------------------------------------------------- - randy_clarke@zycor.lgc.com ------------------ Research Group, Zycor - ------- (512) 292-2331 -------------------------- Software Engineer --- "Life is what happens to you while you are making other plans." ----------------------------------------------------------------------- From guest Thu Sep 21 19:37:29 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA22300; Thu, 21 Sep 1995 19:32:14 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA22297; Thu, 21 Sep 1995 19:32:12 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03241; Thu, 21 Sep 95 19:32:09 -0700 Received: from ix5.ix.netcom.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA20953; Thu, 21 Sep 1995 19:32:05 -0700 Received: from BLASTARR by ix5.ix.netcom.com (8.6.12/SMI-4.1/Netcom) id TAA16812; Thu, 21 Sep 1995 19:31:27 -0700 Date: Thu, 21 Sep 1995 19:31:27 -0700 Message-Id: <199509220231.TAA16812@ix5.ix.netcom.com> X-Sender: blastarr@smtp.ix.netcom.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: halliday@cs.sfu.ca From: Kent Miller Subject: Re: Virtual I/O Head Tracker Cc: info-performer@sgi.sgi.com Status: O > I have written a head tracker driver library for the Virtual >I/O Glasses. I found that the tracker is very noisy. I do an sproc so >that I can collect data faster than I am using it. This allows me >to average a few samples before they are used. I have written >a filter but I still get a lot of jitter. Has anyone else written >a decent filter for it? > I wrote a damper for our Polhemus FASTRAK. It's ok, but you always have the smooth vs. fast response problem. The more you damp, the more you feel like your head's stuck in molasses. Try playing around with the number of samples you average, and the cone angle of the dead spot. For the Polhemus, the best mix is about 20 samples with a 3-degree cone. This year's SIGGRAPH papers included one on predicting head motion - I suppose you could spend a couple of months turning that into code (and post it here!). That way you can have it both ways. From guest Thu Sep 21 21:30:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA22503; Thu, 21 Sep 1995 21:27:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA22500; Thu, 21 Sep 1995 21:27:26 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05627; Thu, 21 Sep 95 21:27:25 -0700 Received: from sgimco.orlando.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id VAA04906; Thu, 21 Sep 1995 21:27:19 -0700 Received: from dolphin.orlando.sgi.com by sgimco.orlando.sgi.com via ESMTP (940816.SGI.8.6.9/930416.SGI) id AAA03892; Fri, 22 Sep 1995 00:27:09 -0400 Received: by dolphin.orlando.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id AAA03616; Fri, 22 Sep 1995 00:26:40 -0400 From: "Dennis Pierce" Message-Id: <9509220026.ZM3614@dolphin.orlando.sgi.com> Date: Fri, 22 Sep 1995 00:26:36 -0400 In-Reply-To: Kent Miller "Re: Virtual I/O Head Tracker" (Sep 21, 19:31) References: <199509220231.TAA16812@ix5.ix.netcom.com> X-Face: "|M:`f=J:QLq!1azA~nCk/kos:QFGU9IAgqX2Zvx+?v`>6m.$kYt2")&qFIFe_-w[u7jBDO g{5v\\%T!G'/D_ir]::4i3gz6,U{};]S}[b`KcD.h))=pRfmd!m}7jU"d8t^+UFuLF9RlT=:D49=l! hp7$F+HjjW'}f![(Q_+'},i{x;C+E>0~, halliday@cs.sfu.ca Subject: Re: Virtual I/O Head Tracker Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O prediction is the best approach, and it should not be too difficult to develop a basic predictor - of course, if I'm doing a SIGGRAPH paper, I want to research many alternatives, but for simple got-to-get- it-done engineering, integrate the positions to get velocities and the velocities to get accelerations, then let the accelerations drive your visuals - averaging is ok but some basic integration filter would be better - try ashein@boston.sgi.com for some algorithms as he has done this a bit for autonomous vehicle control - don't forget to discard truly out-of-band readings (spikes) as they will trash whatever filter/predictor you devise good luck! PS, I'm sure mtj@asd.sgi.com (Michael T. Jones) has a few references on the subject too, so ping him directly and check -- -- Dennis Pierce SGI / Ste 130 / 900 Winderley PL / Maitland FL 32751 work : 407.660.0073 late : 407.660.2789 cell : 407.256.8447 vmail: 800.326.1020 x58548 From guest Fri Sep 22 04:25:32 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id EAA22912; Fri, 22 Sep 1995 04:21:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id EAA22909; Fri, 22 Sep 1995 04:21:25 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13670; Fri, 22 Sep 95 04:21:21 -0700 Received: from internet-mail.ford.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id EAA07044; Fri, 22 Sep 1995 04:21:17 -0700 Received: by internet-mail.ford.com id AA23241 (InterLock SMTP Gateway 3.0 for info-performer@sgi.com); Fri, 22 Sep 1995 07:21:16 -0400 Message-Id: <199509221121.AA23241@internet-mail.ford.com> Received: by internet-mail.ford.com (Protected-side Proxy Mail Agent-1); Fri, 22 Sep 1995 07:21:16 -0400 From: "Russ Navarre" Date: Fri, 22 Sep 1995 07:26:34 -0400 In-Reply-To: Kent Miller "Re: Virtual I/O Head Tracker" (Sep 21, 7:31pm) References: <199509220231.TAA16812@ix5.ix.netcom.com> X-Mailer: Z-Mail (3.2.1 15feb95) To: halliday@cs.sfu.ca Subject: Re: Virtual I/O Head Tracker Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Mechanical tracking is much more accurate. You guys should check out Fakespace. Their 3C boom is very expensive but the new 'Pivot' boom which was introduced at SIGGRAPH this year is less expensive. Getting away from a head-coupled device is nice too. On Sep 21, 7:31pm, Kent Miller wrote: > Subject: Re: Virtual I/O Head Tracker > > I have written a head tracker driver library for the Virtual > >I/O Glasses. I found that the tracker is very noisy. I do an sproc so > >that I can collect data faster than I am using it. This allows me > >to average a few samples before they are used. I have written > >a filter but I still get a lot of jitter. Has anyone else written > >a decent filter for it? > > > I wrote a damper for our Polhemus FASTRAK. It's ok, but you always have the > smooth vs. fast response problem. The more you damp, the more you feel like > your head's stuck in molasses. Try playing around with the number of samples > you average, and the cone angle of the dead spot. For the Polhemus, the best > mix is about 20 samples with a 3-degree cone. > > This year's SIGGRAPH papers included one on predicting head motion - I > suppose you could spend a couple of months turning that into code (and post > it here!). That way you can have it both ways. > > >-- End of excerpt from Kent Miller -- ------------------------------------------------------------------------------ Russ Navarre Phone: (313) 322-9588 Adv. Graphics Software Developer Fax: (313) 594-1193 Ford Motor Company Email: rnavarre@ford.com Room 1122, Building#5 20000 Rotunda Drive Dearborn, MI 48121 ------------------------------------------------------------------------------ From guest Fri Sep 22 05:12:31 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA23023; Fri, 22 Sep 1995 05:10:45 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA23020; Fri, 22 Sep 1995 05:10:45 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14391; Fri, 22 Sep 95 05:10:43 -0700 Received: from beyond.clubfed.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id FAA09876; Fri, 22 Sep 1995 05:10:41 -0700 Received: from hotsauce.clubfed.sgi.com by beyond.clubfed.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id IAA08789; Fri, 22 Sep 1995 08:14:42 -0400 Received: by hotsauce.clubfed.sgi.com (940816.SGI.8.6.9/930416.SGI.AUTO) id IAA08472; Fri, 22 Sep 1995 08:10:34 -0400 From: "Brian Furtaw" Message-Id: <9509220810.ZM8470@hotsauce.clubfed.sgi.com> Date: Fri, 22 Sep 1995 08:10:30 -0400 In-Reply-To: "Randy Clarke" "load .rgb file as opengl texture map?" (Sep 21, 4:34pm) References: <9509211634.ZM4576@godzilla.zycor.lgc.com> X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: "Randy Clarke" Subject: Re: load .rgb file as opengl texture map? Cc: brian@hotsauce.clubfed.sgi.com, info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O This uses ImageVision Library but try this out, if you don't have IL use libgutil's unsigned long *longimagedata(char * filename, char *mode) must link to libimage also. Here's some code... #include #include #include unsigned char * createTex( char *imgfile, GLsizei *width, GLsizei *height, GLsizei *depth) { unsigned char *buffer; ilFileImg* img = ilOpenImgFile(imgfile, "r"); if (img == NULL) { printf ("Couldn't open image file: %s\n", imgfile); exit(0); } ilSize size; img->getSize(size); *width = size.x; *height = size.y; *depth = size.c; buffer = (unsigned char *) malloc( size.x * size.y * size.c * sizeof(unsigned char)); img->getTile(0, 0, size.x, size.y, buffer); return buffer; } GLvoid initTex( char *tfile ) { unsigned char *textureMap; GLsizei width, height, depth; textureMap = createTex( tfile, &width, &height, &depth ); // assumes textureMap is already a power of two glPixelStorei(GL_UNPACK_ALIGNMENT, 1); glTexImage2D( GL_TEXTURE_2D, 0, depth, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, textureMap); // generate the MipMaps gluBuild2DMipmaps( GL_TEXTURE_2D, depth, width, height, GL_RGB, GL_UNSIGNED_BYTE, textureMap); // set up mapping parameters glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST_MIPMAP_NEAREST); glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE); } GLvoid drawScene( GLvoid ) { From guest Fri Sep 22 06:28:31 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA23167; Fri, 22 Sep 1995 06:24:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA23164; Fri, 22 Sep 1995 06:24:45 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15581; Fri, 22 Sep 95 06:24:41 -0700 Received: from dw3si.ess.harris.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA16179; Fri, 22 Sep 1995 06:24:34 -0700 From: bmcquear@dw3f.ess.harris.com Received: by dw3si.ess.harris.com (5.57/Ultrix3.0-C) id AA00335; Fri, 22 Sep 95 09:23:52 -0400 Message-Id: <9509221323.AA00335@dw3si.ess.harris.com> To: info-performer@sgi.sgi.com Subject: Performer 2.0/Impact Date: Fri, 22 Sep 95 09:23:51 -0400 X-Mts: smtp Status: O I recently heard a rumor that the Impact will only run Performer 2.0 and not 1.2. ?? Is this a true statement, and if so, why ?? Thanks, Bruce McQueary From guest Fri Sep 22 10:38:35 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA23552; Fri, 22 Sep 1995 10:34:58 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA23549; Fri, 22 Sep 1995 10:34:52 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23271; Fri, 22 Sep 95 10:34:49 -0700 Received: from atc.boeing.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA29792; Fri, 22 Sep 1995 10:34:48 -0700 Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA08997; Fri, 22 Sep 1995 10:37:39 -0700 Received: from aw545.iasl.ca.boeing.com.iasl.ca.boeing.com (aw545.iasl.ca.boeing.com) by aw101.iasl.ca.boeing.com with SMTP id AA27251 (5.67a/IDA-1.4.4 for ); Fri, 22 Sep 1995 10:34:47 -0700 From: "David H. Whittington" Received: by aw545.iasl.ca.boeing.com.info-performer@sgi.sgi.com (5.65c/client-1.3) id AA01712; Fri, 22 Sep 1995 10:34:45 -0700 Message-Id: <199509221734.AA01712@aw545.iasl.ca.boeing.com.info-performer@sgi.sgi.com> Subject: Object priority To: info-performer@sgi.sgi.com Date: Fri, 22 Sep 1995 10:34:44 -0700 (PDT) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1222 Status: O to: Performer gurus Please help I am reading in a terrain object patch (30nm by 30nm -40k polys with 3LOD's) and want to read in separately a generic airport model (runway,taxiways,grass patch, and buildings) and allow the user to use a GUI to translate and rotate the airport into several positions "on" the terrain. The only problem is that I want the airport to maintain "normal" viewability, i.e. it should not "flash" with the terrain object due to z-buffer fighting when viewing from several thousand feet above nor should I be able to see the airport when in a valley of the terrain. How can I handle this object priority problem without just adding the object to the terrain patch database as a "subobject". Thanks for the help!! .=========================================================================. / David H. Whittington | Voice: (206) 662-4923 (work) \ | Boeing Commercial Airplane | (206) 662-3425 (lab) | | P.O. Box 3707, M/S 19-MH | Internet: dhw3314@aw101.iasl.ca.boeing.com | \ Seattle, WA 98124-2207 | #include "/boeing/sw/std_disclaimer.h" / `=========================================================================' From guest Fri Sep 22 10:43:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA23571; Fri, 22 Sep 1995 10:39:40 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA23568; Fri, 22 Sep 1995 10:39:39 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23553; Fri, 22 Sep 95 10:39:37 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA01528; Fri, 22 Sep 1995 10:39:37 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA23537; Fri, 22 Sep 95 10:39:33 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA03929; Fri, 22 Sep 1995 10:37:01 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199509221737.KAA03929@tubes.asd.sgi.com> Subject: Re: Help on converting image data to performer pfTexture type To: guest (Anita Kishore) Date: Fri, 22 Sep 95 10:37:01 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9509191453.ZM1341@tracey.electrogig.com>; from "Anita Kishore" at Sep 19, 95 2:53 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > -- > --PART-BOUNDARY=.19509191453.ZM1341.electrogig.com > Content-Type: text/plain; charset=us-ascii > > Can someone help me with the following: > > I generate an image that looks like a checkerboard ( as given in the > open GL book, page 261) and use that image in pfTexImage API hoping to be > able to map this new texture on to my geometry which is a square facing the > user. But instead of a check image I get a solid purple square. If I change the > number of components/pixel in the API, then I don't get anything. What am I > doing wrong? I am enclosing a small smaple program to demo this. > > int i, j, r, c; > unsigned long img[64][64][3]; > > tex = pfNewTex(arena); > > xsize = ysize = 64; > > /* make check image : from openGL book */ > for ( i = 0; i < ysize; i++ ) > for ( j = 0; j < xsize; j++ ) > { > c = ((((i&0x8)==0)^((j&0x8))==0)) * 255; > img[i][j][0] = (unsigned long) c; > img[i][j][1] = (unsigned long) c; > img[i][j][2] = (unsigned long) c; > } > > pfTexImage(tex, img, 2, xsize, ysize, 1); pfTexImage expects a packed image. In the above example your image is of type 'long' but it should be of type 'char' and the number of components you specify to pfTexImage should be 3, not 2. I speak for IrisGL only - I don't know exactly how pfTexImage behaves in OpenGL. From guest Fri Sep 22 10:51:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA23592; Fri, 22 Sep 1995 10:47:30 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA23589; Fri, 22 Sep 1995 10:47:30 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23876; Fri, 22 Sep 95 10:47:28 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA03024; Fri, 22 Sep 1995 10:47:25 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA23872; Fri, 22 Sep 95 10:47:24 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA03940; Fri, 22 Sep 1995 10:44:51 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199509221744.KAA03940@tubes.asd.sgi.com> Subject: Re: Positional Accuracy To: guest (Paul Levy) Date: Fri, 22 Sep 95 10:44:51 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <199509192147.RAA06035@banshee.camberva.com>; from "Paul Levy" at Sep 19, 95 5:47 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > We are flying around a relatively large database that was created from > DTED data. The database has been translated to its correct lat lon position. > The problem we have is the X,Y,Z numbers are so large, the image seems > to jitter eventhough the eyepoint is stationary. I would appreciate any > existing solutions or workarounds. > A solution is to chop up the database into tiles whose extent is adequately represented by a float. Recompute the coordinates of each tile based on an origin at the tile center and parent each tile with a pfDCS. Determine which tile the viewer is in and compute view position relative to the origin of the tile. Set the viewer's tile DCS to the identity matrix and translate all other tiles relative to the viewer's tile. This should give you good precision and performance but will complicate computations which cross tile boundaries, e.g. - intersections. From guest Fri Sep 22 11:09:53 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA23771; Fri, 22 Sep 1995 11:06:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA23768; Fri, 22 Sep 1995 11:06:16 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24974; Fri, 22 Sep 95 11:06:15 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA07900; Fri, 22 Sep 1995 11:06:11 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id KAA18101; Fri, 22 Sep 1995 10:54:16 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA24101; Fri, 22 Sep 95 10:54:06 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA03986; Fri, 22 Sep 1995 10:51:34 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199509221751.KAA03986@tubes.asd.sgi.com> Subject: Re: Performance problems for root To: guest (Dr. Aris Christidis) Date: Fri, 22 Sep 95 10:51:34 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <63A32FD2054@aitec.de>; from "Dr. Aris Christidis" at Sep 19, 95 5:42 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > Hello! > > We have a remarkable problem with a multiprocess-Performer > application running with root privileges (setuid or started > by root) on a 12 CPU, 3 pipes Onyx under Performer 1.2 and > IRIX 5.3: > > When started in privileged mode, the obtained performance > is much lower than when being run by a non-privileged user > (intermittent frame delay, 10-30 msec). > > Any suggestions? > > Best regards, > Aris ChristidisAITEC GmbH & CO Informationstechnologie KG > Dr. Aris Christidis > Alter Hellweg 50 > D-44379 Dortmund > Tel.: +49 231 9646545 > Fax.: +49 231 9646598 > EMail: ac@aitec.de This kind of thing may be a result of starvation and/or deadlock. Are you? 1. isolating processors, 2. assigning more than one process to a CPU, 3. using non-degrading priorities From guest Fri Sep 22 12:40:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA24498; Fri, 22 Sep 1995 12:35:45 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA24495; Fri, 22 Sep 1995 12:35:45 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29311; Fri, 22 Sep 95 12:35:44 -0700 Received: from satchmo.virtualprototypes.ca by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA28116; Fri, 22 Sep 1995 12:35:33 -0700 Received: from rem.virtualprototypes.ca by satchmo.virtualprototypes.ca via SMTP (931110.SGI/911001.satchmo.VirtualPrototypes.CA) for info-performer@sgi.com id AA03128; Fri, 22 Sep 95 15:35:36 -0400 Received: by rem.virtualprototypes.ca (931110.SGI/930416.SGI.AUTO) for @satchmo.virtualprototypes.ca:info-performer@sgi.com id AA07667; Fri, 22 Sep 95 15:35:34 -0400 From: naud@rem.virtualprototypes.ca (Jean-Marc Naud) Message-Id: <9509221935.AA07667@rem.virtualprototypes.ca> Subject: GL code in VEGA To: info-performer@sgi.sgi.com Date: Fri, 22 Sep 95 15:35:31 EDT X-Mailer: ELM [version 2.3 PL11] Status: O Help! This might not be the proper mailing list for this question but here it is anyway: We are using Vega from Paradigm (which sits on top of Performer). We put some GL drawing code in a channel postdraw callback. But our drawing is always done on the root window while VEGA opens its own window. Obviously we would like our drawing to be in the VEGA opened window NOT on the root window. And there does not seem to be a way to ask VEGA for the windowid of the window it opens. Anyone with help out there? Thanks. --------------------------------------------------------------------------- Jean-Marc Naud Phone: (514) 341-3VPI Virtual Prototypes Inc. FAX: (514) 341-6532 4700 de la Savane, Suite 300 Email: naud@VirtualPrototypes.CA Montreal (Quebec) H4P 1T7 From guest Fri Sep 22 15:04:20 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA25307; Fri, 22 Sep 1995 15:00:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA25304; Fri, 22 Sep 1995 15:00:17 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05177; Fri, 22 Sep 95 15:00:15 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA29808; Fri, 22 Sep 1995 15:00:04 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA05148; Fri, 22 Sep 95 14:59:57 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA04853; Fri, 22 Sep 1995 14:57:25 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199509222157.OAA04853@tubes.asd.sgi.com> Subject: Re: pfSequence and the twilight zone To: guest (Darin C. Partridge) Date: Fri, 22 Sep 95 14:57:24 PDT Cc: info-performer@sgi.sgi.com, darin@chaos.idec.sdl.usu.edu In-Reply-To: <9506291634.ZM4642@paradox.idec.sdl.usu.edu>; from "Darin C. Partridge" at Jun 29, 95 4:34 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > I posted a pfSequence problem a week or so ago but didn't get a response. > Now I have more information to help someone help me. > > I have five frames under a pfSequence node of which I loop through four. > (for some reason the last node gets inserted as the first child when > the sequence is built(is this a bug), so I had to copy the first index and > add it to the pfSequence again so I could preserve order. So I loop from 1 > through 4) > > Heres what shows up on the screen. > > Time 1: frame 1 > Time 2: frame 2 > Time 3: frame 3 > Time 4: nothing > Time 5: frame 4 and frame 1 > Time 6: frame 2 > Time 7: frame 3 > Time 8: nothing > Time 9: frame 1 > Time 10: frame 2 and frame 4 > Time 11: frame 3 > Time 12: nothing > Time 13: frame 1 > Time 14: frame 2 > Time 15: frame 3 and frame 4 > Time 16: nothing > Time 17: frame 1 > Time 18: frame 2 > Time 19: frame 3 > Time 20: frame 4 > (now the pattern cycles back to Time 1) > > So the pfSequence looked good from time 17-20. > > I've had my problems with pfSequence but I've used it anyway in a number > of apps. Usually I have to jimmy-rig it to get it to work. > > I've noticed that when people post questions about pfSequence > that there is usually little or no response. I'm wondering if > I'm the only one having problems with pfSequence or is there a bug > (feature) with the pfSequence. > There is a bug in pfFlatten() which rearranges the order of any pfDCSes that are direct children of a pfSequence - specifically all DCS children are placed under an SCS which is added to the end of the sequence child list. If this is not your problem, please send me a test case. From guest Fri Sep 22 17:15:41 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA25898; Fri, 22 Sep 1995 17:07:42 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA25895; Fri, 22 Sep 1995 17:07:42 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10252; Fri, 22 Sep 95 17:07:40 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA26907; Fri, 22 Sep 1995 17:07:37 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id RAA11460; Fri, 22 Sep 1995 17:02:56 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA10031; Fri, 22 Sep 95 17:01:39 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA10658; Fri, 22 Sep 1995 16:59:06 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199509222359.QAA10658@tubes.asd.sgi.com> Subject: Re: pfPassChanData :-( To: guest (Robert Webb) Date: Fri, 22 Sep 95 16:59:06 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: ; from "Robert Webb" at Jul 19, 95 10:23 am X-Mailer: ELM [version 2.3 PL8] Status: O > > Hi Performer-people, > > In my application pfPassChanData() doesn't seem to be doing quite what it > should :-( I have two modes which I can toggle between with the hit of a > key: > > Mode 1: > Channel 1: Calls pfDraw() once. > Channel 2: Turned off. > > Mode 2: > Channel 1: Calls pfDraw() once. > Channel 2: Calls pfDraw() twice. > > When I hit the key, the chan-data for channel 1 changes and I call > pfPassChanData() to make sure it gets sent down the pipeline to the DRAW > process. However I am printing out the value of the data passed to my draw > call-back (from within that call-back) and after a few hits of the key, it > starts changing between the value it should have (for the current mode), and > the value it should have in the other mode. I have a printf at every call > to pfPassChanData(), so I know it is NOT being called unless I hit the key, > but still the data being passed to the draw call-back is oscillating between > two different values. It is as if Performer is still using an older copy of > the chan-data sometimes, rather than the new one I asked to pass down. > This is a bug in 1.2 which may be exacerbated by disabling channel 2. For now, call pfPassChanData each frame until you get 2.0. From guest Fri Sep 22 17:09:12 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA25884; Fri, 22 Sep 1995 17:04:22 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA25881; Fri, 22 Sep 1995 17:04:22 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10096; Fri, 22 Sep 95 17:04:20 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA26009; Fri, 22 Sep 1995 17:04:12 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id RAA11500; Fri, 22 Sep 1995 17:03:24 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA10039; Fri, 22 Sep 95 17:02:08 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA10666; Fri, 22 Sep 1995 16:59:35 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199509222359.QAA10666@tubes.asd.sgi.com> Subject: Re: Channel Data To: guest (William J. Moore) Date: Fri, 22 Sep 95 16:59:35 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9507222213.AA19030@world.nad.northrop.com>; from "William J. Moore" at Jul 22, 95 3:13 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > I've noticed a difference in behavior when passing channel > data in APPCULL_DRAW verses APP_CULL_DRAW multiprocess modes. > It works as expected in APP_CULL_DRAW, but in APPCULL_DRAW > you must force the creation of the channel data buffers with > three calls to pfPassChanData (chan) & pfFrame(). If you don't > the data pointer is null in the draw callback. Is this correct > or am I not setting it up correctly in APPCULL_DRAW mode? > I believe this is a bug that has been fixed in 2.0. From guest Mon Sep 25 01:09:26 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA28551; Mon, 25 Sep 1995 01:06:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA28548; Mon, 25 Sep 1995 01:06:34 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27629; Mon, 25 Sep 95 01:06:33 -0700 Received: from death.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA06020; Mon, 25 Sep 1995 01:06:29 -0700 Received: by death.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id IAA23051; Mon, 25 Sep 1995 08:03:56 GMT From: "Angus Henderson" Message-Id: <9509250803.ZM23049@death.reading.sgi.com> Date: Mon, 25 Sep 1995 08:03:56 +0000 In-Reply-To: halliday@cs.sfu.ca "Re: Transparency" (Sep 20, 2:57pm) References: <199509202157.OAA29115@mayne> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: halliday@cs.sfu.ca, info-performer@sgi.sgi.com Subject: Re: Transparency Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > a taurus must be sorted by face to get proper blending. I'm a Leo - there's more polygons in a leo than a taurus From guest Mon Sep 25 05:52:25 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA29079; Mon, 25 Sep 1995 05:50:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA29076; Mon, 25 Sep 1995 05:50:17 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04424; Mon, 25 Sep 95 05:50:16 -0700 Received: from scn1.nmc.wpafb.af.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA20503; Mon, 25 Sep 1995 05:50:10 -0700 Received: by Wright-Patterson AFB Mailgate Mon Sep 25 08:43:45 1995 Received: from fltsvr1.flight.wpafb.af.mil by fltsvr2.flight.wpafb.af.mil (4.1/SMI-4.1) id AA14529; Mon, 25 Sep 95 08:43:42 EDT Date: Mon, 25 Sep 95 08:43:42 EDT From: buellcg@fltsvr2.flight.wpafb.af.mil (Christopher G. Buell) Message-Id: <9509251243.AA14529@fltsvr2.flight.wpafb.af.mil> To: info-performer@sgi.sgi.com Status: O I have been reading the messages concerning the problems with mixing the SYS V IPC shared memory with the shared arenas that Performer uses. Could using Systran's SCRAMNet memory directly from a Performer application produce the same side-effects or conflicts with the shared arenas? Chris Buell Veda, Inc. buellcg@fltsvr1.flight.wpafb.af.mil From guest Mon Sep 25 08:30:48 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA29446; Mon, 25 Sep 1995 08:28:01 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA29443; Mon, 25 Sep 1995 08:28:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08743; Mon, 25 Sep 95 08:27:58 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA07728; Mon, 25 Sep 1995 08:27:56 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA08712; Mon, 25 Sep 95 08:27:38 -0700 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id IAA18507; Mon, 25 Sep 1995 08:27:26 -0700 From: "Michael Jones" Message-Id: <9509250827.ZM18505@babar.asd.sgi.com> Date: Mon, 25 Sep 1995 08:27:26 -0700 In-Reply-To: bmcquear@dw3f.ess.harris.com "Performer 2.0/Impact" (Sep 22, 9:23am) References: <9509221323.AA00335@dw3si.ess.harris.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: bmcquear@dw3f.ess.harris.com, info-performer@sgi.sgi.com Subject: Re: Performer 2.0/Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 22, 9:23am, bmcquear@dw3f.ess.harris.com wrote: > Subject: Performer 2.0/Impact : :I recently heard a rumor that the Impact will only run :Performer 2.0 and not 1.2. ?? : :Is this a true statement, and if so, why ?? It's not quite true, but it's close. Impact is an OpenGL machine. Performance-sensitive users (and this is probably just about everybody) will want to convert any IRIS GL programs that they use to OpenGL for best performance. The (almost-here) IRIS Performer 2.0 supports both IrisGL and OpenGL, so that users get the best performance on all machines. The previous Performer 1.2 only supports IrisGL. For customers wanting to run IRIS GL programs on Impact, there is an Iris-GL-On-Opengl (IGLOO) tool that is invoked to provide run-time IrisGL support. This is usable with Performer 1.2, so the rumor is not quite true in detail, but in spirit, nearly all Impact customers using Performer will want Performer 2.0 and the native OpenGL support that it provides. -- Be seeing you, Phone:415.390.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Mon Sep 25 01:40:34 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA28731; Mon, 25 Sep 1995 01:36:45 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA28728; Mon, 25 Sep 1995 01:36:44 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28200; Mon, 25 Sep 95 01:36:39 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA08040; Mon, 25 Sep 1995 01:36:37 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/940406.SGI) id KAA13558; Mon, 25 Sep 1995 10:11:12 +0200 From: "Angus Dorbie" Message-Id: <9509251011.ZM13556@bitch.reading.sgi.com> Date: Mon, 25 Sep 1995 10:11:12 -0600 In-Reply-To: naud@rem.virtualprototypes.ca (Jean-Marc Naud) "GL code in VEGA" (Sep 22, 3:35pm) References: <9509221935.AA07667@rem.virtualprototypes.ca> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: naud@rem.virtualprototypes.ca (Jean-Marc Naud), info-performer@sgi.sgi.com Subject: Re: GL code in VEGA Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I've used a channel post draw callback in VEGA to draw a simple HUD and I didn't have this problem. Unfortunately I don't have the code anymore. My example used a GL window, perhaps there are differences if you use an X window? On Sep 22, 3:35pm, Jean-Marc Naud wrote: > Subject: GL code in VEGA > > Help! > > This might not be the proper mailing list for this > question but here it is anyway: > > We are using Vega from Paradigm (which sits on top > of Performer). We put some GL drawing code in > a channel postdraw callback. But our drawing > is always done on the root window while VEGA > opens its own window. Obviously we would like > our drawing to be in the VEGA opened window NOT > on the root window. And there does not seem to > be a way to ask VEGA for the windowid of the > window it opens. > > Anyone with help out there? > > Thanks. > > > --------------------------------------------------------------------------- > Jean-Marc Naud Phone: (514) 341-3VPI > Virtual Prototypes Inc. FAX: (514) 341-6532 > 4700 de la Savane, Suite 300 Email: naud@VirtualPrototypes.CA > Montreal (Quebec) H4P 1T7 > > > > >-- End of excerpt from Jean-Marc Naud -- Angus Dorbie, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Mon Sep 25 07:21:21 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA29290; Mon, 25 Sep 1995 07:19:01 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA29287; Mon, 25 Sep 1995 07:19:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06587; Mon, 25 Sep 95 07:18:59 -0700 Received: from spiffy by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA28586; Mon, 25 Sep 1995 07:18:31 -0700 From: sharon@spiffy.paradigmsim.com Received: from sharonspc.paradigmsim.com by spiffy via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA13576; Mon, 25 Sep 1995 09:18:36 -0500 Date: Mon, 25 Sep 95 09:12:31 PDT Subject: RE: GL code in VEGA To: info-performer@sgi.sgi.com, Jean-Marc Naud X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Jean-Marc, You should use the vgAddFunc command to install a callback function which will be invoked postdraw on a specific channel. This is the typical method used to draw an overlay and will draw the overlay in the VEGA window, not the root window. I have just executed a test case which does this and it works appropriately. Let me know if you are still having problems with this. Regards, Sharon Lindholm Manager, Customer Advocacy Paradigm Simulation, Inc. ---------------Original Message--------------- Help! This might not be the proper mailing list for this question but here it is anyway: We are using Vega from Paradigm (which sits on top of Performer). We put some GL drawing code in a channel postdraw callback. But our drawing is always done on the root window while VEGA opens its own window. Obviously we would like our drawing to be in the VEGA opened window NOT on the root window. And there does not seem to be a way to ask VEGA for the windowid of the window it opens. Anyone with help out there? Thanks. --------------------------------------------------------------------------- Jean-Marc Naud Phone: (514) 341-3VPI Virtual Prototypes Inc. FAX: (514) 341-6532 4700 de la Savane, Suite 300 Email: naud@VirtualPrototypes.CA Montreal (Quebec) H4P 1T7 ----------End of Original Message---------- ------------------------------------- E-mail: sharon@paradigmsim.com Date: 12/05/94 Time: 10:17:33 This message was sent by Chameleon ------------------------------------- From guest Mon Sep 25 12:01:20 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA29872; Mon, 25 Sep 1995 11:57:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA29869; Mon, 25 Sep 1995 11:57:15 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22976; Mon, 25 Sep 95 11:57:11 -0700 Received: from bos1e.delphi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA23805; Mon, 25 Sep 1995 11:57:11 -0700 From: CINEMED127@delphi.com Received: from delphi.com by delphi.com (PMDF V5.0-5 #10880) id <01HVP3VO7VKG90NQDX@delphi.com> for info-performer@sgi.com; Mon, 25 Sep 1995 14:57:02 -0400 (EDT) Date: Mon, 25 Sep 1995 14:57:02 -0400 (EDT) Subject: job posting To: info-performer@sgi.sgi.com Message-Id: <01HVP3VO858290NQDX@delphi.com> X-Vms-To: IN%"info-performer@sgi.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: O Employment Opportunity Computer graphics programmer position open at Cine'-Med. Cine'-Med is an instructional technology developer that specializes in medical and surgical educational applications. We are developing a virtual reality surgical skills simulator that focuses on endoscopic surgery. The simulator is being developed on SGI using Performer. Ideal candidates will have a Masters in CS, and experience with Performer. Also, scince we have a small lab, candidates should have an interest in I/O integration. Interested parties should contact: cinemed127@delphi.com From guest Mon Sep 25 12:20:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA29939; Mon, 25 Sep 1995 12:09:30 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA29936; Mon, 25 Sep 1995 12:09:29 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23863; Mon, 25 Sep 95 12:09:21 -0700 Received: from banshee.camberva.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA26087; Mon, 25 Sep 1995 12:09:06 -0700 Received: by banshee.camberva.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id PAA03998; Mon, 25 Sep 1995 15:11:45 -0400 From: gwaldron@banshee.camberva.com (Glenn Waldron) Message-Id: <199509251911.PAA03998@banshee.camberva.com> Subject: acbuffer problem To: info-performer@sgi.sgi.com (Performer List) Date: Mon, 25 Sep 1995 15:11:42 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 639 Status: O I use the accumulation buffer to do motion blurring. I set it up, in the open-pipeline callback: drawmode(NORMALDRAW); acsize(12); gconfig(); ... and I use it in the post-draw callback: acbuf(AC_MULT, blur); acbuf(AC_ACCUMULATE, 1.0); acbuf(AC_RETURN, blur); ... This always worked fine. In a 800x600 window, I got a consistent 30 hertz frame rate on a 1-RM 2-CPU Onyx (with limiting turned on). Today, SGI came and installed a second RM4 board. Now I get a consistant 8.6 hertz running the same program. Taking out the three calls to acbuf() in the post-draw callback alleviates the problem. What's happening? Thanks, Glenn. From guest Tue Sep 26 05:55:07 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA02641; Tue, 26 Sep 1995 05:52:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA02638; Tue, 26 Sep 1995 05:52:06 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12236; Tue, 26 Sep 95 05:52:05 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA04329; Tue, 26 Sep 1995 05:52:01 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id WAA21500 (8.6.12/IDA-1.6); Tue, 26 Sep 1995 22:50:56 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA07506 (5.65c/IDA-1.5); Tue, 26 Sep 1995 13:27:01 +1000 Received: from murad (murad [8.0.0.108]) by aggro with SMTP id NAA04019 (8.6.12/IDA-1.6); Tue, 26 Sep 1995 13:33:53 +1000 Received: by murad (5.65) id AA01366; Tue, 26 Sep 1995 13:38:17 +1000 Date: Tue, 26 Sep 1995 13:38:17 +1000 (EST) From: Simon Bennett X-Sender: simonb@murad To: "Christopher G. Buell" Cc: info-performer@sgi.sgi.com Subject: SCRAMNet In-Reply-To: <9509251243.AA14529@fltsvr2.flight.wpafb.af.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Mon, 25 Sep 1995, Christopher G. Buell wrote: > I have been reading the messages concerning the problems with > mixing the SYS V IPC shared memory with the shared arenas that > Performer uses. Could using Systran's SCRAMNet memory directly > from a Performer application produce the same side-effects or > conflicts with the shared arenas? Doubt it. Mind you, I don't know what you're doing. I've used VMIC's reflective memory cards (VMIVME-5550) with Performer applications very sucessfully - and anyway, as Michael Smith pointed out - he uses SysV IPC with Performer OK - so maybe the incompatibiliies are now fixed? Have you been experiencing problems? +----------------------------------------------------------------------------+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 9981 0611 (x512) Meeting - an event where you take minutes and waste hours. From guest Tue Sep 26 07:37:32 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA02888; Tue, 26 Sep 1995 07:31:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA02885; Tue, 26 Sep 1995 07:31:01 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15320; Tue, 26 Sep 95 07:30:55 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA16313; Tue, 26 Sep 1995 07:30:49 -0700 Received: from cats.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA06374; Tue, 26 Sep 1995 10:27:56 -0400 Received: by cats.cae.ca (931110.SGI/930416.SGI.AUTO) for @poster.cae.ca:info-performer@sgi.com id AA04040; Tue, 26 Sep 95 10:26:42 -0400 From: "Bernard Leclerc" Message-Id: <9509261026.ZM4038@cats.cae.ca> Date: Tue, 26 Sep 1995 10:26:38 -0400 In-Reply-To: Simon Bennett "SCRAMNet" (Sep 26, 1:38pm) References: X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Simon Bennett , "Christopher G. Buell" Subject: Re: SCRAMNet Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Sep 26, 1:38pm, Simon Bennett wrote: > Subject: SCRAMNet > On Mon, 25 Sep 1995, Christopher G. Buell wrote: > > > I have been reading the messages concerning the problems with > > mixing the SYS V IPC shared memory with the shared arenas that > > Performer uses. Could using Systran's SCRAMNet memory directly > > from a Performer application produce the same side-effects or > > conflicts with the shared arenas? > > Doubt it. Mind you, I don't know what you're doing. I've used VMIC's > reflective memory cards (VMIVME-5550) with Performer applications very > sucessfully - and anyway, as Michael Smith pointed out - he uses SysV > IPC with Performer OK - so maybe the incompatibiliies are now fixed? > > Have you been experiencing problems? I doubt there's ever been any incompatibilities between SVR4 IPCs and IRIS arenas because we've been using shared memory segments to communicate between a simulation and a Performer process since october 1993. This's been done using Performer 1.0/1.2 on IRIX 4.0.5/5.2. We've never experienced any problem... -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Tue Sep 26 06:27:13 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA02675; Tue, 26 Sep 1995 06:16:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA02672; Tue, 26 Sep 1995 06:16:47 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12929; Tue, 26 Sep 95 06:16:40 -0700 Received: from gatekeeper.bvr.co.il by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA07600; Tue, 26 Sep 1995 06:16:33 -0700 Received: (from uucp@localhost) by gatekeeper.bvr.co.il (8.6.12/8.6.9) id NAA23769 for <@gatekeeper.bvr.co.il:info-performer@sgi.com>; Tue, 26 Sep 1995 13:17:46 GMT Received: from unknown(192.114.85.105) by gatekeeper.bvr.co.il via smap (V1.3) id sma023767; Tue Sep 26 15:17:46 1995 Received: by genie.bvr.co.il (940816.SGI.8.6.9/931108.SGI.AUTO.ANONFTP) for info-performer@sgi.com id PAA26313; Tue, 26 Sep 1995 15:16:41 +0200 From: "Ran Yakir" Message-Id: <9509261516.ZM26311@genie.bvr.co.il> Date: Tue, 26 Sep 1995 15:16:40 +0000 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: acbuffer problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 25, 3:11pm, Glenn Waldron wrote: > Subject: acbuffer problem > > I use the accumulation buffer to do motion blurring. I set it up, > in the open-pipeline callback: > > drawmode(NORMALDRAW); > acsize(12); > gconfig(); > ... > > and I use it in the post-draw callback: > > acbuf(AC_MULT, blur); > acbuf(AC_ACCUMULATE, 1.0); > acbuf(AC_RETURN, blur); > ... > > > This always worked fine. In a 800x600 window, I got a consistent > 30 hertz frame rate on a 1-RM 2-CPU Onyx (with limiting turned on). > Today, SGI came and installed a second RM4 board. Now I get a > consistant 8.6 hertz running the same program. Taking out the three > calls to acbuf() in the post-draw callback alleviates the problem. > What's happening? > > Thanks, Glenn. > > >-- End of excerpt from Glenn Waldron It seems that acbuf performance is very poor when in multisample mode. Maybe someone from SGI could answer why. It would be logical to sample the final frame buffer into the accumulation buffer. However, it seems that the acbuf() command does something with the sub-samples. Anyway, Glenn's problem is that, while he had ony 1 RM, he ran with no multisampling (default Performer behaviour for 1 RM, 1280x1024 vof). When an additional RM was added, there was suddenly enough room for 8 samples, and Performer goes into multisample mode. If you turn off multisampling by pfAntialias(PFAA_OFF), you'll get back to your fine performance. Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | From guest Tue Sep 26 10:24:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA03210; Tue, 26 Sep 1995 10:19:43 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA03207; Tue, 26 Sep 1995 10:19:42 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24700; Tue, 26 Sep 95 10:19:33 -0700 Received: from scn1.nmc.wpafb.af.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA15232; Tue, 26 Sep 1995 10:19:30 -0700 Received: by Wright-Patterson AFB Mailgate Tue Sep 26 12:42:31 1995 Received: from fltsvr1.flight.wpafb.af.mil by fltsvr2.flight.wpafb.af.mil (4.1/SMI-4.1) id AA15326; Tue, 26 Sep 95 12:42:29 EDT Date: Tue, 26 Sep 95 12:42:29 EDT From: buellcg@fltsvr2.flight.wpafb.af.mil (Christopher G. Buell) Message-Id: <9509261642.AA15326@fltsvr2.flight.wpafb.af.mil> To: info-performer@sgi.sgi.com Subject: SCRAMNet Status: O Simon and Bernard, Thanks for the input. For the most part we are not having any problems. But when we run a 3 channel scene, the application will freeze periodcally. Sometimes indefinitly, sometimes not so indefinitly. The application is not core dumping or dying. The processor activity is 0. From as near as I can determine, the draw process just simply hasn't seen the signal/event to start. I have been looking for any possibility where we might be creating an "MP-unsafe" situation for Performer. I wondered if the mapping of SCRAMNet memory to a Performer program might cause some of the same interactions that were described between the to types of shared memory libraries. We are running our application under Vega 1.2 (with Performer 1.2). I have been waiting for Performer 2.0 and Vega 2.0 to see if our problems persist. Thanks again for the input. Chris Buell Veda, Inc. buellcg@fltsvr1.flight.wpafb.af.mil From guest Tue Sep 26 11:28:39 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA03348; Tue, 26 Sep 1995 11:21:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA03345; Tue, 26 Sep 1995 11:21:13 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29458; Tue, 26 Sep 95 11:21:10 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA28062; Tue, 26 Sep 1995 11:21:04 -0700 Received: from poster.cae.ca (poster.cae.ca [142.39.22.1]) by bhole with SMTP (DuhMail/2.0) id OAA04250; Tue, 26 Sep 1995 14:06:30 -0400 Received: from cats.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA24825; Tue, 26 Sep 1995 14:03:12 -0400 Received: by cats.cae.ca (931110.SGI/930416.SGI.AUTO) for @poster.cae.ca:info-performer@sgi.com id AA04485; Tue, 26 Sep 95 14:01:38 -0400 From: "Bernard Leclerc" Message-Id: <9509261401.ZM4483@cats.cae.ca> Date: Tue, 26 Sep 1995 14:01:29 -0400 In-Reply-To: "Bernard Leclerc" "Re: SCRAMNet" (Sep 26, 10:26am) References: <9509261026.ZM4038@cats.cae.ca> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Simon Bennett , "Christopher G. Buell" Subject: Re: SCRAMNet Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Mon, 25 Sep 1995, Christopher G. Buell wrote: > I have been reading the messages concerning the problems with > mixing the SYS V IPC shared memory with the shared arenas that > Performer uses. Could using Systran's SCRAMNet memory directly > from a Performer application produce the same side-effects or > conflicts with the shared arenas? Concerning Systran's SCRAMNet card, we have successfully used it to interface our visual application (based on Performer) with a simulation process running on a different host. The mapping to SCRAMNet was done using a combination of open("/dev/mmem",...) and mmap(). There was no conflict between Performer arenas and SCRAMNet memory. So, regarding your problem, I don't think that using memory mapped RAM located on a SCRAMNet board is slower than using a IRIX shared arena. However, you have to realize that a SCRAMNet board plugs in the VME bus. The transfer rate on the VME bus is slower than the transfer rate on the SGI bus. Accessing SCRAMNet memory might be a little slower than accessing the main memory. Beside this transfer rate issue, there's no difference between the two kind of RAM. BTW, mmap() is not what's called SysV IPC. Semaphores (semget), shared memory segments (shmget) and message queues (msgget) form the basis for System V Inter-Process Communication (IPC). -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Tue Sep 26 12:27:45 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA03604; Tue, 26 Sep 1995 12:24:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA03601; Tue, 26 Sep 1995 12:24:06 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03830; Tue, 26 Sep 95 12:24:03 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA09993; Tue, 26 Sep 1995 12:23:46 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id MAA24079; Tue, 26 Sep 1995 12:07:51 -0700 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA02879; Tue, 26 Sep 95 12:07:34 -0700 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA06647; Tue, 26 Sep 1995 12:07:22 -0700 From: "Javier Castellar" Message-Id: <9509261207.ZM6645@sixty.asd.sgi.com> Date: Tue, 26 Sep 1995 12:07:21 -0700 In-Reply-To: "Ran Yakir" "Re: acbuffer problem" (Sep 26, 3:16pm) References: <9509261516.ZM26311@genie.bvr.co.il> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Ran Yakir" , info-performer@sgi.sgi.com Subject: Re: acbuffer problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I think that the problem is that they run out of framebuffer space for the acbuffer. One reason is that they let performer use 8 subsamples and then the acbuffer has no space to be allocated => software mode->SLOW I may suggest to force multisample with only FOUR subsamples and then use acbuffer, it should work fine (if i am not wrong ;-) ) -Javier -- o <\> (Fix and Create or Die) / \ ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-390-1589 * * Real-Time Graphics * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8U-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon From guest Tue Sep 26 13:02:14 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA03709; Tue, 26 Sep 1995 12:59:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA03706; Tue, 26 Sep 1995 12:59:06 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06287; Tue, 26 Sep 95 12:59:03 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA16191; Tue, 26 Sep 1995 12:58:56 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id MAA02173; Tue, 26 Sep 1995 12:41:27 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id MAA03595; Tue, 26 Sep 1995 12:40:51 -0700 From: "AnitaKishore" Message-Id: <9509261240.ZM3593@lee.electrogig.com> Date: Tue, 26 Sep 1995 12:40:50 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: motion blur in performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I have a problem in motion blur when I try doing it against a static background. I loose the "vapour trails" of the moving object with each accumulation because I think the remenants of the previous image of the moving object is being wiped off by the current accumulation of the scene. If I have no static part, then I get a nice moving geometry leaving behind it a nice vapour trail. My set up is as follows: scene graph looks like: pfScene | -------------- | | pfDCS static scene | background object to be motion blurred In the pipe window configuration callback: pfOpenPWin(pw); drawmode(NORMALDRAW); subpixel(TRUE); acsize (16); pfInitGfx(); acbuf (AC_CLEAR, 0.0); In the motion blurred geometry node's post traversal DRAW callback: acbuf(AC_MULT, .88); // .88 controls the size of vapour trail acbuf (AC_ACCUMULATE, 1.0); acbuf (AC_RETURN, 1.0); The object is translated to certain distance through the DCS. With this setting the inside of the object is blurred, but it doesn't have a trail. The call to acbuf (AC_ACCUMULATE, 1.0) destroys the previous contents of the acbuf and hence the trail is lost. Can somebody help me out?? Thanks for any help -anita ----------------------------------------------------------------------------- Anita Kishore kishore@electrogig.com ----------------------------------------------------------------------------- From guest Tue Sep 26 18:59:43 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA02282; Tue, 26 Sep 1995 18:49:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA02279; Tue, 26 Sep 1995 18:49:27 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28656; Tue, 26 Sep 95 18:49:16 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id SAA29467; Tue, 26 Sep 1995 18:48:46 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id LAA14727 (8.6.12/IDA-1.6); Wed, 27 Sep 1995 11:01:09 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA15728 (5.65c/IDA-1.5); Wed, 27 Sep 1995 10:30:44 +1000 Received: from murad (murad [8.0.0.108]) by aggro with SMTP id KAA06812 (8.6.12/IDA-1.6); Wed, 27 Sep 1995 10:37:34 +1000 Received: by murad (5.65) id AA02379; Wed, 27 Sep 1995 10:42:01 +1000 Date: Wed, 27 Sep 1995 10:42:01 +1000 (EST) From: Simon Bennett X-Sender: simonb@murad To: Bernard Leclerc Cc: "Christopher G. Buell" , info-performer@sgi.sgi.com Subject: Re: SCRAMNet In-Reply-To: <9509261026.ZM4038@cats.cae.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Tue, 26 Sep 1995, Bernard Leclerc wrote: > On Sep 26, 1:38pm, Simon Bennett wrote: > > Subject: SCRAMNet > I doubt there's ever been any incompatibilities between SVR4 IPCs and IRIS > arenas because we've been using shared memory segments to communicate between a > simulation and a Performer process since october 1993. This's been done using > Performer 1.0/1.2 on IRIX 4.0.5/5.2. > We've never experienced any problem... You missed a small detail from the earlier postings... I'm suggesting problems with IRIX 5.0 and 5.1.1.1 - not 4.0.5g (or whatever the first Onyx RE^2 IRIX version was) or 5.2/5.3 - I'm quite prepared to believe that it worked for every other version of IRIX. Anyway - it's in the IRIX Systems Programming Guide - so it must be true :) +----------------------------------------------------------------------------+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 9981 0611 (x512) Meeting - an event where you take minutes and waste hours. From guest Wed Sep 27 09:00:56 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA04078; Wed, 27 Sep 1995 08:58:39 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA04075; Wed, 27 Sep 1995 08:58:38 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20613; Wed, 27 Sep 95 08:58:36 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA00651; Wed, 27 Sep 1995 08:58:29 -0700 Received: from cats.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA22845; Wed, 27 Sep 1995 11:56:41 -0400 Received: by cats.cae.ca (931110.SGI/930416.SGI.AUTO) for @poster.cae.ca:kishore@electrogig.com id AA07304; Wed, 27 Sep 95 11:53:31 -0400 From: "Bernard Leclerc" Message-Id: <9509271153.ZM7302@cats.cae.ca> Date: Wed, 27 Sep 1995 11:53:25 -0400 In-Reply-To: "AnitaKishore" "motion blur in performer" (Sep 26, 12:40pm) References: <9509261240.ZM3593@lee.electrogig.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com, "Anita Kishore" Subject: Re: motion blur in performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Sep 26, 12:40pm, Anita Kishore wrote: > I have a problem in motion blur when I try doing it against a static > background. I loose the "vapour trails" of the moving object with each > accumulation because I think the remenants of the previous image of the > moving object is being wiped off by the current accumulation of the scene. > If I have no static part, then I get a nice moving geometry leaving behind > it a nice vapour trail. My set up is as follows: > > scene graph looks like: > > pfScene > | > -------------- > | | > pfDCS static scene > | background > object to be > motion blurred > > > In the pipe window configuration callback: > > pfOpenPWin(pw); > drawmode(NORMALDRAW); > subpixel(TRUE); > acsize (16); > pfInitGfx(); > acbuf (AC_CLEAR, 0.0); > > In the motion blurred geometry node's post traversal DRAW callback: > > acbuf(AC_MULT, .88); // .88 controls the size of vapour trail > acbuf (AC_ACCUMULATE, 1.0); > acbuf (AC_RETURN, 1.0); I have the impression that you should not use a node's post traversal DRAW callback since the scene hasn't been completely drawn yet. You should wait until everything is drawn, i.e. the moving object and the static background. I suggest to use a channel DRAW callback to accumulate the image. static void drawFunc(pfChannel* chan, void* data) { static float f = 0.0; chan->clearChan(); pfDraw(); acbuf(AC_MULT, .88); acbuf (AC_ACCUMULATE, 1.0); f = 0.88*f + 1.0; acbuf (AC_RETURN, 1.0/f); } > The object is translated to certain distance through the DCS. > > With this setting the inside of the object is blurred, but it doesn't > have a trail. The call to acbuf (AC_ACCUMULATE, 1.0) destroys the previous > contents of the acbuf and hence the trail is lost. Here, I suspect the moving object is drawn before the static background. With the node's post DRAW callback, you end up blurring the moving object on a black background. Later, when the static background is drawn, it erases the trail of the object. Hope it helps you... -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Wed Sep 27 11:17:16 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA04628; Wed, 27 Sep 1995 11:14:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA04625; Wed, 27 Sep 1995 11:14:09 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28793; Wed, 27 Sep 95 11:14:07 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA26810; Wed, 27 Sep 1995 11:14:02 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) id KAA08852; Wed, 27 Sep 1995 10:42:54 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA04383; Wed, 27 Sep 1995 10:42:17 -0700 From: "AnitaKishore" Message-Id: <9509271042.ZM4381@lee.electrogig.com> Date: Wed, 27 Sep 1995 10:42:16 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: bleclerc@cae.ca, info-performer@sgi.sgi.com Subject: motion blur in performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > I have the impression that you should not use a node's post traversal DRAW > callback since the scene hasn't been completely drawn yet. You should wait > until everything is drawn, i.e. the moving object and the static background. I > suggest to use a channel DRAW callback to accumulate the image. > > static void drawFunc(pfChannel* chan, void* data) > { > static float f = 0.0; > chan->clearChan(); > pfDraw(); > acbuf(AC_MULT, .88); > acbuf (AC_ACCUMULATE, 1.0); > f = 0.88*f + 1.0; > acbuf (AC_RETURN, 1.0/f); > } > > > The object is translated to certain distance through the DCS. > > > > With this setting the inside of the object is blurred, but it doesn't > > have a trail. The call to acbuf (AC_ACCUMULATE, 1.0) destroys the previous > > contents of the acbuf and hence the trail is lost. > > Here, I suspect the moving object is drawn before the static background. With > the node's post DRAW callback, you end up blurring the moving object on a black > background. Later, when the static background is drawn, it erases the trail of > the object. > > Hope it helps you... Bernard, The above suggestion works great! Thanks a lot. No idea about what I did correctly today, but all calls from the DRAW process callback are working (which were not so before)! Though the use of "f" in AC_RETURN call doesn't make any difference, with or without it. So thanks once again for your help. -anita ----------------------------------------------------------------------------- Anita Kishore kishore@electrogig.com ----------------------------------------------------------------------------- From guest Wed Sep 27 13:26:08 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA05194; Wed, 27 Sep 1995 13:22:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA05191; Wed, 27 Sep 1995 13:22:34 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05711; Wed, 27 Sep 95 13:22:29 -0700 Received: from ligsg1.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA19894; Wed, 27 Sep 1995 13:22:10 -0700 Received: by ligsg1.epfl.ch (Smail3.1.29.1 #28) id m0sy2yZ-0006sIC; Wed, 27 Sep 95 21:21 MET Message-Id: Date: Wed, 27 Sep 95 21:21 MET From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) To: info-performer@sgi.sgi.com Subject: quaternions revisited Reply-To: matomira@epfl.ch Status: O Hello, What happened regarding 2.0 and quaternion first-class citizenship? Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch GVRAI d* s: a- C++++ UI++ !L P-- E W+++ N+++ K? w--- !O M-- V p--- PS+++ PE++ Y+ PGP- t+ 5? X? tv+ b!+++ DI? D+ G- e+++ h-- r++ s !g w+ y* A07 HH PP--- v+++ M[o]+++ (((()))) From guest Wed Sep 27 14:27:34 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA05330; Wed, 27 Sep 1995 14:21:01 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA05327; Wed, 27 Sep 1995 14:21:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08852; Wed, 27 Sep 95 14:20:56 -0700 Received: from ligsg1.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA29152; Wed, 27 Sep 1995 14:20:47 -0700 Received: by ligsg1.epfl.ch (Smail3.1.29.1 #28) id m0sy3C7-0005uoC; Wed, 27 Sep 95 21:35 MET Message-Id: Date: Wed, 27 Sep 95 21:35 MET From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) To: info-performer@sgi.sgi.com Subject: quaternions revisited Reply-To: matomira@epfl.ch Status: O Hello, What happened regarding 2.0 and quaternion first-class citizenship? Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch GVRAI d* s: a- C++++ UI++ !L P-- E W+++ N+++ K? w--- !O M-- V p--- PS+++ PE++ Y+ PGP- t+ 5? X? tv+ b!+++ DI? D+ G- e+++ h-- r++ s !g w+ y* A07 HH PP--- v+++ M[o]+++ (((()))) From guest Wed Sep 27 14:40:18 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA05383; Wed, 27 Sep 1995 14:35:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA05380; Wed, 27 Sep 1995 14:35:10 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09699; Wed, 27 Sep 95 14:35:05 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA02166; Wed, 27 Sep 1995 14:34:55 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id NAA29795; Wed, 27 Sep 1995 13:59:00 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA07396; Wed, 27 Sep 95 13:58:55 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA03881; Wed, 27 Sep 1995 13:58:54 -0700 Message-Id: <199509272058.NAA03881@surreal.asd.sgi.com> To: matomira@epfl.ch Cc: info-performer@sgi.sgi.com Subject: Re: quaternions revisited In-Reply-To: Your message of "Wed, 27 Sep 95 21:21:00 +0700." Date: Wed, 27 Sep 95 13:58:53 -0700 From: Jim Helman Status: O 2.0 includes the quaternion support listed below. Also, pfMatrix::makeQuat(pfQuat &quat); -jim pfQuat(3pf) IRIS Performer 2.0 libpr C++ Reference Pages pfQuat(3pf) NAME pfQuat - Set and operate on quaternions FUNCTION SPECIFICATION #include void pfQuat::makeRot(float angle, float x, float y, float z); void pfQuat::getRot(float *angle, float *x, float *y, float *z); float pfQuat::length(void); void pfQuat::conj(const pfQuat& q); void pfQuat::exp(const pfQuat& q); void pfQuat::log(const pfQuat& q); void pfQuat::mult(const pfQuat& q1, const pfQuat& q2); void pfQuat::div(const pfQuat& q1, const pfQuat& q2); void pfQuat::invert(const pfQuat& q); int pfQuat::equal(const pfQuat& q1, const pfQuat& q2); int pfQuat::almostEqual(const pfQuat& q1, const pfQuat& q2, float tol); void pfQuat::slerp(float t, const pfQuat& q1, const pfQuat q2); void pfQuat::squad(float t, const pfQuat& q1, const pfQuat q2, const pfQuat& a, const pfQuat& b); extern void pfQuat::meanTangent(const pfQuat& q1, const pfQuat& q2, const pfQuat& q3); struct pfQuat : public pfVec4 PARENT CLASS FUNCTIONS The IRIS Performer class pfQuat is derived from the parent class pfVec4, so each of these member functions of class pfVec4 are also directly usable with objects of class pfQuat. Casting an object of class pfQuat to an object of class pfVec4 is taken care of automatically. This is also true for casts to objects of ancestor classes of class pfVec4. void pfVec4::addScaled(pfVec3& dst, const pfVec3& v1, float s, const pfVec3& v2); Page 1 pfQuat(3pf) IRIS Performer 2.0 libpr C++ Reference Pages pfQuat(3pf) void pfVec4::add(const pfVec4& v1, const pfVec4& v2); int pfVec4::almostEqual(const pfVec4& v2, float tol); void pfVec4::combine(float s1, const pfVec4& v1, float s2, const pfVec4& v2); void pfVec4::copy(const pfVec4& v); float pfVec4::distance(const pfVec4& pt2); float pfVec4::dot(const pfVec4& v2); int pfVec4::equal(const pfVec4 v2); float pfVec4::length(void); void pfVec4::negate(const pfVec4& v); float pfVec4::normalize(void); void pfVec4::scale(float s, const pfVec4& v); void pfVec4::set(float x, float y, float z, float w); float pfVec4::sqrDistance(const pfVec4& pt2); void pfVec4::sub(const pfVec4& v1, const pfVec4& v2); void pfVec4::xform(const pfVec4 v, const pfMatrix m); DESCRIPTION pfQuat represents a quaternion as the four floating point values (x, y, z, w) of a pfVec4. pfQuat::makeRot converts an axis and angle rotation representation to a quaternion. pfQuat::getRot is the inverse operation. It produces the axis (as a unit length direction vector) and angle equivalent to the given quaternion. Also see pfMatrix::makeQuat and pfMatrix::getOrthoQuat. Several monadic quaternion operators are provided. pfQuat::conj produces the complex conjugate dst of q by negating only the complex components (x, y, and z) which results in an inverse rotation. pfQuat::exp and pfQuat::log perform complex exponentiation and logarithm functions respectively. The length of a quaternion is computed by pfQuat::length and is defined as the norm of all four quaternion components. Macro equivalents are PFCONJ_QUAT and PFLENGTH_QUAT. For negation, use the pfVec4 routine, pfVec4::negate. pfQuat::mult and pfQuat::div are dyadic quaternion operations which provide the product, and quotient of two quaternions. When quaternions are used to represent rotations, multiplication of two quaternions is equivalent, but more efficient, than the multiplication of the two correspondinging rotation matrices. pfQuat::invert computes the multiplicative inverse of a quaternion. These operations are the basis from which the other quaternion capabilities have been derived. Macro equivalents are PFMULT_QUAT, PFDIV_QUAT, and PFINVERT_QUAT. For addition and scalar multiplciation, use the pfVec4 routines pfVec4::add, pfVec4::sub, and pfVec4::scale. Comparisons can be made with the pfVec4 member functions pfVec4::equal and pfVec4::almostEqual, since pfQuat is derived from pfVec4. Interpolation of quaternions (as presented by Ken Shoemake) is an effective technique for rotation interpolation. Spherical linear Page 2 pfQuat(3pf) IRIS Performer 2.0 libpr C++ Reference Pages pfQuat(3pf) interpolation is performed with pfQuat::slerp, which produces a pfQuat that is t of the way between q1 and q2. Spherical quadratic interpolation is provided by pfQuat::squad and its helper function, pfQuat::meanTangent. NOTES These functions use a pfVec4 to represent quaternions and store the imaginary part first, thus the array contents q = {x,y,z,w} are a representation of the quaternion w + xi + yj+ zk. Because both q and -q represent the same rotation (quaternions have a rotation range of [-360,360] degrees) conversions such as pfMatrix::getOrthoQuat make an arbitrary choice of the sign of the returned quaternion. To prevent the arbitrary sign from introducing large, unintended rotations, pfQuat::slerp checks the angle theta between q1 and q2. If theta exceeds 180 degrees, q2 is negated changing the interpolations range from [0,theta] to [0, theta-360 degrees]. For more information on quaternions, see the article by by Sir William Rowan Hamilton "On quaternions; or on a new system of imaginaries in algebra," in the Philosophical Magazine, xxv pp. 10-13 (July 1844). More recent references include "Animating Rotation with Quaternion Curves," SIGGRAPH Proceedings Vol 19, Number 3, 1985, and "Quaternion Calculus For Animation," in "Math for SIGGRAPH", Course Notes, #23, SIGGRAPH 1989, both by Ken Shoemake. Note that for consistency with Performer's transformation order, pfQuats are the conjugates of the quaternions described in these references. SEE ALSO pfVec4, pfMatrix Page 3 From guest Thu Sep 28 12:29:55 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA07543; Thu, 28 Sep 1995 12:15:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA07540; Thu, 28 Sep 1995 12:15:35 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03386; Thu, 28 Sep 95 12:15:27 -0700 Received: from ligsg10.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA21107; Thu, 28 Sep 1995 12:15:22 -0700 Received: by ligsg10.epfl.ch (Smail3.1.29.1 #28) id m0syOQ0-0000NxC; Thu, 28 Sep 95 20:14 MET Message-Id: Date: Thu, 28 Sep 95 20:14 MET From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) To: info-performer@sgi.sgi.com Subject: single-component modifications Reply-To: matomira@epfl.ch Status: O First of all, thanks for the quats.. Next, what about all those single-component modifications? eg: to change one component of a material color, you are forced to do a pfGetMtlColor first. Regards, Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch GVRAI d* s: a- C++++ UI++ !L P-- E W+++ N+++ K? w--- !O M-- V p--- PS+++ PE++ Y+ PGP- t+ 5? X? tv+ b!+++ DI? D+ G- e+++ h-- r++ s !g w+ y* A07 HH PP--- v+++ M[o]+++ (((()))) From guest Thu Sep 28 12:31:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA07553; Thu, 28 Sep 1995 12:28:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA07550; Thu, 28 Sep 1995 12:28:23 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04120; Thu, 28 Sep 95 12:28:18 -0700 Received: from archimedes.vislab.navy.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA23562; Thu, 28 Sep 1995 12:28:14 -0700 Received: from [129.131.31.10] (gawain.vislab.navy.mil [129.131.31.10]) by archimedes.vislab.navy.mil (current-1701B/current-CL-CL) with SMTP id MAA27975 for ; Thu, 28 Sep 1995 12:28:55 -0700 Date: Thu, 28 Sep 1995 12:28:55 -0700 Posted-Date: Thu, 28 Sep 1995 12:28:55 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: jan@archimedes.vislab.navy.mil (Jan A. Barglowski) Subject: Object location marker... Status: O I'm trying to mark a far away object that is too far to be "seen" on the screen. I'd like to draw a red square around the object, thus making it easier to tell which direction to look for it. I've seen this effect in Coryphaeus' Alladin demo, where an arrow points at the object. I'd like the marker to stay one size, regardless of the distance away the object is. My guess is to somehow get the 2d viewport coordinates of the object, then draw a 2d overlaid square around it. Anyone done this technique? Is there an easier/better way? Thanks! jan. Jan Anthony Barglowski Phone: (619) 927-1057 Computer Graphics Dude Internet: jan@vislab.navy.mil VisLab, China Lake Packet: KC6UTH@WA6YBN.#SOCA.CA.US.NA From guest Thu Sep 28 16:17:31 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA00882; Thu, 28 Sep 1995 16:02:43 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA00879; Thu, 28 Sep 1995 16:02:42 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18603; Thu, 28 Sep 95 16:02:32 -0700 Received: from od.sri.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA13816; Thu, 28 Sep 1995 16:02:26 -0700 Received: by od.sri.com (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id QAA10305; Thu, 28 Sep 1995 16:02:02 -0700 From: "Nathaniel Bletter" Message-Id: <9509281602.ZM10303@od.sri.com> Date: Thu, 28 Sep 1995 16:02:01 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: job offer at SRI International Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Job Vacancy in Virtual Perception Program, SRI International Title: Research Engineer Location: SRI International, Menlo Park, CA, US Salary Range: $30,000 - $40,000 / yr Start Date: 10/1/95 Length: 1 year - permanent Essential Functions: Designing, programming and testing multi-user virtual reality applications using advanced multi-server architectures and advanced networks. Other Duties: Designing, programming and presenting technical demonstrations. Writing technical reports. Contacting potential clients for virtual reality technology. Experience: At least 3 years of experience in computer graphics, networking, program management and/or distributed databases. Familiarity with Unix, C/C++, Silicon Graphics, GL, Inventor, Performer, and VRML Education: BS degree in CS/EE Company description: SRI International is one of the world's largest contract research firms. Founded in 1946 in conjunction with Stanford University as the Stanford Research Institute, we later became fully independent and were incorporated as a non-profit organization under U.S. and California laws. Solving client technological and business problems is our primary goal. SRI International established the Virtual Perception Program to explore the technology that has come to be known by such terms as virtual-reality, telepresence, and cyberspace. This program has three main thrusts: development of new hardware and software components for virtual-reality systems, development of virtual-reality applications, and evaluation of the (application-dependent) sensory requirements of virtual-reality systems. SHAVE (SHAred Virtual Environment), one of the groups main projects, is a multi-user virtual environment system that allows several users on the internet to interact whithin a shared 3D world. The SHAVE system provides a framework for remote collaborative work whithin interactive and editable 3D worlds. The current SHAVE prototype runs on SGI platforms, and a PC version is under development. It uses the OpenInventor 3D library and the Performer Toolkit, both based on OpenGL. If interested, please mail, fax, or email resumes to Nat Bletter SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 USA email: nat@od.sri.com fax: (415) 859-5984 -- Nat Bletter SRI International nat@od.sri.com http://os.sri.com/people/nat/ From guest Fri Sep 29 14:27:02 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA01103; Fri, 29 Sep 1995 14:21:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA01100; Fri, 29 Sep 1995 14:21:59 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11382; Fri, 29 Sep 95 01:08:42 -0700 Received: from death.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA14966; Fri, 29 Sep 1995 01:08:26 -0700 Received: by death.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) for info-performer@sgi.sgi.com id IAA28395; Fri, 29 Sep 1995 08:05:44 GMT From: "Angus Henderson" Message-Id: <9509290805.ZM28393@death.reading.sgi.com> Date: Fri, 29 Sep 1995 08:05:43 +0000 In-Reply-To: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) "quaternions revisited" (Sep 27, 9:21pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: quaternions revisited Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Everyone laughs at my Su 35 flight model cos I let the pilot fly way outside the envelope covered by all the other flight simulators you see on Silicon Graphics demos ( not real ones I hasten to add in case I offend someone who simulates every atom around an X31 at 600 Hz. ) I really need to put some quaternions into the equations of motion so it will go nicely aerobatic - but I don't know the first bloody thing about them. What should I read to help me - I just ordered "Flight SImulation" by J.M. Rolfe but it's taking for ever to come. ANy advise etc... ANgus From guest Fri Sep 29 14:27:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA01098; Fri, 29 Sep 1995 14:21:58 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA01095; Fri, 29 Sep 1995 14:21:57 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11781; Fri, 29 Sep 95 01:28:34 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA16757; Fri, 29 Sep 1995 01:28:19 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/940406.SGI) id JAA01457; Fri, 29 Sep 1995 09:22:52 +0100 From: "Angus Dorbie" Message-Id: <9509290922.ZM1455@bitch.reading.sgi.com> Date: Fri, 29 Sep 1995 09:22:52 +0100 In-Reply-To: jan@archimedes.vislab.navy.mil (Jan A. Barglowski) "Object location marker..." (Sep 28, 12:28pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: jan@archimedes.vislab.navy.mil (Jan A. Barglowski), info-performer@sgi.sgi.com Subject: Re: Object location marker... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O A really easy way without changing to orthographic projection is to use cmov() to the distant object position then charstr() but you have limited control over appearance or scale. On Sep 28, 12:28pm, Jan A. Barglowski wrote: > Subject: Object location marker... > I'm trying to mark a far away object that is too far to be "seen" on the > screen. I'd like to draw a red square around the object, thus making it > easier to tell which direction to look for it. I've seen this effect in > Coryphaeus' Alladin demo, where an arrow points at the object. I'd like > the marker to stay one size, regardless of the distance away the object is. > > My guess is to somehow get the 2d viewport coordinates of the object, then > draw a 2d overlaid square around it. Anyone done this technique? Is there > an easier/better way? > > Thanks! > > jan. > > > Jan Anthony Barglowski Phone: (619) 927-1057 > Computer Graphics Dude Internet: jan@vislab.navy.mil > VisLab, China Lake Packet: KC6UTH@WA6YBN.#SOCA.CA.US.NA > > > > >-- End of excerpt from Jan A. Barglowski -- Angus Dorbie, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Fri Sep 29 14:27:02 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA01108; Fri, 29 Sep 1995 14:22:02 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA01105; Fri, 29 Sep 1995 14:22:00 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11910; Fri, 29 Sep 95 01:34:14 -0700 Received: from death.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) id BAA19544; Fri, 29 Sep 1995 01:34:07 -0700 Received: by death.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id IAA28453; Fri, 29 Sep 1995 08:31:11 GMT From: "Angus Henderson" Message-Id: <9509290831.ZM28451@death.reading.sgi.com> Date: Fri, 29 Sep 1995 08:31:11 +0000 In-Reply-To: simonb@wormald.com.au "Re: Using paths?" (Sep 28, 7:23pm) References: <9509280923.AA03571@murad> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: simonb@wormald.com.au Subject: Re: Using paths? Cc: info-performer@sgihub.corp.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Here is what is on sgigate.sgi.com:~ftp/pub/Performer/RealityCentre Databases.tar.Z - Some databases which work with "perpath" atlantis.tar.Z - The fish demo upon which I have based an entire career flames.tar.Z - A smoke & flames special effect tools.tar.Z - Loads of free tools to help database modellers Medit_dist - The famous cheap database modelling tool distort.tar.Z - A distortion correction demo perpath.tar.Z - Perfly including paths,smoke,medit & parameter init files. ANgus From guest Fri Sep 29 14:26:17 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA01051; Fri, 29 Sep 1995 14:21:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA01048; Fri, 29 Sep 1995 14:21:14 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17102; Fri, 29 Sep 95 06:11:12 -0700 Received: from mailbox.swip.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA05402; Fri, 29 Sep 1995 06:10:47 -0700 Received: from dialup97-072.swipnet.se (dialup97-072.swipnet.se [130.244.97.72]) by mailbox.swip.net (8.6.12/8.6.12) with SMTP id OAA22074 for ; Fri, 29 Sep 1995 14:10:43 +0100 Date: Fri, 29 Sep 1995 14:10:43 +0100 Message-Id: <199509291310.OAA22074@mailbox.swip.net> X-Sender: m-3509@mailbox.swipnet.se Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: info-performer@sgi.sgi.com From: per.andersson@mailbox.swipnet.se (Ulf Yngve) Subject: pfMakePerspFrust and pfEarthSky X-Mailer: Status: O Hi! I have a problem when I try ty use pfMakePerspFrust and a pfEarthSky. My problem is that I have a viewing frustum like this \ | <- \ | line \ | of \ | sight \ | ---- ^ Eye When I use this together with an earth-sky of mode sky_ground the sky polygons doesn=B4t update a part of the upper left corner of the=20 screen. The problem disappears when I use a simple frustum of the same angle. Is it a bug or am I doing something else wrong. Does anyone have a fix or can i go around it in any way. Regards Ulf Yngwe From guest Fri Sep 29 14:26:11 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA01031; Fri, 29 Sep 1995 14:20:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA01028; Fri, 29 Sep 1995 14:20:47 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19339; Fri, 29 Sep 95 07:34:46 -0700 Received: from sgigate.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id HAA08001; Fri, 29 Sep 1995 07:34:48 -0700 Received: from octagon.tacom.army.mil by sgigate.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/940406.SGI) for id HAA02086; Fri, 29 Sep 1995 07:34:47 -0700 From: tidrowd@cc.tacom.army.mil Received: from cc-gw.tacom.army.mil by octagon.tacom.army.mil (8.6.12/8.6.12-kbp) with SMTP id KAA24301; Fri, 29 Sep 1995 10:34:45 -0400 Received: from ccMail by cc-gw.tacom.army.mil (IMA Internet Exchange 1.04b) id 06c03e90; Fri, 29 Sep 95 10:34:17 -0400 Mime-Version: 1.0 Date: Fri, 29 Sep 1995 10:29:08 -0400 Message-Id: <06c03e90@cc-gw.tacom.army.mil> Subject: Old Messages To: info-performer@sgihub.corp.sgi.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Status: O Could somebody tell me where the archives of this mailing list are stored? I inadvertently deleted a message I wanted to keep. TIA. Don Tidrow Visual Simulation Developer US Army Tank-automotive and Armaments Command From guest Fri Sep 29 14:25:14 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA00920; Fri, 29 Sep 1995 14:18:30 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA00917; Fri, 29 Sep 1995 14:18:30 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29565; Fri, 29 Sep 95 10:50:40 -0700 Received: from ligsg1.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA20745; Fri, 29 Sep 1995 10:50:33 -0700 Received: by ligsg1.epfl.ch (Smail3.1.29.1 #28) id m0syjN5-00025AC; Fri, 29 Sep 95 18:37 MET Message-Id: Date: Fri, 29 Sep 95 18:37 MET From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) To: info-performer@sgi.sgi.com Subject: Polylines and Wavefront loader Reply-To: matomira@epfl.ch Status: O Hello, Does the new Wavefront loader support polylines? Anybody who has already modified the old one out there? Thanks in advance, Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch GVRAI d* s: a- C++++ UI++ !L P-- E W+++ N+++ K? w--- !O M-- V p--- PS+++ PE++ Y+ PGP- t+ 5? X? tv+ b!+++ DI? D+ G- e+++ h-- r++ s !g w+ y* A07 HH PP--- v+++ M[o]+++ (((()))) From guest Fri Sep 29 14:24:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA00861; Fri, 29 Sep 1995 14:16:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA00858; Fri, 29 Sep 1995 14:16:00 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06730; Fri, 29 Sep 95 12:33:27 -0700 Received: from ligsg4.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA15120; Fri, 29 Sep 1995 12:32:57 -0700 Received: by ligsg4.epfl.ch (Smail3.1.29.1 #28) id m0syks8-0005Q5C; Fri, 29 Sep 95 20:13 MET Message-Id: Date: Fri, 29 Sep 95 20:13 MET From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) To: info-performer@sgi.sgi.com Subject: `billboard' labels? Reply-To: matomira@epfl.ch Status: O Here I go again.. Is there any support for placing `billboard' 2D font labels in the scene graph in 2.0? BTW, There's something funny about the per-vertex color assignment in the Inventor loader I'm using (1.44). Has this been fixed already? Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch GVRAI d* s: a- C++++ UI++ !L P-- E W+++ N+++ K? w--- !O M-- V p--- PS+++ PE++ Y+ PGP- t+ 5? X? tv+ b!+++ DI? D+ G- e+++ h-- r++ s !g w+ y* A07 HH PP--- v+++ M[o]+++ (((()))) From guest Fri Sep 29 15:39:33 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA01938; Fri, 29 Sep 1995 15:33:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA01935; Fri, 29 Sep 1995 15:33:22 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18078; Fri, 29 Sep 95 15:33:19 -0700 Received: from ccvax.lanl.gov by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA17182; Fri, 29 Sep 1995 15:32:43 -0700 Date: Fri, 29 Sep 1995 15:32:43 -0700 Message-Id: <199509292232.PAA17182@sgi.sgi.com> Received: from spock.visidyne.hsv.com ([204.121.254.10]) by ccvax.lanl.gov with SMTP; Fri, 29 Sep 1995 16:33:42 -0600 (MDT) X-Sender: 608122@ccvax X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: ken sartor Subject: IRIX IPC Status: O Hi - This is not really a performer question but... I am using IRIX shared memory to communicate data from a non-performer app to a performer app with the following problem. It works just fine until i increase the memory above a certain amount (about 120K). Then the usmalloc returns a NULL and problems arise. Any ideas? Thanks in advance! From guest Fri Sep 29 16:55:02 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA02287; Fri, 29 Sep 1995 16:51:40 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA02284; Fri, 29 Sep 1995 16:51:39 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22674; Fri, 29 Sep 95 16:51:37 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA01393; Fri, 29 Sep 1995 16:51:32 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id QAA28140; Fri, 29 Sep 1995 16:47:26 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA22442; Fri, 29 Sep 95 16:47:13 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA13633; Fri, 29 Sep 1995 16:47:09 -0700 Message-Id: <199509292347.QAA13633@surreal.asd.sgi.com> To: per.andersson@mailbox.swipnet.se (Ulf Yngve) Cc: info-performer@sgi.sgi.com Subject: Re: pfMakePerspFrust and pfEarthSky In-Reply-To: Your message of "Fri, 29 Sep 95 14:10:43 BST." <199509291310.OAA22074@mailbox.swip.net> Date: Fri, 29 Sep 95 16:47:09 -0700 From: Jim Helman Status: O It's a bug in Performer 1.2. EarthSky does not work properly for off-axis viewing frsuta. I won't say "fixed in 2.0", because it isn't yet. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Sep 29 16:53:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA02282; Fri, 29 Sep 1995 16:50:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA02279; Fri, 29 Sep 1995 16:50:23 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22615; Fri, 29 Sep 95 16:50:18 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id QAA01154; Fri, 29 Sep 1995 16:49:57 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA22590; Fri, 29 Sep 95 16:49:54 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA13645; Fri, 29 Sep 1995 16:49:54 -0700 Message-Id: <199509292349.QAA13645@surreal.asd.sgi.com> To: "Angus Henderson" Cc: info-performer@sgi.sgi.com Subject: Re: quaternions revisited In-Reply-To: Your message of "Fri, 29 Sep 95 08:05:43 -0000." <9509290805.ZM28393@death.reading.sgi.com> Date: Fri, 29 Sep 95 16:49:53 -0700 From: Jim Helman Status: O Graphics Gems has some stuff on quats, but Ken Shoemake's papers more lucid. From the pfQuat man page: For more information on quaternions, see the article by Sir William Rowan Hamilton "On quaternions; or on a new system of imaginaries in algebra," in the Philosophical Magazine, xxv pp. 10-13 (July 1844). More recent references include "Animating Rotation with Quaternion Curves," SIGGRAPH Proceedings Vol 19, Number 3, 1985, and "Quaternion Calculus For Animation," in "Math for SIGGRAPH", Course Notes, #23, SIGGRAPH 1989, both by Ken Shoemake. Note that for consistency with Performer's transformation order, pfQuats are the conjugates of the quaternions described in these references. There's a *very* nice little tutorial paper available on. ftp://ftp.cis.upenn.edu/pub/graphics/shoemake rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Sep 29 17:09:48 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA02412; Fri, 29 Sep 1995 17:06:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA02409; Fri, 29 Sep 1995 17:06:25 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23529; Fri, 29 Sep 95 17:06:22 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA03071; Fri, 29 Sep 1995 17:06:12 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id QAA28716; Fri, 29 Sep 1995 16:54:27 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA22805; Fri, 29 Sep 95 16:54:22 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA13677; Fri, 29 Sep 1995 16:54:21 -0700 Message-Id: <199509292354.QAA13677@surreal.asd.sgi.com> To: ken sartor Cc: info-performer@sgi.sgi.com Subject: Re: IRIX IPC In-Reply-To: Your message of "Fri, 29 Sep 95 15:32:43 PDT." <199509292232.PAA17182@sgi.sgi.com> Date: Fri, 29 Sep 95 16:54:21 -0700 From: Jim Helman Status: O What size did you usconfig your usinit for? The most common cause of a failed usmalloc is that you're out of space in the arena. Also, if you have usinit problems, the most common cause of a failed usinit is insufficient available memory or an address conflict with something already in the current executable's virtual address space. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Sep 29 17:49:06 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA02805; Fri, 29 Sep 1995 17:45:08 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA02802; Fri, 29 Sep 1995 17:45:07 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA25778; Fri, 29 Sep 95 17:45:04 -0700 Received: from rs2.hrz.th-darmstadt.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id RAA09561; Fri, 29 Sep 1995 17:44:47 -0700 From: reiners@igd.fhg.de Received: from igd.igd.fhg.de (dakeeper.igd.fhg.de) by rs2.hrz.th-darmstadt.de with SMTP id AA05349 (5.65c/IDA-1.4.4 for ); Sat, 30 Sep 1995 01:12:10 +0100 Received: by igd.igd.fhg.de; Sat, 30 Sep 95 01:12:18 +0100 Received: by uderzo.igd.fhg.de (940816.SGI.8.6.9/SMI-4.0) id BAA00188; Sat, 30 Sep 1995 01:04:40 +0100 Date: Sat, 30 Sep 1995 01:04:40 +0100 Message-Id: <9509300104.ZM182@uderzo> In-Reply-To: ken sartor "IRIX IPC" (Sep 29, 15:32) References: <199509292232.PAA17182@sgi.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: ken sartor Subject: Re: IRIX Arena size Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Sep 29, 15:32, ken sartor wrote: > Subject: IRIX IPC > > Hi - > > This is not really a performer question but... > > I am using IRIX shared memory to communicate data from > a non-performer app to a performer app with the following > problem. It works just fine until i increase the memory > above a certain amount (about 120K). Then the usmalloc > returns a NULL and problems arise. Any ideas? > >-- End of excerpt from ken sartor This is one of the problems I've run into, too. At arena creation time you have to specify the maximum size your arena can have. If you ever exceed that size you'll get no more mem. My solution was to estimate how much I could reasonably get with the following code snippet: #include #include #include #include { struct rlimit data, vmem; off_t swap; long size; inventory_t *inv; swapctl(SC_GETFREESWAP, &swap); swap*=512; getrlimit(RLIMIT_VMEM, &vmem); getrlimit(RLIMIT_DATA, &data); for (inv=getinvent(); inv && (inv->inv_class!=INV_MEMORY || inv->inv_type!=INV_MAIN); inv=getinvent()); size=min(min(data.rlim_cur, vmem.rlim_cur), (swap+inv->inv_state)*.9); usconfig(CONF_INITSIZE, size); } This will allocate an arena size of the minimum of - maximum process data size, as defined by setrlimit - maximum process virtual memory size, as defined by setrlimit (these are usually 512MB) - 90% of (free swap space + main memory size) It think this makes sense, but any comments are welcome. BTW, I thought the default size was 64K, so if you don't set any, you should have had the problem much earlier. Dirk From guest Fri Sep 29 17:49:05 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA02810; Fri, 29 Sep 1995 17:45:39 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA02807; Fri, 29 Sep 1995 17:45:38 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA25833; Fri, 29 Sep 95 17:45:36 -0700 Received: from sgigate.sgi.com by sgihub.corp.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for id RAA04167; Fri, 29 Sep 1995 17:45:39 -0700 Received: from bhole.cae.ca by sgigate.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/940406.SGI) for id RAA27485; Fri, 29 Sep 1995 17:45:37 -0700 Received: from cats.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA25891; Fri, 29 Sep 1995 20:43:41 -0400 Received: by cats.cae.ca (931110.SGI/930416.SGI.AUTO) for @poster.cae.ca:info-performer@sgihub.corp.sgi.com id AA15492; Fri, 29 Sep 95 20:39:50 -0400 From: "Bernard Leclerc" Message-Id: <9509292039.ZM15490@cats.cae.ca> Date: Fri, 29 Sep 1995 20:39:45 -0400 In-Reply-To: tidrowd@cc.tacom.army.mil "Old Messages" (Sep 29, 10:29am) References: <06c03e90@cc-gw.tacom.army.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: tidrowd@cc.tacom.army.mil, info-performer@sgihub.corp.sgi.com Subject: Re: Old Messages Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Sep 29, 10:29am, "Don Tidrow" wrote: > Could somebody tell me where the archives of this mailing list are > stored? I inadvertently deleted a message I wanted to keep. Look in sgigate.sgi.com:pub/Performer/monthly-archives However, you wont find this month's archive yet. The last one is from July. -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4