From guest Thu Dec 1 03:44:10 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA09621; Thu, 1 Dec 1994 03:29:13 -0800 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 DAA09618; Thu, 1 Dec 1994 03:29:11 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA25118; Thu, 1 Dec 94 03:29:09 -0800 Received: from INGFI1.ING.UNIFI.IT by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id DAA07688; Thu, 1 Dec 1994 03:29:05 -0800 Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Thu, 1 Dec 1994 12:28:43 +0200 (MET) Received: by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA29886; Thu, 1 Dec 94 12:25:06 +0100 Date: Thu, 1 Dec 94 12:25:06 +0100 From: Riccardo Camiciottoli Message-Id: <9412011125.AA29886@aguirre.ing.unifi.it> To: info-performer@sgi.sgi.com Subject: subscribe_me camiciot@aguirre.ing.unifi.it Status: O subscribe_me camiciot@aguirre.ing.unifi.it From guest Thu Dec 1 13:18:10 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA10376; Thu, 1 Dec 1994 13:03:26 -0800 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 NAA10373; Thu, 1 Dec 1994 13:03:24 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA06446; Thu, 1 Dec 94 13:03:23 -0800 Received: from relay.iunet.it by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id NAA09606; Thu, 1 Dec 1994 13:03:11 -0800 Received: from hpdtmt2.UUCP by relay.iunet.it with UUCP id AA17142 (5.65c8/IDA-1.4.4 for info-performer%sgi.com@iunet.it); Thu, 1 Dec 1994 22:11:22 +0100 Message-Id: <199412012111.AA17142@relay.iunet.it> Received: by hpdtmt2 (16.6/16.2) id AA17785; Thu, 1 Dec 94 14:09:19 +0100 From: Marco Crocetta Subject: Infraredlighting To: info-performer@sgi.sgi.com Date: Thu, 1 Dec 94 14:09:18 MET Mailer: Elm [revision: 66.25] Status: O Hi, I need to simulate an infrared lighting in my application. I read in the Performer Programming Guide, that color tables can help me in doing this: pag. 27 says "Color Tables can be used for special effects such as infrared lighting ...". The problem is that in the manuals I have not found any exeample or reference about how producing such effects. The question is: there is someone who can help me in understanding how I have to use Color tables to generate infrared lightings? Thanks in Advance -------------------------- Marco Crocetta DATAMAT SpA, Rome E-Mail: onyx@datamat.it -------------------------- From guest Thu Dec 1 13:41:25 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA10564; Thu, 1 Dec 1994 13:24:58 -0800 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 NAA10561; Thu, 1 Dec 1994 13:24:57 -0800 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA07191; Thu, 1 Dec 94 13:24:56 -0800 Received: from holodeck.asd.sgi.com by sgihub.corp.sgi.com via ESMTP (940519.SGI.8.6.9/911001.SGI) for id NAA04920; Thu, 1 Dec 1994 13:24:55 -0800 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id NAA10558; Thu, 1 Dec 1994 13:24:50 -0800 From: aschaffe (Allan Schaffer) Message-Id: <9412011324.ZM10556@holodeck.asd.sgi.com> Date: Thu, 1 Dec 1994 13:24:49 -0800 In-Reply-To: halliday@BanffCentre.AB.CA (Sean Halliday) "Re: Antialiasing and other RE stuff" (Nov 30, 9:35am) References: <9411301635.AA06649@grizzly.BanffCentre.AB.CA> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgihub.corp.sgi.com Subject: Re: Antialiasing and other RE stuff Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > > I have had similar problems on our ONYX (OS 5.2, 2 CPU's, 2 RM's), > except it appears as a transparency problem (maybe AA too, it's hard > to tell in NTSC). I ran at 4@640x486_30i. I have seen the same > problem when I run at 1600x1200 (small pixel depth), so for some > reason the machine thinks it's in small pixel depth mode when no one > is logged in to the console. We are running the visuallogin. The > problem is not there if I log on to the console. This is something that has been mentioned a few times before; I'll add it to the FAQ list. This is a bug of sorts; it is caused by 'clogin' and 'chost' using the ImageVision library to display bitmap images of users & machine types. On RealityEngine the IL uses hardware acceleration to scale the images, which gobbles up framebuffer memory. The symptoms show up when Performer (or any other GL application) tries to configure the framebuffer. Since the framebuffer memory is already in use (by clogin or chost) Performer has to back off & ask for something less. It's possible to work around this, somewhat: setenv IL_HW_ACCELERATE 0 should force the IL to do its' computations on the host. Or to work around it for just 'clogin' you can 'chkconfig visuallogin off'. Or just log in. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Thu Dec 1 18:38:08 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA11838; Thu, 1 Dec 1994 18:22:09 -0800 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 SAA11835; Thu, 1 Dec 1994 18:22:04 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA16797; Thu, 1 Dec 94 18:21:59 -0800 Received: from trout.nosc.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id SAA29501; Thu, 1 Dec 1994 18:21:56 -0800 Received: from cod.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA05032; Thu, 1 Dec 94 18:21:54 PST Received: by cod.nosc.mil (4.1/SMI-4.1) id AA01513; Thu, 1 Dec 94 18:20:49 PST Date: Thu, 1 Dec 94 18:20:49 PST From: goodhart@cod.nosc.mil (Curtis L. Goodhart) Message-Id: <9412020220.AA01513@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: Traverse Question Cc: goodhart@cod.nosc.mil, ling@cod.nosc.mil Status: O 1) How can one traverse the scene hierarchy for some arbitrary reason? Is the only way to traverse, by using either pfCull, pfDraw, or pfSegsIsectNode? For example I would like to traverse the hierarchy computing some information at each Geode, but not draw anything as a result of the traversal. My understanding is that pfCull will issue draw commands. I want to do my computational traversal with no drawing then after that do a regular cull and draw. Thanks, Curt Goodhart From guest Thu Dec 1 22:19:35 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA04541; Thu, 1 Dec 1994 22:04:02 -0800 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 WAA04538; Thu, 1 Dec 1994 22:04:01 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA21583; Thu, 1 Dec 94 22:03:59 -0800 Received: from qbert.paradigmsim.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id WAA17752; Thu, 1 Dec 1994 22:03:55 -0800 Received: by qbert.paradigmsim.com (931110.SGI/921111.SGI.AUTO) for info-performer@sgi.com id AA22270; Fri, 2 Dec 94 00:01:43 -0600 From: aaron@qbert.paradigmsim.com (Aaron Hightower) Message-Id: <9412020601.AA22270@qbert.paradigmsim.com> Subject: Re: Traverse Question To: goodhart@cod.nosc.mil (Curtis L. Goodhart) Date: Fri, 2 Dec 1994 00:01:42 -0600 (CST) Cc: info-performer@sgi.sgi.com In-Reply-To: <9412020220.AA01513@cod.nosc.mil> from "Curtis L. Goodhart" at Dec 1, 94 06:20:49 pm Reply-To: aaron@paradigmsim.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2253 Status: O > 1) How can one traverse the scene hierarchy for some > arbitrary reason? > > Is the only way to traverse, by using either pfCull, > pfDraw, or pfSegsIsectNode? Nope. > For example I would like to traverse the hierarchy > computing some information at each Geode, but not > draw anything as a result of the traversal. My > understanding is that pfCull will issue draw commands. > I want to do my computational traversal with no > drawing then after that do a regular cull and draw. /* ============================================================================ General traversal to do stuff on all pfGeodes in a performer subtree ============================================================================ */ void myTraverse( pfNode *node ) { int i,n; if( pfGetType( node ) == PFTYPE_GEODE ) { /*** Do your cool stuff to geodes here ***/ return; } if( !(pfGetType( node ) & PFCLASS_GROUP )) return; n = pfGetNumChildren( node ); for(i=0; i > Thanks, > > Curt Goodhart Hope this helps! -- _ _______________________________________________ | | __| |___ Aaron Hightower, aaron@paradigmsim.com \ * / Paradigm Simulation Inc 214-960-2301 \_ / 15280 Addison Rd. \ ( Dallas, TX 75248 Vega Development \/ _______________________________________________ From guest Fri Dec 2 02:00:43 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA05211; Fri, 2 Dec 1994 01:33:06 -0800 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 BAA05208; Fri, 2 Dec 1994 01:33:05 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03093; Fri, 2 Dec 94 01:33:00 -0800 Received: from INGFI1.ING.UNIFI.IT by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id BAA06003; Fri, 2 Dec 1994 01:32:48 -0800 Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Fri, 2 Dec 1994 10:32:24 +0200 (MET) Received: from ozon180.ing.unifi.it by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA01764; Fri, 2 Dec 94 10:28:41 +0100 Received: by ozon180.ing.unifi.it (5.0/SMI-SVR4) id AA11335; Fri, 2 Dec 1994 10:28:44 +0100 Date: Fri, 2 Dec 1994 10:28:44 +0100 From: camiciot@aguirre (Riccardo Camiciottoli) Message-Id: <9412020928.AA11335@ozon180.ing.unifi.it> To: info-performer@sgi.sgi.com Subject: 3-D glasses on Indy machine Cc: camiciot@aguirre.ing.unifi.it X-Sun-Charset: US-ASCII Content-Length: 554 Status: O I'm an italian engineering student and I'm trying to install and use the 3-D SEGA glasses on Silicon Graphics Indy machine. In back side of Indy there is a glasses reserved output. 1) Is there someone that can sending me the scheme of the signals from this output port? 2) How can I control the double buffering mode in a Performer program to achieve the 3-D effect with glasses? Thanks in advance. Riccardo Camiciottoli Universita' di Firenze Facolta' di Ingegneria Dipartimento di Sistemi e Informatica email: camiciot@aguirre.ing.unifi.it From guest Fri Dec 2 03:20:34 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA05290; Fri, 2 Dec 1994 02:55:17 -0800 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 CAA05287; Fri, 2 Dec 1994 02:55:09 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03990; Fri, 2 Dec 94 02:55:08 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id CAA10209; Fri, 2 Dec 1994 02:55:07 -0800 Received: from sgifra.paris.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id CAA20266; Fri, 2 Dec 1994 02:55:00 -0800 Received: from theix.paris.sgi.com by sgifra.paris.sgi.com via SMTP (920330.SGI/911001.SGI) for @sgihub.corp.sgi.com,@FORWARDHOST.BAR.FOO.COM:info-performer@sgi.sgi.com id AA16069; Fri, 2 Dec 94 11:54:41 +0100 Received: by theix.paris.sgi.com (931110.SGI/930416.SGI) for @FORWARDHOST.BAR.FOO.COM:ghilde@paris.sgi.com id AA02321; Fri, 2 Dec 94 12:01:29 +0100 From: "Philippe CHURLET" Message-Id: <9412021201.ZM2319@theix.paris.sgi.com> Date: Fri, 2 Dec 1994 12:01:29 +0100 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Cc: ghilde@paris.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O subscribe pchurlet@paris.sgi.com From guest Fri Dec 2 08:30:20 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA05521; Fri, 2 Dec 1994 08:02:04 -0800 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 IAA05518; Fri, 2 Dec 1994 08:01:58 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA07269; Fri, 2 Dec 94 08:01:57 -0800 Received: from c209.ucs.usl.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id IAA29986; Fri, 2 Dec 1994 08:01:54 -0800 Received: by c209.ucs.usl.edu id AA26631 (5.65c/IDA-1.4.4 for info-performer@sgi.com); Fri, 2 Dec 1994 10:00:36 -0600 Date: Fri, 2 Dec 1994 10:00:36 -0600 From: Guruswamy Kowsik Message-Id: <199412021600.AA26631@c209.ucs.usl.edu> To: goodhart@cod.nosc.mil, info-performer@sgi.sgi.com Subject: Re: Traverse Question Cc: ling@cod.nosc.mil Status: O Take a look at pfuTraverser, which I think would solve your problem. You can set up preFunc and postFunc in the pfuTraverser structure and calculate whatever you want. You could do this after you load the scene and before you enter the main loop. K. -- Kowsik Guruswamy (kowsik@usl.edu) Home: (318)-232-4718 |I never knew Message-Id: <9412021754.ZM29684@isa.paris.sgi.com> Date: Fri, 2 Dec 1994 17:54:48 +0100 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O please unsubscribe me (ghilde@paris.sgi.com) -- -- Gilles Deghilage -- ghilde@paris.sgi.com M/S IFR340 -- SGI France -- Tel (33) 1 34-88-80-00 V/M 58081 -- Projects Center Manager -- Fax (33) 1 34-88-80-76 From guest Fri Dec 2 09:33:31 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA05654; Fri, 2 Dec 1994 09:14:20 -0800 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 JAA05651; Fri, 2 Dec 1994 09:14:19 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA09205; Fri, 2 Dec 94 09:14:17 -0800 Received: from well.sf.ca.us by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id JAA09716; Fri, 2 Dec 1994 09:14:15 -0800 Received: (from stereo@localhost) by well.sf.ca.us (8.6.9/8.6.9) id JAA18618; Fri, 2 Dec 1994 09:14:00 -0800 Date: Fri, 2 Dec 1994 09:14:00 -0800 From: Amy Marr Message-Id: <199412021714.JAA18618@well.sf.ca.us> To: camiciot@aguirre, info-performer@sgi.sgi.com Subject: Re: 3-D glasses on Indy machine Cc: camiciot@aguirre.ing.unifi.it Status: O >From Tim Crane the following pins for the StereoView Glasses 1-+12VDC, 2-Gnd, 3-L/R signal. There is cable called the X5.P-STVIEW. That is for that purpose and will be compatable with an SGI type emitter. See the following for more info:::: }pKX-P1180}.mt2 .mb3 Tim Crane StereoGraphics Tech Support 2171 E. Francisco Blvd San Rafael CA 94901 415-459-4500 415-455-1844 fax stereo@well.com Attn:Tcrane Revised 8/22/94 C:\PROWIN\UPLOAD\INDY1.TXT revised 10:10AM 10/20/94 I suggest finding some of the resident demo software that the located in the dir : usr/people/4Dgift/examples/devices/StereoView Nested cubes is another good "stereo test" program. It should be a simple plug and play. Also try the setmon command: /usr/gfx/setmon -n STR_RECT to turn on the stereo option. This will elongate the monitor (to 120 Hz refresh rate) the command /usr/gfx/setmon -n 60HZ will turn off the stereo. NOTE: The -n toggle is need so the format will not be saved in EEPROM, and just loaded temporarily. Also there is a program called /usr/demos/bin/powerflip data is located in /usr/demos/data/yaodl/ /usr/demos/bin/powerflip -S /usr/demos/data/yaodl/(data file) will create a stereo image. man powerflip will give you info on that. *************************************** GT and GTX Graphics support 30HZ, 60HZ, NTSC, PAL, and 30HZ_SG. GT and GTX RV2 Graphics support 30HZ, 60HZ, NTSC, PAL, 30HZ_SG 343 and STR_RECT. Run "hinv" to determine hardware ... Run ".usr/gfx/gfxinfo". That should help us out in figuring the revision. The other way is the brute force method; /usr/gfx/setmon -n 60HZ (then return) cut and paste the above command into the mouse cut and paste buffer. type /usr/gfx/setmon -n STR_RECT If the monitor goes crazy or if the monitor can do stereo mode..ta da... if the user can not see what they are doing, have them press the middle mouse button to get the /usr/gfx/setmon -n 60HZ command typed in or have them type it in blind. ****************************************** RED LED INDICATOR The Visible RED LED is a multi purpose indicator. 1) Power. 2) Switch is in HI or LOW. 3) Tells when the Left/Right (stereo 60Hz signal) is present. 4) Phase, brighter in the right eye. Note: All of the first 3 conditions must be met for the light to turn on. ******************************************** p=3 SGI emitter VS PC/PRO emitter The emitters sold through SGI distribution are different from the ones StereoGraphics Corp. sells directly for other computer and or video systems. Although upon a casual look they appear to be the same, they are not! The best way to tell the difference is by looking at the rear panel. The SGI type has only a DB9 connector and a range switch, while the PC/PRO emitter has an additional BNC connector. The two emitters are wired differently on the DB9 and are not directly compatible. The SGI type emitter will ONLY work with SGI computers and cables, the PC/PRO emitter WILL NOT. Do not get them mixed up or you will have problems. Adaptors are available to "rewire the cables" for cases with incompatible emitters. The SGI to PRO (# 82250) is for SGI computer and cable sets going to a PC/PRO emitter, the other is PRO to SGI (# 82249) for other non SGI computers and cables to SGI emitters. See StereoGraphics Corp. for info in them. ************************************************** PSTVIEW-INDY EYEWARE / EMITTER SET The Indy (Blue) EYEWARE / EMITTER SET is not compatible with and other eyeware. They are unique. Blue eyeware units will only work with blue emitters. This set is compatible with any of the Indy,Indigo,Indigo2 and Elan graphics that use the small 3 pin MINI DIN type connector as the STEREO output. From guest Fri Dec 2 09:54:53 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA05696; Fri, 2 Dec 1994 09:37:20 -0800 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 JAA05693; Fri, 2 Dec 1994 09:37:19 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA09818; Fri, 2 Dec 94 09:37:18 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id JAA12793; Fri, 2 Dec 1994 09:37:15 -0800 Received: from hawkeye.newport.sgi.com by sgihub.corp.sgi.com via ESMTP (940519.SGI.8.6.9/911001.SGI) for id JAA08556; Fri, 2 Dec 1994 09:37:14 -0800 Received: by hawkeye.newport.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA14497; Fri, 2 Dec 1994 09:37:10 -0800 From: millard@hawkeye.newport.sgi.com (Ed Millard) Message-Id: <199412021737.JAA14497@hawkeye.newport.sgi.com> Subject: Re: 3-D glasses on Indy machine To: camiciot@aguirre.newport.sgi.com (Riccardo Camiciottoli) Date: Fri, 2 Dec 1994 09:37:09 -0800 (PST) Cc: info-performer@sgi.sgi.com, camiciot@aguirre.ing.unifi.it In-Reply-To: <9412020928.AA11335@ozon180.ing.unifi.it> from "Riccardo Camiciottoli" at Dec 2, 94 10:28:44 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1295 Status: O > > I'm an italian engineering student and I'm trying to install and use the 3-D SEGA glasses on Silicon Graphics > Indy machine. In back side of Indy there is a glasses reserved output. > > 1) Is there someone that can sending me the scheme of the signals from this output port? > > 2) How can I control the double buffering mode in a Performer program to achieve the 3-D > effect with glasses? > 1 +12V +12 Volts DC Output 2 GND Ground - 3 Stereo Stereo Sync Output The stereo sync is TTL and is high when the left eye is on screen. The best choice for stereo on Indy is using the XSGI stereo extensions I posted simple sample code for on this group a couple weeks ago. This works on IRIX 5.2 or later. You would have to figure out how to incorporate the simple sample I sent into Performer. Performer has traditionally only used stereo-in-a-window which only works on RealityEngine and VTX and not Indy. ============================================================================= Ed Millard | 18201 Von Karman Avenue Silicon Graphics Inc. | Suite 100 Developer's Support Group | Irvine, CA 92715 millard@sgi.com | (714) 756-5975 ============================================================================= From guest Fri Dec 2 09:54:55 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA05710; Fri, 2 Dec 1994 09:39:19 -0800 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 JAA05705; Fri, 2 Dec 1994 09:39:06 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA09853; Fri, 2 Dec 94 09:39:01 -0800 Received: from taurus.cs.nps.navy.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id JAA13065; Fri, 2 Dec 1994 09:38:57 -0800 Received: from ac15.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA24296; Fri, 2 Dec 94 09:39:38 PST Date: Fri, 2 Dec 94 09:39:38 PST From: mcdowell@cs.nps.navy.mil (Perry McDowell) Message-Id: <9412021739.AA24296@taurus.cs.nps.navy.mil> To: info-performer Subject: Missing DCS Nodes Cc: king@cs.nps.navy.mil, pratt@cs.nps.navy.mil Status: O Greetings: I am having trouble inputting DCS nodes into my application using MultiGen v14. I create the node I want to be a DCS node as an object and make it the child of a group which is the child of a DOF node in MultiGen. I position the DOF node where I want it, and the axis appears in the correct position. I exercise the DOF and it appears to work correctly in MultiGen. The problem is when I run my application in Performer, the DOF nodes never appear. I have tried attaching them to another group with no other children and moving the DOF to the first node under its parent, but the node doesn't appear in Performer. When I move the DOF node up two levels higher in the hierarchy, it will appear, but if I put it only one level up in the hierarchy, it still is not visible. Also, if I put all the DOF nodes at the same level the first is visible at, only half of them are visible. I can't understand why the DOF's are apparently getting culled, since everything else at that level is in the same area and is appearing correctly. If I go into the DOF's attributes and enter the location where I want the door, MultiGen puts it out in the middle of nowhere. I have used DOF's in a smaller application and didn't have this problem. However, in looking back at my earlier application to try and solve this problem, I notice that while the DOF nodes rotate correctly in Performer they rotate completely wrong in MultiGen. (They are doors and they rotate about a point ~5m away from the edge, while in Performer they rotate about an axis through the edge.) Any help would be greatly appreciated. Information: MultiGen v14 Performer 1.2 Running on 4 processor ONYX RE2 Perry McDowell mcdowell@cs.nps.navy.mil From guest Fri Dec 2 09:59:39 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA05721; Fri, 2 Dec 1994 09:40:53 -0800 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 JAA05718; Fri, 2 Dec 1994 09:40:53 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA09944; Fri, 2 Dec 94 09:40:50 -0800 Received: from VNET.IBM.COM by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id JAA13276; Fri, 2 Dec 1994 09:40:45 -0800 From: hodeckes@VNET.IBM.COM Message-Id: <199412021740.JAA13276@sgi.sgi.com> Received: from OWGVM6 by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 7329; Fri, 02 Dec 94 12:39:59 EST Date: Fri, 2 Dec 94 12:40:35 EST To: INFO-PERFORMER@sgi.sgi.com Subject: path in scene Status: O Hello, I am running Perf1.2 on an Onyx w/RE and IRIX 5.2 I notice an unusual growth of the paths when I print out my scene hierarchy using pfPrint. Each time a path field is listed for a group, /usr/people/joe/dwbfiles is appended to the beginning of the path. After a few instances, this field starts getting huge and causes problems. I use LoadFile to read in a dwb file and then clone the node into multiple SCSs. Exactly what does this path field refer to? What sets this path and modifies it. Here is an entry from my scene pfPrint. [4:0]pfGroup pfId=66 0x1827dd30 { path: //usr/people/joe/dwbfiles//usr/people/joe/dwbfiles//usr/peopl e/joe/dwbfiles//usr/people/joe/dwbfiles//usr/people/joe/dwbfiles//u sr/people/joe/dwbfiles//usr/people/joe/dwbfiles/modelfile.dwb trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff bsphere: ctr(-0.048517, 0.000000, 0.384121) rad=58.055885 Num Children: 1 Thanks, ---------------------------------------------------------------------- Steve Hodecker Phone: (607) 751-3624 Systems Engineer Email: hodeckes@lfs.loral.com Loral Federal Systems - Owego Fax: (607) 751-2260 ---------------------------------------------------------------------- From guest Fri Dec 2 11:25:14 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA05953; Fri, 2 Dec 1994 11:08:31 -0800 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 LAA05950; Fri, 2 Dec 1994 11:08:30 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA13391; Fri, 2 Dec 94 11:08:29 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id LAA03467; Fri, 2 Dec 1994 11:08:26 -0800 Received: from crusader.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA08157; Fri, 2 Dec 94 14:09:08 EST Received: by crusader.vsl.ist.ucf.edu (920330.SGI) id AA08840; Fri, 2 Dec 94 14:08:27 -0500 Date: Fri, 2 Dec 1994 14:08:26 -0500 (EST) From: "Lance R. Marrou" To: aaron@paradigmsim.com Cc: "Curtis L. Goodhart" , info-performer@sgi.sgi.com Subject: Re: Traverse Question In-Reply-To: <9412020601.AA22270@qbert.paradigmsim.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Fri, 2 Dec 1994, Aaron Hightower wrote: ... > Another way you could do stuff per frame is to install node callbacks. > Check out the man page on pfNodeTravFuncs for information on this. The > short story is that this allows you to call one of your functions from > the cull, draw or intersection process if you need to do so. It will > pass the data for the node to your function when and if the > cull/draw/isect process encounters the given node that has a callback > installed. You'll still want to use the above function to actually > find the nodes in the scene graph so that you can install the callbacks > on them. ... Your code looked good, though the new pfuTraverser, as mentioned below by Kowsik Guruswamy does the same thing, and allows for ready-to-use simple options (see the man page). I just wanted to point out that using the draw and/or cull callbacks for some node processing could seriously hurt the performance. Unless you really need to be in the draw process or the cull process you probably should refrain from doing application processing there. Furthermore, you cannot access the full scene graph in the draw process (if you need it). Of course, in MP_APPCULLDRAW, it doesn't matter. Kowsik Guruswamy wrote: >Take a look at pfuTraverser, which I think would solve your problem. > >You can set up preFunc and postFunc in the pfuTraverser structure and >calculate whatever you want. You could do this after you load the scene >and before you enter the main loop. _______________________________________________________ IST __ E-mail: marrou@vsl.ist.ucf.edu Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Fri Dec 2 14:33:52 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA06869; Fri, 2 Dec 1994 14:16:10 -0800 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 OAA06866; Fri, 2 Dec 1994 14:16:09 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19675; Fri, 2 Dec 94 14:15:50 -0800 Received: from relay1.UU.NET by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id OAA29437; Fri, 2 Dec 1994 14:15:44 -0800 Received: from uucp5.UU.NET by relay1.UU.NET with SMTP id QQxspc20808; Fri, 2 Dec 1994 17:14:43 -0500 Received: from multigen.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Fri, 2 Dec 1994 17:15:22 -0500 Received: from MAIL_CENTER (QM 3.0) by multigenuunet.UU.NET (UMCP\QM 2.0.1) id AA00391; Fri, 2 Dec 1994 15:18:26 PST Message-Id: <00581.2869226306.391@multigenuunet.UU.NET> Organization: MultiGen, Inc. X-Charset: MACINTOSH X-Umcp-Priority: 1 X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Fri, 2 Dec 1994 15:13:55 PST Subject: Re: Missing DCS Nodes Status: O Reply to: RE>Missing DCS Nodes >Date: Fri, 2 Dec 94 09:39:38 PST >From: mcdowell@cs.nps.navy.mil (Perry McDowell) >Message-Id: <9412021739.AA24296@taurus.cs.nps.navy.mil> >To: info-performer@holodeck.asd.sgi.com >Subject: Missing DCS Nodes >Cc: king@cs.nps.navy.mil, pratt@cs.nps.navy.mil > >Greetings: > >I am having trouble inputting DCS nodes into my application using >MultiGen v14. I create the node I want to be a DCS node as an object >and make it the child of a group which is the child of a DOF node in >MultiGen. I position the DOF node where I want it, and the axis >appears in the correct position. I exercise the DOF and it appears to >work correctly in MultiGen. This a bit confusing to me. A DOF bead is translated into a pfDCS node by the OpenFlight loader. An object bead is translated into a pfGroup plus pfGeode, pfBillboard, and pfLightPoint children as appropriate. I gather that you're expecting to somehow convert the object bead into a pfDCS node? >The problem is when I run my application in Performer, the DOF nodes >never appear. There are no "DOF nodes" in the Performer scene graph. I assume you mean that the geometry under the DOF bead isn't drawn.? >I have tried attaching them to another group with no other children >and moving the DOF to the first node under its parent, but the node >doesn't appear in Performer. When I move the DOF node up two levels >higher in the hierarchy, it will appear, but if I put it only one level up >in the hierarchy, it still is not visible. Also, if I put all the DOF nodes >at the same level the first is visible at, only half of them are visible. Uhm ... so you're using MultiGen to shuffle the hierarchy around in order to figure out what's wrong? Ok. Be aware that the OpenFlight loader does three kinds of post process editing on the generated scene graph before returning the root node to you. These actions can be enabled/disabled via LoadFltMode() described in the readme file /usr/src/Performer/src/lib/libpfflt/README.V14. The actions are: PFFLT_COMBINELODS: It combines logically related LOD beads into single pfLOD nodes. PFFLT_FLATTEN: It calls pfFlatten() to apply all the static transforms represented by pfSCS nodes (group beads with [TRSM] matrices). PFFLT_CLEAN: Lastly, it removes all redundant pfGroups and pfSCS (identity matrices after pfFlatten) nodes. Singleton hierarchies, like you seem to describe above, will be simplified to a top level pfGroup with pfGeode (leaf node) children. The pfGroup created in place of the object bead (your DCS?) will be deleted. You should disable PFFLT_CLEAN and PFFLT_FLATTEN to see if the pfNodes you're interested in are being deleted. Also, it's very possible that you're running into a bug in pfFlatten(). By default the loader calls pfFlatten() when it's finished translating the .flt file. Here's how I described the bug to John Rohlf last September: =============begin excerpt====================== From: Marcus (9/2/94) To: John Rohlf CC: Allan Schaffer Reply to: pfFlatten bug? Dear Mr. Rohlf, What follows is a dialog we've had with a customer concerning a problem loading his .flt files into Performer v1.2. I've isolated the problem to the actions of pfFlatten. It apparently fails to apply a parent SCS transform to the sibling of a child DCS node (see MultiGen hierarchy below). I've enclosed 2 sample .flt files that show the problem. They should both display the same thing, but they don't. One is OK, the other is broken by pfFlatten. Perhaps this is a known Performer bug? Please let me know if you need more information, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4118 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET -------------------------------------- Date: 9/2/94 4:02 PM From: Marcus More info for you and Keith: The problem with pfFlatten is that right hand siblings of a pfDCS (DOF), which has a pfSCS (group [TRSP]) above it, will be affected by the pfDCS. MultiGen hierarchy (pfFlatten breaks it) /--------\ | g1 | | [T] | \--------/ |____________ | | /--------\ /--------\ ----> After pfFlatten, o1 is affected | d1 | | o1 | by d1, because of the transform | | | | immediately above d1. This \--------/ \--------/ shouldn't be. As a workaround have Keith and others model this way: MultiGen hierarchy (pfFlatten does NOT break it) /--------\ | g1 | | [T] | \--------/ |____________ | | /--------\ /--------\ | g2 | | o1 | | | | | \--------/ \--------/ | /--------\ -----> Any siblings here may be affected by d1 | d1 | after pfFlatten is done! So don't do it. | | \--------/ I'll be reporting this pfFlatten bug to the Performer Group. Regards, Marcus =============end excerpt====================== >I can't understand why the DOF's are apparently getting culled, since >everything else at that level is in the same area and is appearing >correctly. If I go into the DOF's attributes and enter the location >where I want the door, MultiGen puts it out in the middle of nowhere. DOF beads represent a local coordinate system which is usually different from the database's. Entering database coordinates in DOF attributes can easily place it outside the field of view. Apply your put tranformation to the external reference or the DOF bead's parent group, whichever. >I have used DOF's in a smaller application and didn't have this problem. >However, in looking back at my earlier application to try and solve this >problem, I notice that while the DOF nodes rotate correctly in Performer >they rotate completely wrong in MultiGen. (They are doors and they >rotate about a point ~5m away from the edge, while in Performer they >rotate about an axis through the edge.) Updating a pfDCS node, derived from DOF bead, in Performer requires the information provided by the OpenFlight loader callback for DOF beads. The loader calculates the put and inverse put matrices that are needed to enter and exit the DOF local coordinate system within which the DOF transformations are meaningfull. The pfDCS in the scene graph is only updated via pfDCSMat() with the resultant matrix, not via direct multiplication. I have a basic demo program and database that illustrates this concept that I can send you. > Any help would be greatly appreciated. > >Perry McDowell >mcdowell@cs.nps.navy.mil Please feel free to contact me directly for more help on this subject. Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4118 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Sat Dec 3 02:03:52 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA08395; Sat, 3 Dec 1994 01:35:19 -0800 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 BAA08392; Sat, 3 Dec 1994 01:35:02 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA01667; Sat, 3 Dec 94 01:34:53 -0800 Received: from INGFI1.ING.UNIFI.IT by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id BAA27926; Sat, 3 Dec 1994 01:34:51 -0800 Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Sat, 3 Dec 1994 10:32:22 +0200 (MET) Received: from hobbit.ing.unifi.it by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA03699; Sat, 3 Dec 94 10:28:34 +0100 Received: by hobbit.ing.unifi.it (5.0/SMI-SVR4) id AA05778; Sat, 3 Dec 1994 10:28:36 +0100 Date: Sat, 3 Dec 1994 10:28:36 +0100 From: camiciot@aguirre (Riccardo Camiciottoli) Message-Id: <9412030928.AA05778@hobbit.ing.unifi.it> To: millard@hawkeye.newport.sgi.com Subject: 3-D glasses on Indy Cc: camiciot@aguirre.ing.unifi.it, info-performer@sgi.sgi.com X-Sun-Charset: US-ASCII Content-Length: 1653 Status: O >> I'm an italian engineering student and I'm trying to install and use the 3-D SEGA glasses on Silicon Graphics >> Indy machine. In back side of Indy there is a glasses reserved output. >> >> 1) Is there someone that can sending me the scheme of the signals from this output port? >> >> 2) How can I control the double buffering mode in a Performer program to achieve the 3-D >> effect with glasses? >> > > 1 +12V +12 Volts DC Output > 2 GND Ground - > 3 Stereo Stereo Sync Output > >The stereo sync is TTL and is high when the left eye is on screen. > >The best choice for stereo on Indy is using the XSGI stereo extensions >I posted simple sample code for on this group a couple weeks ago. This >works on IRIX 5.2 or later. You would have to figure out how to >incorporate the simple sample I sent into Performer. Performer has >traditionally only used stereo-in-a-window which only works on >RealityEngine and VTX and not Indy. Thanks for your reply. I've three question about it, yet. Can you send me the exact layout of the pins 1, 2 and 3 of the Indy's output port? You said stereo sync is TTL and is high when the left eye is on screen; well, that means the output is a square wave, high (~3.5 Volts) when the left eye is on screen, low (~0.2 Volts) otherwise, and I must construct a circuit that generates another square wave with a T/2 delay for the right eye. Is it right or wrong? Would you mind sending me a copy of the article you posted weeks ago? Thanks in advance. Riccardo Camiciottoli Universita' di Firenze Facolta' di Ingegneria Dipartimento di Sistemi e Informatica. email: camiciot@aguirre.ing.unifi.it From guest Sun Dec 4 19:51:14 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA10211; Sun, 4 Dec 1994 19:27:17 -0800 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 TAA10208; Sun, 4 Dec 1994 19:27:13 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA20699; Sun, 4 Dec 94 19:27:12 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id TAA04587; Sun, 4 Dec 1994 19:27:09 -0800 Received: from sgitokyo.nsg.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for id TAA03518; Sun, 4 Dec 1994 19:27:06 -0800 Received: from dimwit.dst.nk-exa.co.jp by sgitokyo.nsg.sgi.com via UUCP (931110.SGI.ANONFTP/911001.SGI) for info-performer@sgi.sgi.com id AA02548; Mon, 5 Dec 94 12:26:56 +0900 Received: from dimwit.dst.nk-exa.co.jp by exagw.nk-exa.co.jp (4.1/6.4J.6-1.17) id AA01356; Mon, 5 Dec 94 11:46:53 JST Received: from localhost.dst.nk-exa.co.jp by dimwit.dst.nk-exa.co.jp via SMTP (931110.SGI/930416.SGI.AUTO) for @exagw.nk-exa.co.jp:info-performer@sgi.sgi.com id AA06286; Mon, 5 Dec 94 11:47:50 +0900 To: info-performer@sgi.sgi.com Subject: speed @pfSeqDuration() Date: Mon, 05 Dec 1994 11:47:41 +0900 Message-Id: <6285.786595661@dimwit.dst.nk-exa.co.jp> From: Masahiko Yamanaka Status: O Hello, I'm using Performer1.2. I have a question. What's the meaning of speed factor in pfSeqDuration() ? I thought, for example, if I use pfSeqDuration( seq, 0.5, -1 ), the term of display for one shape inclase. I tried to set it to 1.5, or 0.5. But It didn't seem effective. How do I use it ? -- Masahiko Yamanaka From guest Mon Dec 5 07:19:06 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA11764; Mon, 5 Dec 1994 06:59:09 -0800 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 GAA11761; Mon, 5 Dec 1994 06:59:07 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA29174; Mon, 5 Dec 94 06:58:53 -0800 Received: from post.demon.co.uk by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id GAA02537; Mon, 5 Dec 1994 06:58:49 -0800 Received: from division.demon.co.uk by post.demon.co.uk id ab03657; 5 Dec 94 14:26 GMT Received: from ariel.division.demon.co.uk by division.demon.co.uk (AIX 3.2/UCB 5.64/4.03) id AA18442; Mon, 5 Dec 1994 14:16:38 GMT Received: by ariel.division.demon.co.uk (931110.SGI/921111.SGI) for @division.demon.co.uk:info-performer@holodeck.asd.sgi.com id AA07578; Mon, 5 Dec 94 14:16:37 GMT From: Angus Dorbie uid Message-Id: <9412051416.ZM7576@ariel.division.demon.co.uk> Date: Mon, 5 Dec 1994 14:16:36 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer Subject: Performer PFSTATE_CULLFACE Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O The state mode PFSTATE_CULLFACE links front face and back face culling to the one state variable. I would like to apply overrides to these states independently to match some material attribute overrides which I intend applying independently. Is there an existing or planned mechanism for overriding these properties independently? Thanks, -- ________________________________________________ Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.demon.co.uk UK ________________________________________________ From guest Mon Dec 5 09:03:08 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA11910; Mon, 5 Dec 1994 08:47:01 -0800 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 IAA11907; Mon, 5 Dec 1994 08:46:53 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA01200; Mon, 5 Dec 94 08:46:51 -0800 Received: from well.sf.ca.us by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) id IAA11918; Mon, 5 Dec 1994 08:46:49 -0800 Received: (from stereo@localhost) by well.sf.ca.us (8.6.9/8.6.9) id IAA07313; Mon, 5 Dec 1994 08:46:39 -0800 Date: Mon, 5 Dec 1994 08:46:39 -0800 From: Amy Marr Message-Id: <199412051646.IAA07313@well.sf.ca.us> To: camiciot@aguirre, millard@hawkeye.newport.sgi.com Subject: Re: 3-D glasses on Indy Cc: camiciot@aguirre.ing.unifi.it, info-performer@sgi.sgi.com Status: O Tim Crane StereoGraphics Tech Support 2171 E. Francisco Blvd San Rafael CA 94901 415-459-4500 415-455-1844 fax stereo@well.com Attn:Tcrane No the infarred emitter will use the TTL square wave just as it is. When is sees a high it tell the glasses to turn on the left eye, when it sees a low it tells the glasses to turn the right eye. If you give me a fax # I can send a wiring diagram. ************************** ************************* Tim Crane StereoGraphics Tech Support 2171 E. Francisco Blvd San Rafael CA 94901 415-459-4500 415-455-1844 fax stereo@well.com Attn:Tcrane Revised 8/22/94 INDY1.TXT revised 10:10AM 10/20/94 I suggest finding some of the resident demo software that the located in the dir : usr/people/4Dgift/examples/devices/StereoView Nested cubes is another good "stereo test" program. It should be a simple plug and play. Also try the setmon command: /usr/gfx/setmon -n STR_RECT to turn on the stereo option. This will elongate the monitor (to 120 Hz refresh rate) the command /usr/gfx/setmon -n 60HZ will turn off the stereo. NOTE: The -n toggle is need so the format will not be saved in EEPROM, and just loaded temporarily. Also there is a program called /usr/demos/bin/powerflip data is located in /usr/demos/data/yaodl/ /usr/demos/bin/powerflip -S /usr/demos/data/yaodl/(data file) will create a stereo image. man powerflip will give you info on that. *************************************** GT and GTX Graphics support 30HZ, 60HZ, NTSC, PAL, and 30HZ_SG. GT and GTX RV2 Graphics support 30HZ, 60HZ, NTSC, PAL, 30HZ_SG 343 and STR_RECT. Run "hinv" to determine hardware ... Run ".usr/gfx/gfxinfo". That should help us out in figuring the revision. The other way is the brute force method; /usr/gfx/setmon -n 60HZ (then return) cut and paste the above command into the mouse cut and paste buffer. type /usr/gfx/setmon -n STR_RECT If the monitor goes crazy or if the monitor can do stereo mode..ta da... if the user can not see what they are doing, have them press the middle mouse button to get the /usr/gfx/setmon -n 60HZ command typed in or have them type it in blind. ****************************************** RED LED INDICATOR The Visible RED LED is a multi purpose indicator. 1) Power. 2) Switch is in HI or LOW. 3) Tells when the Left/Right (stereo 60Hz signal) is present. 4) Phase, brighter in the right eye. Note: All of the first 3 conditions must be met for the light to turn on. ******************************************** SGI emitter VS PC/PRO emitter The emitters sold through SGI distribution are different from the ones StereoGraphics Corp. sells directly for other computer and or video systems. Although upon a casual look they appear to be the same, they are not! The best way to tell the difference is by looking at the rear panel. The SGI type has only a DB9 connector and a range switch, while the PC/PRO emitter has an additional BNC connector. The two emitters are wired differently on the DB9 and are not directly compatible. The SGI type emitter will ONLY work with SGI computers and cables, the PC/PRO emitter WILL NOT. Do not get them mixed up or you will have problems. Adaptors are available to "rewire the cables" for cases with incompatible emitters. The SGI to PRO (# 82250) is for SGI computer and cable sets going to a PC/PRO emitter, the other is PRO to SGI (# 82249) for other non SGI computers and cables to SGI emitters. See StereoGraphics Corp. for info in them. ************************************************** PSTVIEW-INDY EYEWARE / EMITTER SET The Indy (Blue) EYEWARE / EMITTER SET is not compatible with and other eyeware. They are unique. Blue eyeware units will only work with blue emitters. This set is compatible with any of the Indy,Indigo,Indigo2 and Elan graphics that use the small 3 pin MINI DIN type connector as the STEREO output. From guest Mon Dec 5 10:01:05 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA12037; Mon, 5 Dec 1994 09:39:58 -0800 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 JAA12034; Mon, 5 Dec 1994 09:39:57 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA02976; Mon, 5 Dec 94 09:39:48 -0800 Received: from hssiarl.hti.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id JAA18518; Mon, 5 Dec 1994 09:39:38 -0800 Received: from [192.27.12.102] by hssiarl.hti.com (5.65/1.35) id AA23445; Mon, 5 Dec 94 11:39:21 -0600 Received: by mred (920330.SGI/LAI-3.1) id AA16483; Mon, 5 Dec 94 11:36:54 -0600 Date: Mon, 5 Dec 94 11:36:54 -0600 From: steve@mred.hti.com (Steve Baker) Message-Id: <9412051736.AA16483@mred > To: info-performer Subject: Re: Performer PFSTATE_CULLFACE Status: O Angus Dorbie said... > The state mode PFSTATE_CULLFACE links front face and back face culling to the > one state variable. I would like to apply overrides to these states > independently to match some material attribute overrides which I intend > applying independently. Is there an existing or planned mechanism for > overriding these properties independently? IMHO - I feel that face culling should be taken out of the GeoState altogether and placed in the GeoSet. It's a real pain having to make two different versions of a GeoState for (say) a brick material because it is to be used on the exterior of a building and on both sides of a wall. Face culling is typically used to alter the polygonal geometry of a polygon (ie either single or double-sided) and that has little or nothing to do with the material/texture/colour properties of the GeoState. Perhaps pfCullFace should be applicable to either GeoState or GeoSet: either like a pfHighlight where the property becomes a property of the GeoSet itself, or perhaps by having a different primitive type for a double-sided (ie PFCF_OFF) triangle mesh. Steve Baker. ===================================================================== Steve Baker Hughes Training Inc. 2200 Arlington Downs Road Arlington, Texas. TX 76005-6171 steve@mred.hti.com (Email) 817-695-2478 (Voice) 817-695-2555 (Fax) ===================================================================== From guest Mon Dec 5 10:13:58 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA12078; Mon, 5 Dec 1994 09:51:13 -0800 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 JAA12075; Mon, 5 Dec 1994 09:51:08 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03477; Mon, 5 Dec 94 09:51:07 -0800 Received: from sgidev.mdc.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id JAA20097; Mon, 5 Dec 1994 09:51:04 -0800 Received: by sgidev.mdc.com (920213.SGI.UNSUPPORTED.PROTOTYPE/920323.SGI.UNSUPPORTED.PROTOTYPE) for info-performer@sgi.com id AA08091; Mon, 5 Dec 94 09:09:48 -0800 Date: Mon, 5 Dec 94 09:09:48 -0800 From: sal@sgidev.mdc.com (Sal Cabaruvias) Message-Id: <9412051709.AA08091@sgidev.mdc.com> To: info-performer@sgi.sgi.com Subject: pfFrust Questions Status: O To: info-performer@sgi.com Subject: pfFrust Questions ---text follows this line--- Hi, I'm new to Performer. We are running Performer 1.2 on Onyx with 6 cpus and 2 graphic pipes with 2 RM5s per pipe. We are using the Onyx to be our OTW image generator for our C17 simulator. The setup is a 2 channel system with the pilot and copilot sharing the same front channel and the pilot having a separate side view channel. We are using a wide angle collimated optics (WACO) system with the pilot side having zero gap mirrors for his front and side views (two channels). Now for my question: The WACO system has 45 degrees HFOV (hortizontal fiew of view) and 36 VFOV (vertical fiew of view). In addition, there is a 3 degree pitch in the VFOV to provide more down view angle. Using the pfMakeSimpleFrust and pfChanViewOffsets, I can setup the two channels but I can't account for the 3 degs of pitch. The way it's explained to me, is that 36 VFOV is +25 from the center and -31 down. Using the pfChanViewOffsets to add in the 3 degs simply makes a side window that is pitched down 3 degrees. This is not the affect I want. I want the window to stay at the original center line but with more down viewing angle. This is critical since we are using a real HUD. When we on the runway, the horizon is not where it should be when viewing thru the HUD with/out the 3 degs using the pfChanViewOffsets command. Has anyone done this before? Would you mind pointing me in the right direction? What are the calculations/calls I need to get this to align up? Thanks in advance, sal ----------------------------------------------------------------------------- Salvador Cabaruvias |email: sal@sgidev.mdc.com CSSL |saying: "Well I be done seen about McDonnell Douglas | everything when I see elephant (310) 593-6719 | fly!" --- Dumbo --- ----------------------------------------------------------------------------- From guest Mon Dec 5 14:38:14 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA12701; Mon, 5 Dec 1994 14:20:27 -0800 Return-Path: Received: from tubes.asd.sgi.com by holodeck.asd.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA12695; Mon, 5 Dec 1994 14:20:26 -0800 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA12306; Mon, 5 Dec 1994 14:18:51 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <199412052218.OAA12306@tubes.asd.sgi.com> Subject: Re: Performer PFSTATE_CULLFACE To: guest (Steve Baker) Date: Mon, 5 Dec 94 14:18:51 PST Cc: info-performer In-Reply-To: <9412051736.AA16483@mred >; from "Steve Baker" at Dec 5, 94 11:36 am X-Mailer: ELM [version 2.3 PL8] Status: O > > Angus Dorbie said... > > > The state mode PFSTATE_CULLFACE links front face and back face culling to the > > one state variable. I would like to apply overrides to these states > > independently to match some material attribute overrides which I intend > > applying independently. Is there an existing or planned mechanism for > > overriding these properties independently? > > IMHO - I feel that face culling should be taken out of the GeoState altogether > and placed in the GeoSet. It's a real pain having to make two different versions > of a GeoState for (say) a brick material because it is to be used on the exterior > of a building and on both sides of a wall. Face culling is typically used to > alter the polygonal geometry of a polygon (ie either single or double-sided) and > that has little or nothing to do with the material/texture/colour properties of > the GeoState. > > Perhaps pfCullFace should be applicable to either GeoState or GeoSet: either > like a pfHighlight where the property becomes a property of the GeoSet itself, > or perhaps by having a different primitive type for a double-sided (ie PFCF_OFF) > triangle mesh. If pfCullFace() were strictly a pfGeoSet mode, then there would be no other Performer mechanism to set the face culling mode and Performer would be unable to track the face culling mode. Consequently, pfCullFace() must be exposed and it follows that it should be a pfGeoState mode since all libpr state may be set in a pfGeoState. However, it makes some sense for pfGeoSets to support pfCullFace - we already have a precedent in pfShadeModel. Angus, would this solve your problem? From guest Mon Dec 5 15:17:52 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA12837; Mon, 5 Dec 1994 14:59:17 -0800 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 OAA12834; Mon, 5 Dec 1994 14:59:16 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA16501; Mon, 5 Dec 94 14:59:14 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id OAA10887; Mon, 5 Dec 1994 14:59:12 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for id OAA08316; Mon, 5 Dec 1994 14:59:11 -0800 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@sgi.sgi.com id AA16497; Mon, 5 Dec 94 14:59:10 -0800 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA14511; Mon, 5 Dec 1994 14:57:35 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <199412052257.OAA14511@tubes.asd.sgi.com> Subject: Re: pfFrust Questions To: guest (Sal Cabaruvias) Date: Mon, 5 Dec 94 14:57:34 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9412051709.AA08091@sgidev.mdc.com>; from "Sal Cabaruvias" at Dec 5, 94 9:09 am X-Mailer: ELM [version 2.3 PL8] Status: O > > To: info-performer@sgi.com > Subject: pfFrust Questions > ---text follows this line--- > Hi, I'm new to Performer. We are running Performer 1.2 on Onyx with 6 cpus > and 2 graphic pipes with 2 RM5s per pipe. We are using the Onyx to be our OTW > image generator for our C17 simulator. > > The setup is a 2 channel system with the pilot and copilot sharing the same > front channel and the pilot having a separate side view channel. We are > using a wide angle collimated optics (WACO) system with the pilot side having > zero gap mirrors for his front and side views (two channels). > > Now for my question: > > The WACO system has 45 degrees HFOV (hortizontal fiew of view) and 36 VFOV > (vertical fiew of view). In addition, there is a 3 degree pitch in the > VFOV to provide more down view angle. > > Using the pfMakeSimpleFrust and pfChanViewOffsets, I can setup the two > channels but I can't account for the 3 degs of pitch. The way it's explained > to me, is that 36 VFOV is +25 from the center and -31 down. Using the > pfChanViewOffsets to add in the 3 degs simply makes a side window that is > pitched down 3 degrees. This is not the affect I want. I want the window > to stay at the original center line but with more down viewing angle. This > is critical since we are using a real HUD. When we on the runway, the horizon > is not where it should be when viewing thru the HUD with/out the 3 degs > using the pfChanViewOffsets command. > > > Has anyone done this before? Would you mind pointing me in the right > direction? What are the calculations/calls I need to get this to align up? > > Thanks in advance, > > sal > > > > ----------------------------------------------------------------------------- > Salvador Cabaruvias |email: sal@sgidev.mdc.com > CSSL |saying: "Well I be done seen about > McDonnell Douglas | everything when I see elephant > (310) 593-6719 | fly!" --- Dumbo --- > ----------------------------------------------------------------------------- > > Try this: pfFrustAspect(chan, PFFRUST_CALC_NONE); /* Needed to workaround a bug*/ pfChanAutoAspect(chan, PFFRUST_CALC_NONE); pfFrustNearFar(chan, near, far); pfMakePerspFrust(chan, -near * pfTan(22.5f), /* left */ near * pfTan(22.5f), /* right */ -near * pfTan(25.0f), /* bottom */ near * pfTan(31.0f)); /* top */ From guest Tue Dec 6 04:30:11 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id EAA14398; Tue, 6 Dec 1994 04:02:41 -0800 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 EAA14395; Tue, 6 Dec 1994 04:02:36 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03248; Tue, 6 Dec 94 04:02:25 -0800 Received: from post.demon.co.uk by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id EAA18353; Tue, 6 Dec 1994 04:02:20 -0800 Received: from division.demon.co.uk by post.demon.co.uk id aa13304; 6 Dec 94 12:02 GMT Received: from ariel.division.demon.co.uk by division.demon.co.uk (AIX 3.2/UCB 5.64/4.03) id AA12439; Tue, 6 Dec 1994 10:20:19 GMT Received: by ariel.division.demon.co.uk (931110.SGI/921111.SGI) for @division.demon.co.uk:info-performer@holodeck.asd.sgi.com id AA09753; Tue, 6 Dec 94 10:20:18 GMT From: Angus Dorbie uid Message-Id: <9412061020.ZM9751@ariel.division.demon.co.uk> Date: Tue, 6 Dec 1994 10:20:17 +0000 In-Reply-To: John Rohlf "Re: Performer PFSTATE_CULLFACE" (Dec 5, 2:18pm) References: <199412052218.OAA12306@tubes.asd.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: jrohlf@tubes Subject: Re: Performer PFSTATE_CULLFACE Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > However, it makes some sense for pfGeoSets to support > pfCullFace - we already have a precedent in pfShadeModel. > Angus, would this solve your problem? Thanks for the suggestion John. Unfortunately support for culling at the geoset level wouldn't help. My problem is that I can have polygons with arbitrary face culling via the application of different geostates at my leaf nodes. I then apply front and/or back material overrides at a common node above them using draw callbacks, (the leaf information may be instanced many times), however when I apply the override to a particular face, let's say the front, I would like my cull override to disable front face culling independently of the back face culling so that this can still be determined by the geostates being applied. At the moment I can't do this because the two culls are associated with the one state variable. When I override one I must override the other. At this point I'm thinking of changing my spec' so that an override of front or back implies an override both (culled if no material is specified), unless there is a workaround which doesn't involve _lots_ of callbacks. -- ________________________________________________ Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.demon.co.uk UK ________________________________________________ From guest Tue Dec 6 18:20:58 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA17110; Tue, 6 Dec 1994 18:02:48 -0800 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 SAA17107; Tue, 6 Dec 1994 18:02:47 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA29884; Tue, 6 Dec 94 18:02:46 -0800 Received: from gate.demon.co.uk by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id SAA09546; Tue, 6 Dec 1994 18:02:42 -0800 Received: from division.demon.co.uk by gate.demon.co.uk id aa21923; 7 Dec 94 2:01 GMT Received: from ariel.division.demon.co.uk by division.demon.co.uk (AIX 3.2/UCB 5.64/4.03) id AA15690; Wed, 7 Dec 1994 02:10:36 GMT Received: by ariel.division.demon.co.uk (931110.SGI/921111.SGI) for @division.demon.co.uk:info-performer@sgi.com id AA13061; Wed, 7 Dec 94 02:10:35 GMT From: Angus Dorbie uid Message-Id: <9412070210.ZM13059@ariel.division.demon.co.uk> Date: Wed, 7 Dec 1994 02:10:34 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfMaterial Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O In my last email I said I intended to override back and front materials independently. As always front material overrides work, but after some trial and error I can't override the back facing material. I've guessed this is a result of the documented limitations of the Iris GL call lmcolor(). I've tried both the default pfMtlColorMode() setting on my materials and PFMTL_CMODE_COLOR applied to PFMTL_BOTH surfaces. I need PFMTL_CMODE_COL for material transparency, which has the side effect of disabling colour per primitive information on some triangular meshes I create. This is understandable but frustrating because of its requirement for transparent materials. A mode where alpha is applied from the material and diffuse & ambient from lmcolor would be handy. Is there a known workaround for my material override, or colour per primitive with transparent material problems, or have I miss-diagnosed the symptoms? Also, would it be possible for someone to elaborate on what performer is doing with materials in "Iris GL speak" to assist my understanding? I've tried to glean this information from the manuals but in some respects it's not clear what's supposed to be happening under there. Thanks in advance, -- ________________________________________________ Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.demon.co.uk UK ________________________________________________ From guest Wed Dec 7 03:26:17 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA20144; Wed, 7 Dec 1994 02:59:23 -0800 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 CAA20141; Wed, 7 Dec 1994 02:59:14 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA08279; Wed, 7 Dec 94 02:59:08 -0800 Received: from gate.demon.co.uk by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id CAA19762; Wed, 7 Dec 1994 02:59:05 -0800 Received: from division.demon.co.uk by gate.demon.co.uk id aa29101; 7 Dec 94 10:54 GMT Received: from ariel.division.demon.co.uk by division.demon.co.uk (AIX 3.2/UCB 5.64/4.03) id AA16103; Wed, 7 Dec 1994 11:04:29 GMT Received: by ariel.division.demon.co.uk (931110.SGI/921111.SGI) for @division.demon.co.uk:info-performer@sgi.com id AA13819; Wed, 7 Dec 94 11:04:28 GMT From: Angus Dorbie uid Message-Id: <9412071104.ZM13817@ariel.division.demon.co.uk> Date: Wed, 7 Dec 1994 11:04:27 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: follow up to pfMaterial questions Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Looking at my material problem with fresh eyes this morning I've realised that I need to use a pfMtlSide call before my pfApplyMtl call. It also appears to only affect the sides a material is applied to with pfApplyMtl not the sides in a geostate which a material may be applied to. This clears up a few things for me, although pfApplyFrontMtl & pfApplyBackMtl would probably make my code look cleaner, and help IrisGL hacks. I would still welcome any suggestions on the per primitive colouring with transparent materials problem I mentioned. Thanks, -- ________________________________________________ Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.demon.co.uk UK ________________________________________________ From guest Wed Dec 7 05:49:25 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA20260; Wed, 7 Dec 1994 05:23:35 -0800 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 FAA20257; Wed, 7 Dec 1994 05:23:34 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA10577; Wed, 7 Dec 94 05:23:31 -0800 Received: from davinci.eng.buffalo.edu by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id FAA25782; Wed, 7 Dec 1994 05:23:28 -0800 Received: (prabhu@localhost) by davinci.eng.buffalo.edu (8.6.7/8.6.4) id IAA04851 for info-performer@sgi.com; Wed, 7 Dec 1994 08:23:10 -0500 Date: Wed, 7 Dec 1994 08:23:10 -0500 From: girish prabhu Message-Id: <199412071323.IAA04851@davinci.eng.buffalo.edu> To: info-performer@sgi.sgi.com Status: O Hi: Can you please unscribe me for time being Thanks From guest Thu Dec 8 14:59:44 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA28020; Thu, 8 Dec 1994 14:41:15 -0800 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 OAA28017; Thu, 8 Dec 1994 14:41:08 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03327; Thu, 8 Dec 94 14:40:57 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id OAA12695; Thu, 8 Dec 1994 14:40:54 -0800 Received: from crusader.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA03959; Thu, 8 Dec 94 17:42:12 EST Received: by crusader.vsl.ist.ucf.edu (920330.SGI) id AA07951; Thu, 8 Dec 94 17:41:27 -0500 Date: Thu, 8 Dec 1994 17:41:27 -0500 (EST) From: "Lance R. Marrou" To: Performer List Subject: lots o' moving models on the scene Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I have question about optimizing performance. Someone mentioned before, though I am not sure who, that reorganizing the scene graph into something like an octree would be best. Although this makes complete sense for a static scene graph, I want to know if y'all think it would also work better for lots of moving models. COMMENTS: First, whenever a a moving model is updated, its parent's bounding volume may also need to be updated. This means that if, say, 20 models are in one section of the octree, then whenever one of the models gets updated, that octree section gets updated for all 20. Of course, the octree may have lots of subsections, which further increase the number of bounding volumes which get updated. Does Performer utilize a smart algorithm for updating bounding volumes under PFN_BMODE_DYNAMIC? That is, if we only translate a model, will its bounding volume merely be translated (and its parent's and so). Does it check for single children (thus just copying the child's bounding volume, rather than recomputing it). I am just curious if I might get some more performance for the time it takes to write the octree code. Also, some of that octree code may need to be special ordered based upon answers I get. Obviously, if there are only a few moving models, it makes sense doing a complicated octree. I do not know how many models it would take to make it worthwhile. Any ideas? Thanks. :) _______________________________________________________ E-mail: marrou@vsl.ist.ucf.edu IST __ WWW: http://www.vsl.ist.ucf.edu/~marrou Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Thu Dec 8 18:51:35 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA28330; Thu, 8 Dec 1994 18:29:40 -0800 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 SAA28327; Thu, 8 Dec 1994 18:29:39 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA13237; Thu, 8 Dec 94 18:29:33 -0800 Received: from iss.nus.sg by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id SAA17758; Thu, 8 Dec 1994 18:29:06 -0800 Received: from whitehead.iss.nus.sg by iss.nus.sg (5.x/SMI-SVR4) id AA07800; Fri, 9 Dec 1994 10:32:54 +0800 Date: Fri, 9 Dec 1994 10:32:54 +0800 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9412090232.AA07800@iss.nus.sg> Received: by whitehead.iss.nus.sg (5.0/SMI-SVR4) id AA01976; Fri, 9 Dec 94 10:32:53 SST To: info-performer@sgi.sgi.com Subject: Colour Tables Status: O Hi, I was just hoping that someone already had a colour table that I could use. Generally it would have entries like: "red" 1.0 0.0 0.0 "green" 0.0 1.0 0.0 I could generate my own or convert from X, but more of a performer standard colour table would be nice. thanks, Kim. From guest Thu Dec 8 19:39:58 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA28410; Thu, 8 Dec 1994 19:14:58 -0800 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 TAA28407; Thu, 8 Dec 1994 19:14:52 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA14726; Thu, 8 Dec 94 19:14:43 -0800 Received: from iss.nus.sg by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id TAA21812; Thu, 8 Dec 1994 19:05:24 -0800 Received: from whitehead.iss.nus.sg by iss.nus.sg (5.x/SMI-SVR4) id AA08190; Fri, 9 Dec 1994 11:09:11 +0800 Date: Fri, 9 Dec 1994 11:09:11 +0800 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9412090309.AA08190@iss.nus.sg> Received: by whitehead.iss.nus.sg (5.0/SMI-SVR4) id AA01978; Fri, 9 Dec 94 11:09:12 SST To: info-performer@sgi.sgi.com Subject: Pick and Move objects Status: O Hi, Does any one have code that picks the object under the cursor and then attached it to the cursor (at the same distance). I know that performer has something that picks objects, but I was hoping someone had figured out the matrices for moving as well. thanks, Kim. From guest Fri Dec 9 01:30:54 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA28924; Fri, 9 Dec 1994 01:11:43 -0800 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 BAA28921; Fri, 9 Dec 1994 01:11:42 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA20998; Fri, 9 Dec 94 01:11:40 -0800 Received: from viswiz by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id BAA15078; Fri, 9 Dec 1994 01:11:38 -0800 Received: by viswiz id AA26641 (5.65b/IDA-1.4.3.1 for info-performer@sgi.com); Fri, 9 Dec 94 09:11:45 GMT From: Simon Gibbs Message-Id: <9412090911.AA26641@viswiz> Subject: video texture corruption To: info-performer@sgi.sgi.com Date: Fri, 9 Dec 94 10:11:45 MET Status: O We have a RE 2 with RM-4s and a Sirius board. Our Performer 1.2 application loads in various textures and creates a surface with a video texture (using GL calls). When no non-video textures are used things work fine. However as we increase the number of textures we notice... - parts of other textures start appearing along the left edge of the video texture, - after loading still more/larger textures, the video texture starts flickering It looks like a bug in texture memory management, in particular when textures are being swapped and refreshed (using subtexload). Is this a known problem? Simon Gibbs GMD From guest Fri Dec 9 16:17:40 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA00717; Fri, 9 Dec 1994 15:57:38 -0800 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 PAA00714; Fri, 9 Dec 1994 15:57:37 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA12458; Fri, 9 Dec 94 15:57:32 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id PAA08698; Fri, 9 Dec 1994 15:57:30 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id PAA20260; Fri, 9 Dec 1994 15:57:28 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:simon@viswiz.gmd.de id AA12451; Fri, 9 Dec 94 15:57:27 -0800 Received: by rose.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id PAA28394; Fri, 9 Dec 1994 15:57:22 -0800 From: "Sharon Clay (Fischler)" Message-Id: <9412091557.ZM28392@rose.asd.sgi.com> Date: Fri, 9 Dec 1994 15:57:22 -0800 In-Reply-To: Simon Gibbs "video texture corruption" (Dec 9, 10:11am) References: <9412090911.AA26641@viswiz> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Simon Gibbs , info-performer@sgi.sgi.com Subject: Re: video texture corruption Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Dec 9, 10:11am, Simon Gibbs wrote: > Subject: video texture corruption -> ->We have a RE 2 with RM-4s and a Sirius board. Our Performer ->1.2 application loads in various textures and creates ->a surface with a video texture (using GL calls). When no non-video textures ->are used things work fine. However as we increase the ->number of textures we notice... -> - parts of other textures start appearing along the left edge -> of the video texture, -> - after loading still more/larger textures, the video -> texture starts flickering -> ->It looks like a bug in texture memory management, in particular ->when textures are being swapped and refreshed (using subtexload). -> ->Is this a known problem? When this happens, do you have more textures than will fit in texture memory? If you let the GL swap against the video texture, you will trash it. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Graphics Dev. src@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Mon Dec 12 02:15:17 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA17362; Mon, 12 Dec 1994 01:48:05 -0800 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 BAA17359; Mon, 12 Dec 1994 01:48:04 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA20360; Mon, 12 Dec 94 01:48:02 -0800 Received: from rubb.rz.ruhr-uni-bochum.de by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id BAA05549; Mon, 12 Dec 1994 01:47:48 -0800 Received: from midnite.neurobiologie.ruhr-uni-bochum.de (midnite.neurobiologie.ruhr-uni-bochum.de [134.147.120.6]) by rubb.rz.ruhr-uni-bochum.de (8.5/8.5) with SMTP id KAA05975; Mon, 12 Dec 1994 10:47:24 +0100 Received: by midnite.neurobiologie.ruhr-uni-bochum.de (NX5.67c/NX3.0S) id AA02522; Mon, 12 Dec 94 10:46:17 +0100 Date: Mon, 12 Dec 94 10:46:17 +0100 From: "Dr. Markus Lappe" Message-Id: <9412120946.AA02522@midnite.neurobiologie.ruhr-uni-bochum.de> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: info-performer@sgi.sgi.com Subject: subscribe Reply-To: lappe@neuroinformatik.ruhr-uni-bochum.de Status: O subscribe From guest Mon Dec 12 03:02:23 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA17406; Mon, 12 Dec 1994 02:39:41 -0800 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 CAA17403; Mon, 12 Dec 1994 02:39:37 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA21047; Mon, 12 Dec 94 02:39:28 -0800 Received: from hp720a.csc.cuhk.hk by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id CAA07305; Mon, 12 Dec 1994 02:39:21 -0800 Received: from [137.189.28.55] (hell.csc.cuhk.hk) by hp720a.csc.cuhk.hk with SMTP (1.37.109.10G/16.2) id AA036408760; Mon, 12 Dec 1994 18:39:20 +0800 Date: Mon, 12 Dec 1994 18:39:20 +0800 X-Sender: a019700@mailserv.cuhk.hk Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: anton-lam@cuhk.hk (Anton Lam) Subject: Pls add me to the list, thanks. Status: O Sorry if this is not the right address, but I only know this one. Regards Anton Lam Computer Services Centre The Chinese University of Hong Kong From guest Mon Dec 12 06:03:27 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA17587; Mon, 12 Dec 1994 05:45:23 -0800 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 FAA17584; Mon, 12 Dec 1994 05:45:18 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA24760; Mon, 12 Dec 94 05:45:18 -0800 Received: from INGFI1.ING.UNIFI.IT by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id FAA14452; Mon, 12 Dec 1994 05:45:10 -0800 From: luz@aguirre.ing.unifi.it Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Mon, 12 Dec 1994 14:44:22 +0200 (MET) Received: by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA17506; Mon, 12 Dec 94 14:39:49 +0100 Date: Mon, 12 Dec 94 14:39:49 +0100 Message-Id: <9412121339.AA17506@aguirre.ing.unifi.it> To: info-performer@sgi.sgi.com Subject: subscribtion Cc: Luz@aguirre.ing.unifi.it Status: O Subscrib me Luz Marina Tinjaca Computers of science University Of Florence e-mail : Luz@aguirre.ing.unifi.it From guest Mon Dec 12 07:47:49 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA18126; Mon, 12 Dec 1994 07:21:37 -0800 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 HAA18123; Mon, 12 Dec 1994 07:21:33 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA25887; Mon, 12 Dec 94 07:21:25 -0800 Received: from nvl.client by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id HAA20633; Mon, 12 Dec 1994 07:21:24 -0800 Received: by nvl.client (Smail3.1.28.1 #5) id m0rHCZ0-0001QSC; Mon, 12 Dec 94 10:21 EST Message-Id: Date: Mon, 12 Dec 94 10:21 EST From: dslayton@nvl.army.mil (David Slayton) To: info-performer@sgi.sgi.com Subject: range finding from Z-Buffer values Status: O I am attempting to write a range-finding routine as a post-pfdraw function in performer based upon the values contained in the Z-Buffer after pfdraw has completed. The values my routine is returning are inconsistent and non-intuitive. I expect to see values appoaching farplane +nearplane at their largest and nearplane at their smallest, but am not getting anything like this. When I'm looking at things far away, the range values seem to make sense. However, when I'm looking at things up close, the values still remain large (close to the value of farplane). My algorithm is based upon the premise that the z value for a given x,y window offset can yield a range to the foremost visible polygon based upon the following formula: range = (((z - zmin)/(zmax -zmin)) * (farplane - nearplane) + nearplane; The values zmin and zmax are the same as used in the call lsetdepth(zmin,zmax), the farplane and nearplane values are the same as those used in pfChanNearFar(ChanID, nearplane, farplane). The zvalue is a value returned by a call to lrectread(minx, miny, maxx, maxy, parray), where the parray contains the z values of the requested region. Just prior to calling lrectread, I'm calling readsource(SRC_ZBUFFER). The call to lsetdepth is being made in a initGfx callback shortly after a call to pfInitGfx(). The form of the lsetdepth call is either lsetdepth(getgconfig(GC_MS_ZMIN), getgconfig(GC_MS_ZMAX)) or lsetdepth(getgconfig(GC_ZMIN), getgconfig(GC_ZMAX)), depending on whether multisampling is active or not. Is Performer resetting the gl state such that my gl calls in the post-pfDraw function are not working as I would expect? Does anyone already have a range-finding function which already works with Performer? Does anyone see something wrong with my rangefinding function listed below. I'd appreciate any help I can get. ---------------------------------------------------------------------------- void display_range(volatile IoIn *G_input, IoOut *G_output, int X, int Y) { float np = 0.0, fp = 0.0; long nz = 0, fz = 0; unsigned long parray[1]; float zdist = 0.0; Screencoord minX, minY, maxX, maxY; long readcount = 0; pfPushState(); pfBasicState(); drawmode(NORMALDRAW); parray[0] = 0; if( ( X < 0 ) || ( X >= G_input->winSizeX ) || ( Y < 0 ) || ( Y >= G_input->winSizeY )) { pfNotify(PFNFY_WARN, PFNFY_PRINT, "Bad Windowps Offsets <%d,%d>passed to display_range(X,Y)\n" "The window is only ( %d xpixels, by %d ypixels )\n", X, Y, G_input->winSizeX, G_input->winSizeY); return; } /* use the values in the global Output structure as the near and far clipping plane values */ np = G_output->near; fp = G_output->far; nz = G_output->zmin; fz = G_output->zmax; #ifdef DEBUG pfNotify(PFNFY_NOTICE, PFNFY_PRINT, "display_range(): \n" "near clipping plane = <%f>, far clipping plane = <%f>, \n" "minimum z value = <%d>, maximum z value = <%d> \n", np, fp, nz, fz); #endif /* set the readsource to read from the Zbuffer */ readsource(SRC_ZBUFFER); if(!(getgdesc(GD_READSOURCE_ZBUFFER))) { pfNotify(PFNFY_WARN, PFNFY_PRINT, "getdesc status indicates that readsource(SRC_ZBUFFER) " "is not functional\n"); } /* get the z value at the x,y coordinates specified */ minX = X; minY = Y; maxX = X; maxY = Y; readcount = lrectread(minX,minY,minX,minY,parray); #ifdef DEBUG pfNotify(PFNFY_WARN, PFNFY_PRINT, "lrectread obtained <%ld>zvalues for the min<%d,%d>, max<%d,%d> " "coordinates passed to display_range(X,Y) " "parray[0] = <%ld>\n", readcount,minX,minY,maxX,maxY,(long)parray[0]); #endif /* calculate a distance */ /* distance should be the floating point value between the near and far */ /* clipping planes represented by the z interval value */ zdist = np + ( ( ((float)((long)parray[0])) - ((float)nz)) / (((float)fz) - ((float)nz))) * (fp -np); pfNotify(PFNFY_NOTICE, PFNFY_PRINT, "display_range calculated the following value for zdist (%f)\n", zdist); pfPopState(); } _____________________________________________________________________________ Thanks, Dave Slayton dslayton@nvl.army.mil (703)704-3698 From guest Mon Dec 12 08:26:47 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA18489; Mon, 12 Dec 1994 08:04:59 -0800 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 IAA18486; Mon, 12 Dec 1994 08:04:58 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA26593; Mon, 12 Dec 94 08:04:57 -0800 Received: from jumbo by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id IAA24243; Mon, 12 Dec 1994 08:04:50 -0800 Received: from viper.is.rest.tasc.com by jumbo (4.1/TASC-CLIENT-1.5) id AA18028; Mon, 12 Dec 94 11:00:32 EST Received: from temp4.is.rest.tasc.com by viper.is.rest.tasc.com (4.1/TASCnet-4.1R0.0) id AA22600; Mon, 12 Dec 94 10:59:36 EST Received: by temp4.is.rest.tasc.com (931110.SGI/930416.SGI) for @viper.is.rest.tasc.com:info-performer@sgi.com id AA13885; Mon, 12 Dec 94 11:04:17 -0500 From: "Thom DeCarlo" Message-Id: <9412121104.ZM13883@temp4.is.rest.tasc.com> Date: Mon, 12 Dec 1994 11:04:16 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Performer reads .iv. NOT! Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I have been trying to get perfly to read a simple Inventor file but have had no luck. I saw in the Performer FAQ that an updated LoadIV program was to be distributed "at a future date." Has that happened yet? If so, how can I get it? If not, when? Here is what I have done: run the I3DM program create a cone. save it as an ascii Inventor file (cone.iv) save it in the i3dm format (cone.sv) // Performer is supposed to read // this format, too. It doesn't. run "perfly cone.iv" prints a message that 4 CPUs are available, then hangs. ^C to exit run "perfly cone.sv" same behavior as above. System particulars: Onyx RE2 with 4 cpus 1024MB RAM IRIX 5.2 Performer 1.2 Thanks in advance-- Thom DeCarlo -- ,,, (o ~) ++-------------------------------------------++--------oOO--(_)--OOo-----++ || Thom DeCarlo || || || || There was a time when || || TASC - The Analytic Sciences Corporation || when religion ruled the || || 12100 Sunset Hills Rd. || world. It is known as || || Reston, VA 22090 || the Dark Ages. || || phone:703/834-5000 fax:703/318-7900 || || || email:trdecarlo@tasc.com || -Ruth Green || || email:tdecarlo@seas.gwu.edu || || ++-------------------------------------------++--------------------------++ From guest Mon Dec 12 09:35:53 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA18857; Mon, 12 Dec 1994 09:18:16 -0800 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 JAA18854; Mon, 12 Dec 1994 09:18:11 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA28775; Mon, 12 Dec 94 09:18:09 -0800 Received: from josef.ifi.unizh.ch by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id JAA02229; Mon, 12 Dec 1994 09:18:07 -0800 Message-Id: <199412121718.JAA02229@sgi.sgi.com> Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00464-0@josef.ifi.unizh.ch>; Mon, 12 Dec 1994 18:18:00 +0100 To: info-performer@sgi.sgi.com Subject: Geographical Texture Data Date: Mon, 12 Dec 1994 18:18:00 +0100 From: Martin Roth Sender: roth@ifi.unizh.ch Status: O Hi folks, we are working on a GIS project. Yet, we are able to virtually fly through Switzerland. The necessary (big amount of) scene data is prevented in realtime by an object-oriented database through an Ethernet network. In order to increase the reality of the rendering we are trying to implement a texture mapping of satellite data on the polygon surface. As you can imagine texture data is considerably increasing the amount of data to transfer. At the time we are dealing with three levels of detail. We are working on a 4 Mbyte texture RAM Onyx. In order not to run out of texture RAM it probably will be inevitable to introduce the concept of LODs into the texturing, too. Is there an easy (and RAM saving) way to realise texture LODs, eventually preventing the possibility of incrementally loading higher LODs? In order to realise the incremental loading is it possible to expand the actual texture bitmap in a fast way and then add details to the expanded texels? Thanks for your suggestions... ;-) Martin Roth _______________________________________________________________________________ /| /|) S. H. Martin Roth / |/ |\OTH Student in Computer Science ETHZ, Swiss Federal Institute of Technology Zuerich email: sroth@iiic.ethz.ch UniZh, University of Zuerich email: roth@ifi.unizh.ch From guest Mon Dec 12 11:29:46 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA19279; Mon, 12 Dec 1994 11:09:42 -0800 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 LAA19276; Mon, 12 Dec 1994 11:09:37 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03210; Mon, 12 Dec 94 11:09:35 -0800 Received: from wb.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id LAA17996; Mon, 12 Dec 1994 11:09:32 -0800 Received: from wb mail server (mailserver.wb.com) by wb.com (4.1/SMI-4.1) id AA07214; Mon, 12 Dec 94 14:09:26 EST Message-Id: <9412121909.AA07214@wb.com> Date: 12 Dec 1994 14:08:21 U From: "Weiblen, Mike" Subject: RE: Geographical Texture Data To: info-performer@sgi.sgi.com, "Martin Roth" Status: O Martin, We've done similar things using 10m SPOT imagery covering large areas of Nevada. Mipmapping essentially does texture LODs, but for image quality, not performance. The highest texture LOD must be in memory to use any of the lower details. No matter how small a 1024x1024 image appears in the scene, it will still occupy 2.8MB (1024x1024x2x4/3) of texture memory. What we do is downsample the imagery, and bind each texture LOD to a separate geometry LOD that switches at the best distance for texture smoothness. For each 10240x10240 meter tile in the database, the texture LODs are 16 256x256 images (10m res), 4 256x256 (20m), 1 256x256 (40m), 1 128x128 (80m), and finally 1 64x64 (160m) image. This buys three things: 1) we can get far enough from the terrain to see views that would have crashed the system before. (REs don't like scenes whose texture content exceed texture memory) 2) the texture is granular so that the RE can page. We texdef all the textures at startup and have loaded databases containing over 25MB texture and more on 16MB RM5s; the RE pages it in as needed. 3) the database can be represented completely in MultiGen format, and can be loaded and flown in MaK Stealth, Vega, perfly, and MultiGen. The downside is that paging textures can have a very jarring effect on frame rate. There are other techniques where you can do texture paging/management at the app level, fastbinding them in anticipation of use. They can provide beautiful results, and the expense of app complexity and database portability. It depends on your performance requirement. For us, it is more important not to customize apps to run a non-portable database. -- mew Mike Weiblen (mweiblen@wb.com) ARPA War Breaker, Arlington VA 22203 703-908-4358 _______________________________________________________________________________ To: info-performer@sgi.com From: Martin Roth on Mon, Dec 12, 1994 12:56 PM Subject: Geographical Texture Data ... the reality of the rendering we are trying to implement a texture mapping of satellite data on the polygon surface. As you can imagine texture data is considerably increasing the amount of data to transfer. At the time we are dealing with three levels of detail. We are working on a 4 Mbyte texture RAM Onyx. In order not to run out of texture RAM it probably will be inevitable to introduce the concept of LODs into the texturing, too. Is there an easy (and RAM saving) way to realise texture LODs, eventually preventing the possibility of incrementally loading higher LODs? ... From guest Mon Dec 12 11:39:12 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA19292; Mon, 12 Dec 1994 11:20:52 -0800 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 LAA19289; Mon, 12 Dec 1994 11:20:40 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03681; Mon, 12 Dec 94 11:20:39 -0800 Received: from chris.gcs.redstone.army.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id LAA19629; Mon, 12 Dec 1994 11:20:10 -0800 Received: by chris.gcs.redstone.army.mil (931110.SGI/930416.SGI) for info-performer@sgi.com id AA19696; Mon, 12 Dec 94 13:22:06 -0600 Date: Mon, 12 Dec 94 13:22:06 -0600 From: curry@chris.gcs.redstone.army.mil (Tim Curry) Message-Id: <9412121922.AA19696@chris.gcs.redstone.army.mil> To: "<""@chris.gcs.redstone.army.mil>"@chris.gcs.redstone.army.mil Subject: Accessing Frame Buffer Status: O I am trying to read the video frame buffer very quickly so I can perform some image processing on the image and write it back to the frame buffer. Doing lrectreads is very very slow because I am trying to achieve 60 Hz. I would like to see SGI give the user access to the VRAM via fast cache or RAM. I know the RE hardware documents the voltages to the frame buffer for 3rd party hardware to interface. Does anyone have a faster solution to reading the frame buffer. email: Tim Curry/MICOM phone: (205)876-7219 From guest Mon Dec 12 12:16:51 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA19405; Mon, 12 Dec 1994 12:00:01 -0800 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 MAA19402; Mon, 12 Dec 1994 12:00:00 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA05497; Mon, 12 Dec 94 11:59:50 -0800 Received: from NMSU.Edu by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id LAA26410; Mon, 12 Dec 1994 11:59:45 -0800 From: maytorre@NMSU.Edu Received: from ccserver by NMSU.Edu (8.6.8.1/NMSU-1.18) id MAA18246; Mon, 12 Dec 1994 12:59:39 -0700 Message-Id: <199412121959.MAA18246@NMSU.Edu> Received: by ccserver (AIX 3.2/UCB 5.64/NMSU) id AA28364; Mon, 12 Dec 1994 12:59:31 -0700 Subject: Performer reads iv. Maybe! To: info-performer@sgi.sgi.com Date: Mon, 12 Dec 1994 12:59:31 -0700 (MST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4228 Status: O >From root Mon Dec 12 12:55:26 1994 Received: from dns1.NMSU.Edu by ccserver (AIX 3.2/UCB 5.64/NMSU) id AA34447; Mon, 12 Dec 1994 12:55:25 -0700 Date: Mon, 12 Dec 1994 12:55:25 -0700 From: @ Message-Id: <9412121955.AA34447@ccserver> Received: from localhost by NMSU.Edu (8.6.8.1/NMSU-1.18) id MAB18088; Mon, 12 Dec 1994 12:55:30 -0700 Subject: Returned mail: Host unknown (Error 18400) To: Status: RO The original message was received at Mon, 12 Dec 1994 12:55:28 -0700 from paris [128.123.34.8] ----- The following addresses had delivery problems ----- (unrecoverable error) ----- Transcript of session follows ----- 501 ... 550 Host unknown (Error 18400) ----- Original message follows ----- Return-Path: Received: from ccserver by NMSU.Edu (8.6.8.1/NMSU-1.18) id MAA18088; Mon, 12 Dec 1994 12:55:28 -0700 From: Message-Id: <199412121955.MAA18088@NMSU.Edu> Received: by ccserver (AIX 3.2/UCB 5.64/NMSU) id AA29110; Mon, 12 Dec 1994 12:55:20 -0700 Subject: Re: Performer reads .iv. Maybe! To: thom@temp4.rest.tasc.com (Thom DeCarlo) Date: Mon, 12 Dec 1994 12:55:20 -0700 (MST) In-Reply-To: <9412121104.ZM13883@temp4.is.rest.tasc.com> from "Thom DeCarlo" at Dec 12, 94 11:04:16 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2757 Hello Thom, We've had partial success loading inventor files into perfly program. Particularly I've created a simple black box (cube) with showcase and saved it as an Inventor file. I can the see the Inventor file with an Inventor ivquicken. When I tried loading the box.iv *BINARY* file into perfly I obtained similar problems as you did. My solution was to use ivquicken to "improve" the inventor scene graph's rendering performance and to convert it to an ascii file. Then perfly had no problem loading the ascii file, though perfly may have problems with some Inventor ascii files some of the time etc. Anyway, I've read that the Performer's function that reads the iv files is not complete and thus misbehaves when its given an Inventor symbol that it does not recognize. If you want I can email you my box.iv ascii file and give that a try. But I sure wish that Performer had it together with these Inventor files. Hope this helps. M. Torres > > I have been trying to get perfly to read a simple Inventor file but > have had no luck. I saw in the Performer FAQ that an updated LoadIV > program was to be distributed "at a future date." Has that happened > yet? If so, how can I get it? If not, when? > > Here is what I have done: > run the I3DM program > create a cone. > save it as an ascii Inventor file (cone.iv) > save it in the i3dm format (cone.sv) // Performer is supposed to read > // this format, too. It doesn't. > > run "perfly cone.iv" > prints a message that 4 CPUs are available, then hangs. > ^C to exit > > run "perfly cone.sv" > same behavior as above. > > System particulars: > Onyx RE2 with 4 cpus > 1024MB RAM > IRIX 5.2 > Performer 1.2 > > > Thanks in advance-- > Thom DeCarlo > > > -- > ,,, > (o ~) > ++-------------------------------------------++--------oOO--(_)--OOo-----++ > || Thom DeCarlo || || > || || There was a time when || > || TASC - The Analytic Sciences Corporation || when religion ruled the || > || 12100 Sunset Hills Rd. || world. It is known as || > || Reston, VA 22090 || the Dark Ages. || > || phone:703/834-5000 fax:703/318-7900 || || > || email:trdecarlo@tasc.com || -Ruth Green || > || email:tdecarlo@seas.gwu.edu || || > ++-------------------------------------------++--------------------------++ > > > From guest Mon Dec 12 12:24:18 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA19431; Mon, 12 Dec 1994 12:05:24 -0800 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 MAA19428; Mon, 12 Dec 1994 12:05:23 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA05819; Mon, 12 Dec 94 12:05:18 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id MAA27339; Mon, 12 Dec 1994 12:05:15 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id MAA12778; Mon, 12 Dec 1994 12:05:13 -0800 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:RWeyrauch%TSS%SwRI05@D15VS178A.SPACE.SwRI.EDU id AA05766; Mon, 12 Dec 94 12:04:47 -0800 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA27823; Mon, 12 Dec 1994 12:03:11 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <199412122003.MAA27823@tubes.asd.sgi.com> Subject: Re: Sorted transparent billboards To: jrohlf@tubes (jrohlf) Date: Mon, 12 Dec 94 12:03:11 PST Cc: guest, RWeyrauch%TSS%SwRI05@D15VS178A.SPACE.SwRI.EDU, info-performer@sgi.sgi.com In-Reply-To: ; from "jrohlf" at Oct 31, 94 1:49 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > > > I have had similar problems with PFTR_NO_OCCLUDE. I had geosets that > > had a PFTR_NO_OCCLUDE flag in the Geostate and they occluded other geometry. > > When I use gltrace and glfprof, (gltrace produces OpenGL calls) there is > > no glDepthmask(GL_FALSE). Isn't that what there should be for a NO_OCCLUDE? > > -- > > > > Sean Halliday > > Computer Graphics Software Developer > > New Media Research, Banff Centre for the Arts. > > halliday@BanffCentre.AB.CA > > NO_OCCLUDE is supposed to set zwritemask(0). Looking at the > code I do see a possible bug if you are using decals, i.e., pfLayers, > since decals will reenable zwritemask. Does anybody have a > simple test case which I can debug? Perhaps I should come visit you > and chase this bug personally even though I hear Banff is a dump. 8-) Note that even with PFTR_NO_OCCLUDE set, transparent geometry *will* occlude opaque geometry. The PFTR_NO_OCCLUDE flag should really be called PFTR_NO_OCCLUDE_OTHER_TRANSP. Perhaps you are experiencing a feature, not a bug? However, your gldebug trace should reveal a zwritemask(0) call. From guest Mon Dec 12 13:22:02 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA19692; Mon, 12 Dec 1994 13:03:49 -0800 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 NAA19689; Mon, 12 Dec 1994 13:03:47 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA08441; Mon, 12 Dec 94 13:03:45 -0800 Received: from jumbo by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id NAA05724; Mon, 12 Dec 1994 13:03:41 -0800 Received: from viper.is.rest.tasc.com by jumbo (4.1/TASC-CLIENT-1.5) id AA24650; Mon, 12 Dec 94 15:58:35 EST Received: from temp4.is.rest.tasc.com by viper.is.rest.tasc.com (4.1/TASCnet-4.1R0.0) id AA26681; Mon, 12 Dec 94 15:57:37 EST Received: by temp4.is.rest.tasc.com (931110.SGI/930416.SGI) for @viper.is.rest.tasc.com:info-performer@sgi.com id AA00894; Mon, 12 Dec 94 16:02:18 -0500 From: "Thom DeCarlo" Message-Id: <9412121602.ZM892@temp4.is.rest.tasc.com> Date: Mon, 12 Dec 1994 16:02:18 -0500 In-Reply-To: maytorre@NMSU.Edu "Performer reads iv. Maybe!" (Dec 12, 12:59pm) References: <199412121959.MAA18246@NMSU.Edu> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: maytorre@nmsu.edu Subject: Re: Performer reads iv. Maybe! Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi M. (May? :-) Thanks for the idea. I hadn't though about using ivquicken. I'm at the wrong computer now, but I'll try that ASAP. Yeah, IMHO, the Performer team blew it big time by not giving Inventor better coverage. I read in the FAQ that a more complete Inventor reader was to be distributed through the info-performer mailing list "at a future time." I guess the future hasn't happened yet. In the mean time, I've pulled a copy of pfiv.c out of /usr/src/Performer/... and I'm trying to hack out my own LoadIv() function. That's another thing. I've been reading Gavin Bell's postings in comp.sys.sgi.graphics. He is asking if any Inventor users would be upset if Inventor's C API were to disappear in a future (the next?) release. I guess we'd better hope the Performer team is moving to C++ or we are really going to be left out in the cold. Thanks again. Thom -- ,,, (o ~) ++-------------------------------------------++--------oOO--(_)--OOo-----++ || Thom DeCarlo || || || || There was a time when || || TASC - The Analytic Sciences Corporation || when religion ruled the || || 12100 Sunset Hills Rd. || world. It is known as || || Reston, VA 22090 || the Dark Ages. || || phone:703/834-5000 fax:703/318-7900 || || || email:trdecarlo@tasc.com || -Ruth Green || || email:tdecarlo@seas.gwu.edu || || ++-------------------------------------------++--------------------------++ From guest Mon Dec 12 16:21:42 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA20405; Mon, 12 Dec 1994 16:02:41 -0800 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 QAA20402; Mon, 12 Dec 1994 16:02:35 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA15616; Mon, 12 Dec 94 16:02:30 -0800 Received: from Arizona.EDU by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id QAA05052; Mon, 12 Dec 1994 16:02:21 -0800 Received: from crimson.mse.arizona.edu by Arizona.EDU (PMDF V4.3-10 #2381) id <01HKKAMW3R8GEWWYE4@Arizona.EDU>; Mon, 12 Dec 1994 17:02:15 -0700 (MST) Received: by crimson.mse.arizona.edu (931110.SGI/930416.SGI.AUTO) for @Hopey.Telcom.Arizona.EDU:info-performer@sgi.com id AA17382; Mon, 12 Dec 94 17:55:43 -0600 Date: Mon, 12 Dec 1994 17:55:42 -0700 From: "Frank J. Cherne" Subject: Crystal Eyes on VGXT with Performer? To: info-performer@sgi.sgi.com Message-Id: <9412121755.ZM17380@crimson.mse.arizona.edu> Mime-Version: 1.0 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Status: O Is there any sample programs or sample code to utilize Crystal Eyes with a Crimson VGXT system based upon performer. Thanks in Advance. Frank Cherne From guest Mon Dec 12 16:47:37 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA20453; Mon, 12 Dec 1994 16:33:20 -0800 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 QAA20450; Mon, 12 Dec 1994 16:33:19 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA16669; Mon, 12 Dec 94 16:33:18 -0800 Received: from trout.nosc.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id QAA10086; Mon, 12 Dec 1994 16:33:16 -0800 Received: from marlin.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA26200; Mon, 12 Dec 94 16:33:15 PST Received: by marlin.nosc.mil (4.1/SMI-4.1) id AA29541; Mon, 12 Dec 94 16:33:42 PST Date: Mon, 12 Dec 1994 16:33:42 -0800 (PST) From: "B. Cabrera" To: PERFORMER Subject: Multiprocessing and Me Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hello everyone, I'm a beginning performer programmer. I've written a system to place and manipulate objects on a 3D terrain with a Motif 'control panel.' Being completely ignorant of Performer when I started off, I did not design it properly and now it will not multiprocess. What I want to know is: 1) which operations are timing dependent and when should I do them 2) which operations need to be placed in the pre-Cull, post-Cull, pre-Draw, post-Draw, and App processes 3) if there is a book besides the very thin Performer manual, what is it called, and where can I get it. I understand that there are apps out there to aid in building Performer systems, but it is now morally imperative that I get this working on my own. The system does some keyframing of objects in the scene (you can setup keyframes on the fly), so I need to know when I can move the things around and not kill the multiprocessing. Multiprocessing is my bane. Thank you, B. Cabrera From guest Mon Dec 12 19:12:07 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA20645; Mon, 12 Dec 1994 18:52:46 -0800 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 SAA20642; Mon, 12 Dec 1994 18:52:44 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA21106; Mon, 12 Dec 94 18:52:43 -0800 Received: from iss.nus.sg by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id SAA00050; Mon, 12 Dec 1994 18:52:39 -0800 Received: from charon by iss.nus.sg (5.x/SMI-SVR4) id AA14772; Tue, 13 Dec 1994 10:56:31 +0800 From: desmond@iss.nus.sg (Desmond Hii Toh Onn) Received: by charon (931110.SGI//ident-1.0) id AA00873; Tue, 13 Dec 94 10:56:30 +0800 Message-Id: <9412130256.AA00873@charon> Subject: performer and FORMS library To: info-performer@sgi.sgi.com Date: Tue, 13 Dec 1994 10:56:30 +0800 (SST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: O Has anyone tried integrating Forms and performer? what are the issues involved? thanks in advance for any comment. Desmond From guest Mon Dec 12 19:50:33 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA23497; Mon, 12 Dec 1994 19:25:56 -0800 Return-Path: Received: from surreal.asd.sgi.com by holodeck.asd.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA23494; Mon, 12 Dec 1994 19:25:54 -0800 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id TAA23749; Mon, 12 Dec 1994 19:25:52 -0800 Message-Id: <199412130325.TAA23749@surreal.asd.sgi.com> To: "Thom DeCarlo" cc: info-performer Subject: Re: Performer reads iv. Maybe! In-reply-to: Your message of "Mon, 12 Dec 94 16:02:18 EST." <9412121602.ZM892@temp4.is.rest.tasc.com> Date: Mon, 12 Dec 94 19:25:52 -0800 From: Jim Helman Status: O > I've been reading Gavin Bell's postings in comp.sys.sgi.graphics. > He is asking if any Inventor users would be upset if Inventor's C > API were to disappear in a future (the next?) release. I guess we'd > better hope the Performer team is moving to C++ or we are really > going to be left out in the cold. "Moving"? Just to allay fears, we are *adding* a C++ API (which is our underlying language) in Performer 2.0. We have no plans to abandon our C API or leave it less functional than our C++ API. I apologize to everyone for the delay in getting the completed Inventor loader out door. There are still some optimzations to be done to it. Sometimes we may be too picky about performance, but it is our obsession. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Dec 12 21:44:32 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA29921; Mon, 12 Dec 1994 21:21:00 -0800 Return-Path: Received: from surreal.asd.sgi.com by holodeck.asd.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA29907; Mon, 12 Dec 1994 21:20:54 -0800 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id VAA24247; Mon, 12 Dec 1994 21:20:51 -0800 Message-Id: <199412130520.VAA24247@surreal.asd.sgi.com> To: curry@chris.gcs.redstone.army.mil (Tim Curry) cc: info-performer Subject: Re: Accessing Frame Buffer In-reply-to: Your message of "Mon, 12 Dec 94 13:22:06 CST." <9412121922.AA19696@chris.gcs.redstone.army.mil> Date: Mon, 12 Dec 94 21:20:46 -0800 From: Jim Helman Status: O It depends what sort of image processing you need to do. You can do lrectcopies or fbsubtexloads through the GE's back to the frame buffer or to texture memory. On the way, the GE's can do various image processing operations at up to 20MPixels per second per component. (The exact rate depends a lot on what you do). Check out the man pages for pixmode, pixeltransfer, hgram, convolve, minmax, and friends. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Dec 13 00:57:11 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA10640; Tue, 13 Dec 1994 00:37:08 -0800 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 AAA10613; Tue, 13 Dec 1994 00:36:51 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA26763; Tue, 13 Dec 94 00:36:45 -0800 Received: from dfunms.rus.uni-stuttgart.de by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id AAA26870; Tue, 13 Dec 1994 00:36:41 -0800 From: michael@ifr.luftfahrt.uni-stuttgart.de Received: from ifr1.luftfahrt.uni-stuttgart.de by dfunms.rus.uni-stuttgart.de with SMTP id AA13259 (5.65c8/DFUE-M1.0 for ); Tue, 13 Dec 1994 09:36:23 +0100 Received: from ifr16 by ifr1.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-1.0NeXT+) id AA06472; Tue, 13 Dec 94 09:36:19 +0100 Message-Id: <9412130836.AA06472@ifr1.Luftfahrt.Uni-Stuttgart.DE> Received: by ifr16.Luftfahrt.Uni-Stuttgart.DE (NX5.67e/BelWue-S1.0NeXT+) id AA04449; Tue, 13 Dec 94 09:36:17 +0100 Date: Tue, 13 Dec 94 09:36:17 +0100 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: Jim Helman Subject: Re: Performer reads iv. Maybe! Cc: info-performer Status: O > "Moving"? Just to allay fears, we are *adding* a C++ API > (which is our underlying language) in Performer 2.0. We > have no plans to abandon our C API or leave it less > functional than our C++ API. > > -jim helman > > jimh@surreal.asd.sgi.com > 415/390-1151 > What about the Ada95 interface to Performer. I haven't heared anything about it for quite a while now. I hope there are many more people interested in that and not just me. Michael -- |----------------------------------------------------------------------| |Dipl.-Ing. Michael Paus (Member: Team Ada) | |University of Stuttgart, Inst. of Flight Mechanics and Flight Control | |Forststrasse 86, 70176 Stuttgart, Germany | |Phone: (+49) 711-121-1434 FAX: (+49) 711-634856 | |Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)| From guest Tue Dec 13 02:27:00 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA11638; Tue, 13 Dec 1994 02:03:31 -0800 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 CAA11635; Tue, 13 Dec 1994 02:03:22 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA28054; Tue, 13 Dec 94 02:03:19 -0800 Received: from happy.ait.nrl.navy.mil by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id CAA01466; Tue, 13 Dec 1994 02:03:18 -0800 Received: (from king@localhost) by happy.ait.nrl.navy.mil (8.6.7/8.6.7) id FAA07999; Tue, 13 Dec 1994 05:03:15 -0500 Date: Tue, 13 Dec 1994 04:51:24 -0500 (EST) From: "Robert D. King" Subject: Re: Performer reads .iv. NOT! To: Thom DeCarlo Cc: info-performer@sgi.sgi.com In-Reply-To: <9412121104.ZM13883@temp4.is.rest.tasc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Mon, 12 Dec 1994, Thom DeCarlo wrote: > I have been trying to get perfly to read a simple Inventor file but > have had no luck. I saw in the Performer FAQ that an updated LoadIV > program was to be distributed "at a future date." Has that happened > yet? If so, how can I get it? If not, when? > Tom, The problem is in the way that pfiv.c treats an empty set of braces when encountering the inventor command to create a tristrip out of the previously loaded vertices. The 'fix' I am including works around that for simple shapes by testing for the T_COMPLETE code from the tokenizing routine, and setting the striplength to the current number of unprocessed vertices (vCount) if so. With this patch, you should be able to use most of the objects made by id3m (at least as far as my limited testing has put demands on the 'fix'). diff between my new pfiv.c and the old pfiv.c: 336d335 < int doAll = 0; 340,345c339 < { < if (tokenType == T_COMPLETE) { < doAll = 1; < break; < } < } --- > /* EMPTY */ {;} 350c344 < int stripLength = -1; --- > int stripLength; 352,356c346 < if (!doAll) < sscanf(token, "%d", &stripLength); < < if (stripLength <= 0) < stripLength = vCount; --- > sscanf(token, "%d", &stripLength); Regards, Rob From guest Tue Dec 13 02:40:31 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA11656; Tue, 13 Dec 1994 02:17:26 -0800 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 CAA11653; Tue, 13 Dec 1994 02:17:25 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA28228; Tue, 13 Dec 94 02:17:20 -0800 Received: from happy.ait.nrl.navy.mil by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id CAA02032; Tue, 13 Dec 1994 02:17:19 -0800 Received: (from king@localhost) by happy.ait.nrl.navy.mil (8.6.7/8.6.7) id FAA08097; Tue, 13 Dec 1994 05:17:17 -0500 Date: Tue, 13 Dec 1994 05:08:38 -0500 (EST) From: "Robert D. King" Subject: Re: Performer reads .iv. NOT! To: info-performer@sgi.sgi.com In-Reply-To: <9412121104.ZM13883@temp4.is.rest.tasc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I am replying here instead of directly to Thom DeCarlo because my mail sender couldn't parse Thom's address On Mon, 12 Dec 1994, Thom DeCarlo wrote: > I have been trying to get perfly to read a simple Inventor file but > have had no luck. I saw in the Performer FAQ that an updated LoadIV > program was to be distributed "at a future date." Has that happened > yet? If so, how can I get it? If not, when? > Thom, The problem is in the way that pfiv.c treats an empty set of braces when encountering the inventor command to create a tristrip out of previously loaded vertices. The 'fix' I am including works around that for simple shapes by testing for a T_COMPLETE code return from the tokenizing routine, and setting the striplength to the current number of unprocessed vertices (vCount) if so. The apparent 'hang' is the routine blocking *forever* on the final set of curly braces in your .iv file! With this patch, you should be able to use of the objects made by id3m (at least as far as my limited testing has put demands on the 'fix'). diff between my new pfiv.c and the old pfiv.c: 336d335 < int doAll = 0; 340,345c339 < { < if (tokenType == T_COMPLETE) { < doAll = 1; < break; < } < } --- > /* EMPTY */ {;} 350c344 < int stripLength = -1; --- > int stripLength; 352,356c346 < if (!doAll) < sscanf(token, "%d", &stripLength); < < if (stripLength <= 0) < stripLength = vCount; --- > sscanf(token, "%d", &stripLength); Regards, Rob From guest Tue Dec 13 05:03:33 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id EAA11844; Tue, 13 Dec 1994 04:42:23 -0800 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 EAA11841; Tue, 13 Dec 1994 04:42:14 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA00485; Tue, 13 Dec 94 04:42:13 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id EAA08009; Tue, 13 Dec 1994 04:42:11 -0800 Received: from loukoum.neu.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for id EAA10011; Tue, 13 Dec 1994 04:42:08 -0800 Received: by loukoum.neu.sgi.com (920330.SGI/911001.SGI) for info-performer@sgi.sgi.com id AA08439; Tue, 13 Dec 94 13:41:08 +0100 From: "Richard Mercille" Message-Id: <9412131341.ZM8437@loukoum.neu.sgi.com> Date: Tue, 13 Dec 1994 13:41:07 +0100 In-Reply-To: desmond@iss.nus.sg (Desmond Hii Toh Onn) "performer and FORMS library" (Dec 13, 10:56am) References: <9412130256.AA00873@charon> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: desmond@iss.nus.sg (Desmond Hii Toh Onn), info-performer@sgi.sgi.com Subject: Re: performer and FORMS library Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Dec 13, 10:56am, Desmond Hii Toh Onn wrote: > Subject: performer and FORMS library > Has anyone tried integrating Forms and performer? > what are the issues involved? > > thanks in advance for any comment. > > Desmond > > >-- End of excerpt from Desmond Hii Toh Onn ************************************************************************* Hi, I did two versions of Performer with Forms. One with Performer inside the form and one with Performer outside. Normal perfly.c (or complex.c) code with the addition of ************************* First Case : INSIDE FORMS ************************* static void OpenPipeline(pfPipe *p) { long formwin, submwin; /* negotiate with window-manager */ foreground(); fl_init(); create_the_forms(); fl_set_button(Stat,1); fl_addto_choice(Mode,"FREE"); fl_addto_choice(Mode,"FLOAT"); fl_addto_choice(Mode,"LIMIT"); fl_addto_choice(Mode,"LOCK"); formwin = fl_show_form(formGUI,FL_PLACE_CENTER,TRUE,"Title"); submwin = swinopen(formwin); ^^^^ This is the way to get Performer in forms winposition(11,735,129,752); winconstraints(); ........ } *************************** Second Case : OUTSIDE FORMS *************************** void formsLink(void) { FL_OBJECT *obj; char buf[80]; /* if remoteGUI is defined user@donaim */ /* You can have the GUI on another host */ if(remoteGUI) { sprintf(buf, "%s:0.0", login); if(dglopen(buf, DGLTSOCKET) >= 0) { printf("\nRemote connection SUCCEDED\n"); } } fl_init(); create_the_forms(); /* INITIALIZATION OF FORMS */ /* Main Loop */ fl_show_form(pformsRoot, FL_PLACE_CENTER, FALSE, NULL); while(!Shared->exitFlag) { obj=fl_check_forms(); } } static void OpenPipeline(pfPipe *p) { pid_t stat; float xSize = 800; float ySize = 500; /* negotiate with window-manager */ foreground(); /* * Fork user interface */ if((stat=fork()) == 0) { formsLink(); exit(0); } if(stat < 0) { perror("Fork Failed"); exit(0); } winopen("IRIS Performer"); winconstraints(); /* register events of note with event-queue manager */ qdevice(ESCKEY); /* negotiate with GL */ pfInitGfx(p); ............. } Ciao -- ------------------------- Richard Mercille European Graphics Lab Cortaillod, Switzerland Email rim@neu.sgi.com VMail 5-8408 Phone +41.38.43.35.29 Fax +41.38.43.39.05 From guest Tue Dec 13 05:53:53 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA11911; Tue, 13 Dec 1994 05:33:13 -0800 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 FAA11908; Tue, 13 Dec 1994 05:33:09 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA01675; Tue, 13 Dec 94 05:33:04 -0800 Received: from viswiz by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id FAA10152; Tue, 13 Dec 1994 05:33:02 -0800 Received: by viswiz id AA06762 (5.65b/IDA-1.4.3.1 for info-performer@sgi.com); Tue, 13 Dec 94 13:33:11 GMT From: Simon Gibbs Message-Id: <9412131333.AA06762@viswiz> Subject: SOFTIMAGE loader To: info-performer@sgi.sgi.com Date: Tue, 13 Dec 94 14:33:11 MET Status: O Does anybody know of a Perfomer loader for SOFTIMAGE files? Thanks, Simon Gibbs From guest Tue Dec 13 11:36:09 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA13520; Tue, 13 Dec 1994 11:21:17 -0800 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 LAA13517; Tue, 13 Dec 1994 11:21:16 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA12284; Tue, 13 Dec 94 11:21:15 -0800 Received: from chris.gcs.redstone.army.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id LAA19131; Tue, 13 Dec 1994 11:20:42 -0800 Received: by chris.gcs.redstone.army.mil (931110.SGI/930416.SGI) for info-performer@sgi.com id AA00582; Tue, 13 Dec 94 13:22:54 -0600 Date: Tue, 13 Dec 94 13:22:54 -0600 From: curry@chris.gcs.redstone.army.mil (Tim Curry) Message-Id: <9412131922.AA00582@chris.gcs.redstone.army.mil> To: "<""@chris.gcs.redstone.army.mil>"@chris.gcs.redstone.army.mil Subject: ERROR Message Status: O I am getting a Warning on my Performer application: No IB2: default to normal fog I am running with an RE2 onyx. 4RM and 4CPUs Does this mean I have a older version of the RE hardware ? Tim Curry :::::: :::::: :::::: Engineer :: :: :: 205/876.7219 (voice) :: :: :: 205/842.0969 ( fax ) Computer Sciences Corporation :: :: :: :: :: :: :::::: :::::: :::::: email: From guest Tue Dec 13 12:40:42 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA13633; Tue, 13 Dec 1994 12:20:58 -0800 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 MAA13630; Tue, 13 Dec 1994 12:20:57 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA15150; Tue, 13 Dec 94 12:20:56 -0800 Received: from athens.dis.anl.gov by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id MAA28986; Tue, 13 Dec 1994 12:20:49 -0800 Received: from gwynedd.dis.anl.gov (gwynedd.dis.anl.gov [146.137.92.18]) by athens.dis.anl.gov (8.6.8.1/8.6.6) with ESMTP id OAA09334 for ; Tue, 13 Dec 1994 14:20:48 -0600 Received: (fuja@localhost) by gwynedd.dis.anl.gov (8.6.8.1/8.6.6) id OAA00542; Tue, 13 Dec 1994 14:20:46 -0600 Date: Tue, 13 Dec 1994 14:20:45 -0600 (CST) From: Russell Fuja X-Sender: fuja@gwynedd To: info-performer@sgi.sgi.com Subject: Conversion from MicroStation to Performer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Performer Experts: I have an application where I need to take a number of 3d models from an Intergraph MicroStation and eventually display them in Performer. I am looking for help in determining how to convert the models into a format suitable for a 3d modeling packages such as ModelGen or whatever. MicroStation supports export into DXF (which CANNOT be used because of the information lost in conversion) and the IGES format. Does anyone know how to convert a model in IGES into something Performer can read (like OpenFlight, or IRIS Inventor, or whatever is appropriate)? Can someone point me to a modeler program or a bit of conversion code? Any assistance is deeply appreciated. Thanks!! Sincerely, Russell S. Fuja Argonne National Laboratory fuja@dis.anl.gov From guest Tue Dec 13 13:18:05 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA13684; Tue, 13 Dec 1994 13:00:34 -0800 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 NAA13679; Tue, 13 Dec 1994 13:00:33 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA16105; Tue, 13 Dec 94 13:00:28 -0800 Received: from hawk.banffcentre.ab.ca by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id NAA04230; Tue, 13 Dec 1994 13:00:23 -0800 Received: from grizzly.BanffCentre.AB.CA (grizzly.BanffCentre.AB.CA [198.161.28.11]) by hawk.banffcentre.ab.ca (8.6.9/8.6.9) with SMTP id NAA11296 for <@hawk.BanffCentre.AB.CA:info-performer@sgi.com>; Tue, 13 Dec 1994 13:50:59 -0700 Received: by grizzly.BanffCentre.AB.CA (940715.SGI.52/941006.NewMedia-client) for @hawk.BanffCentre.AB.CA:info-performer@sgi.com id AA03059; Tue, 13 Dec 94 14:01:28 -0700 From: halliday@BanffCentre.AB.CA (Sean Halliday) Message-Id: <9412132101.AA03059@grizzly.BanffCentre.AB.CA> Subject: Multiprocessing. To: info-performer@sgi.sgi.com Date: Tue, 13 Dec 1994 14:01:27 -0700 (MST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 836 Status: O I have an old application that I will eventually convert from GL to Performer. What I tried to to as a quick fix is to make it two processes, app and draw (I used sproc.) This worked most of the time. After a random amount of time the graphics pipeline (RE2) would crash. I am not doing any GL calls in the app. I think the problem was that the app could be writing to data (like a matrix) while the draw was accessing it (like multmatrix). Can that be a problem? How does perfromer handle this? Does fork and shared memory fix the problem or does Performer make a copy of the data before making a GL call? Thanks in advance. -- Sean Halliday Computer Graphics Software Developer New Media Research, Banff Centre for the Arts. halliday@BanffCentre.AB.CA From guest Tue Dec 13 17:31:56 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA14037; Tue, 13 Dec 1994 17:14:24 -0800 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 RAA14034; Tue, 13 Dec 1994 17:14:20 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA25490; Tue, 13 Dec 94 17:13:57 -0800 Received: from jumbo by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id RAA13464; Tue, 13 Dec 1994 17:13:51 -0800 Received: from viper.is.rest.tasc.com by jumbo (4.1/TASC-CLIENT-1.5) id AA29183; Tue, 13 Dec 94 20:08:25 EST Received: from temp4.is.rest.tasc.com by viper.is.rest.tasc.com (4.1/TASCnet-4.1R0.0) id AA09193; Tue, 13 Dec 94 20:07:53 EST Received: by temp4.is.rest.tasc.com (931110.SGI/930416.SGI) for @viper.is.rest.tasc.com:info-performer@sgi.com id AA02877; Tue, 13 Dec 94 20:12:34 -0500 From: "Thom DeCarlo" Message-Id: <9412132012.ZM2875@temp4.is.rest.tasc.com> Date: Tue, 13 Dec 1994 20:12:33 -0500 Reply-To: trdecarlo@tasc.com X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: king@ait.nrl.navy.mil Subject: Re: Performer reads .iv. NOT! Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Rob, Thanks for your help. I will try out your patch ASAP. BTW, I think I've fixed my mail reply problem. Hopefully, now that I've set the Reply-To header field your replys won't be bounced off our firewall. -- Thom -- ,,, (o ~) ++-------------------------------------------++--------oOO--(_)--OOo-----++ || Thom DeCarlo || || || || There was a time when || || TASC - The Analytic Sciences Corporation || when religion ruled the || || 12100 Sunset Hills Rd. || world. It is known as || || Reston, VA 22090 || the Dark Ages. || || phone:703/834-5000 fax:703/318-7900 || || || email:trdecarlo@tasc.com || -Ruth Green || || email:tdecarlo@seas.gwu.edu || || ++-------------------------------------------++--------------------------++ From guest Tue Dec 13 22:52:49 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA15678; Tue, 13 Dec 1994 22:24:44 -0800 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 WAA15675; Tue, 13 Dec 1994 22:24:39 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA01945; Tue, 13 Dec 94 22:24:34 -0800 Received: from iss.nus.sg by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id WAA08028; Tue, 13 Dec 1994 22:24:31 -0800 Received: from whitehead.iss.nus.sg by iss.nus.sg (5.x/SMI-SVR4) id AA28169; Wed, 14 Dec 1994 14:25:32 +0800 Date: Wed, 14 Dec 1994 14:25:32 +0800 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9412140625.AA28169@iss.nus.sg> Received: by whitehead.iss.nus.sg (5.0/SMI-SVR4) id AA00574; Wed, 14 Dec 94 14:18:28 SST To: fuja@dis.anl.gov Cc: info-performer@sgi.sgi.com In-Reply-To: (message from Russell Fuja on Tue, 13 Dec 1994 14:20:45 -0600 (CST)) Subject: Re: Conversion from MicroStation to Performer Status: O Hi, We wrote our own translator to our own format. Intergraph is VERY complicated in the number of forms that it can produce (one of our staff spent a year on the translator). If you send us one of your models (one of the more complicated ones for a test), we can see what the translation looks like. thanks, Kim. From guest Tue Dec 13 23:37:13 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA15750; Tue, 13 Dec 1994 23:16:11 -0800 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 XAA15747; Tue, 13 Dec 1994 23:16:06 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA02635; Tue, 13 Dec 94 23:16:04 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id XAA11317; Tue, 13 Dec 1994 23:16:01 -0800 Received: from eclipse.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA02648; Wed, 14 Dec 94 02:17:18 EST Received: by eclipse.vsl.ist.ucf.edu (4.1) id AA06222; Wed, 14 Dec 94 02:16:00 EST Date: Wed, 14 Dec 1994 02:15:59 -0500 (EST) From: "Lance R. Marrou" To: Desmond Hii Toh Onn Cc: info-performer@sgi.sgi.com Subject: Re: performer and FORMS library In-Reply-To: <9412130256.AA00873@charon> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Tue, 13 Dec 1994, Desmond Hii Toh Onn wrote: > Has anyone tried integrating Forms and performer? > what are the issues involved? Well, the first issue is that FORMS must be used only within the draw process. Of course, this will reduce your performance. Also, the FORMS object redrawing functions are obviously not synchronized with your Performer pfSync() and thus you may get many swapbuffers() calls per frame. Richard Mercille offered some nice solutions to integrate FORMS with Performer. I personally like the fork() call solution, though it may compicated message passing. I think implementing the Motif widgets found in perfly would be the better, though more complicated solution (fdesign is really cool, isn't it? :) Maybe someone could convinve Mark Overmars to write a Performer solution of the FORMS library? ;) _______________________________________________________ E-mail: marrou@vsl.ist.ucf.edu IST __ WWW: http://www.vsl.ist.ucf.edu/~marrou Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Wed Dec 14 00:06:35 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA15788; Tue, 13 Dec 1994 23:47:32 -0800 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 XAA15785; Tue, 13 Dec 1994 23:47:31 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03117; Tue, 13 Dec 94 23:47:28 -0800 Received: from rubb.rz.ruhr-uni-bochum.de by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id XAA13013; Tue, 13 Dec 1994 23:47:08 -0800 Received: from fsnif.neuroinformatik.ruhr-uni-bochum.de (fsnif.neuroinformatik.ruhr-uni-bochum.de [134.147.96.18]) by rubb.rz.ruhr-uni-bochum.de (8.5/8.5) with SMTP id IAA22797; Wed, 14 Dec 1994 08:46:45 +0100 Received: from sunset.neurobiologie.ruhr-uni-bochum.de by fsnif.neuroinformatik.ruhr-uni-bochum.de (4.1/LAN-GW-1.0) id AA04154; Wed, 14 Dec 94 08:46:34 +0100 Received: by sunset.neurobiologie.ruhr-uni-bochum.de (4.1/SMI-4.1) id AA25695; Wed, 14 Dec 94 08:51:16 +0100 Date: Wed, 14 Dec 94 08:51:16 +0100 From: lappe@neuroinformatik.ruhr-uni-bochum.de (Markus Lappe) Message-Id: <9412140751.AA25695@sunset.neurobiologie.ruhr-uni-bochum.de> To: info-performer@sgi.sgi.com Subject: subscribe Status: O please enter my subscription From guest Wed Dec 14 01:19:03 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA15937; Wed, 14 Dec 1994 00:57:51 -0800 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 AAA15934; Wed, 14 Dec 1994 00:57:42 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA05230; Wed, 14 Dec 94 00:57:36 -0800 Received: from rhh.rhh.dk by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id AAA16294; Wed, 14 Dec 1994 00:57:30 -0800 Received: by rhh.rhh.dk (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA15036; Wed, 14 Dec 94 09:51:11 +0100 Date: Wed, 14 Dec 1994 09:51:09 +0100 (MET) From: Bjorn Eliasen To: Russell Fuja Cc: info-performer@sgi.sgi.com Subject: Re: Conversion from MicroStation to Performer In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi, We have been converting about 15 meg. MicroStation models into flight format utilizing the dxf reader within MultiGen. I don't know if ModelGen has the same feature. With the latest versions of MultiGen I think you will find that the conversion is almost complete leaving just a number of backfacing polygons which needs to be inverted. If you need more details please don't hesitate to call me at int + 45 45986800 if you like. Sincerely, Bjoern Eliasen RH&H Consult, Denmark From guest Wed Dec 14 01:20:52 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA15946; Wed, 14 Dec 1994 01:03:04 -0800 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 BAA15943; Wed, 14 Dec 1994 01:03:03 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA05326; Wed, 14 Dec 94 01:03:02 -0800 Received: from relay.iunet.it by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id BAA16626; Wed, 14 Dec 1994 01:02:51 -0800 Received: from hpdtmt2.UUCP by relay.iunet.it with UUCP id AA17785 (5.65c8/IDA-1.4.4 for info-performer%sgi.com@iunet.it); Wed, 14 Dec 1994 10:11:09 +0100 Message-Id: <199412140911.AA17785@relay.iunet.it> Received: by hpdtmt2 (16.6/16.2) id AA18590; Wed, 14 Dec 94 09:32:26 +0100 From: Marco Crocetta Subject: Performer Cloned Instancing To: info-performer@sgi.sgi.com Date: Wed, 14 Dec 94 9:32:25 MET Mailer: Elm [revision: 66.25] Status: O Hi, I built a model whit MultiGen V.11. In this model some objects are instanced more times. As you know, when the loader encounters one instance reference bead, it make a cloning operation. Now, I need to move at run-time some parts of these cloned instances, one instance independently from each other. In other words, I need to find the specific instance that I have to move, and his dynamic parts. The question is: How can I find the groups to move ? I couldn't find the names of the MultiGen groups that represent the instance, even in disabling the scene tree optimization in the loader. Thanks in Advance -------------------------- Marco Crocetta DATAMAT SpA, Rome E-Mail: onyx@datamat.it -------------------------- From guest Wed Dec 14 03:14:36 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA16115; Wed, 14 Dec 1994 02:56:19 -0800 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 CAA16112; Wed, 14 Dec 1994 02:56:14 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA06715; Wed, 14 Dec 94 02:56:09 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id CAA21536; Wed, 14 Dec 1994 02:56:07 -0800 Received: from scorpio.hongkong.sgi.com by sgihub.corp.sgi.com via ESMTP (940519.SGI.8.6.9/911001.SGI) id CAA09761; Wed, 14 Dec 1994 02:55:57 -0800 Received: by scorpio.hongkong.sgi.com (940816.SGI.8.6.9/930416.SGI) id RAA12700; Wed, 14 Dec 1994 17:18:22 -0800 From: "Samuel KM Lo" Message-Id: <9412141718.ZM12698@scorpio.hongkong.sgi.com> Date: Wed, 14 Dec 1994 17:18:21 -0800 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: subscribe Cc: hall@yvonne.arch.cuhk.hk, anton-lam@cuhk.hk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Please subscribe the following persons who are our existing educational users in Performer , thanks anton-lam@cuhk.hk hall@yvonne.arch.cuhk.hk -- @@ @@ @@@ @@@ @@@@@ @@@@@ @@@ @@ @@ @@@ @@@ @@ @@ @@@ @@@@ @@ @@ @@@@ @@ @@@ @@ @@ @@@ @@ Samuel KM LO | tel: (852)784-3837 @@ @@@@ @@@@ @@ Sales Manager | fax: (852)778-9100 @@ @@@ @@ @@@ @@ Silicon Graphics | vm #: 58143 @@ @@ @@@@@@ @@ @@ South China & | mailstop: IHK 355 @@@@ @@@ @@ @@@ @@@@ Hong Kong Region | samuel@hongkong.sgi.com @@ @@ @@ @@ @@ @@ ----------------------------------------------- @@ @@ @@ @@ Units 513-522 HK Industrial Technology Centre, @@ @@ @@ @@ 72 Tat Chee Avenue, Kowloon, Hong Kong. @@@ @@ @@ @@@ ------------------------------------------- @@@@@ @@@@@ - Seek the time - @@@ @@@ @@ @@ From guest Wed Dec 14 09:45:42 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA16547; Wed, 14 Dec 1994 09:27:35 -0800 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 JAA16544; Wed, 14 Dec 1994 09:27:31 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA13891; Wed, 14 Dec 94 09:27:29 -0800 Received: from cae.ca by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id JAA16885; Wed, 14 Dec 1994 09:27:23 -0800 Received: by cae.ca (4.1/SMI-4.1) id AA12034; Wed, 14 Dec 94 12:27:29 EST Date: Wed, 14 Dec 94 12:27:29 EST From: jfr@cae.ca (Jean-Francois Richard) Message-Id: <9412141727.AA12034@cae.ca> To: info-performer@sgi.sgi.com Subject: GState corruption Status: O From guest Wed Dec 14 09:45:46 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA16552; Wed, 14 Dec 1994 09:28:32 -0800 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 JAA16549; Wed, 14 Dec 1994 09:28:31 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA13926; Wed, 14 Dec 94 09:28:27 -0800 Received: from cae.ca by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id JAA16984; Wed, 14 Dec 1994 09:28:19 -0800 Received: by cae.ca (4.1/SMI-4.1) id AA12237; Wed, 14 Dec 94 12:28:30 EST Date: Wed, 14 Dec 94 12:28:30 EST From: jfr@cae.ca (Jean-Francois Richard) Message-Id: <9412141728.AA12237@cae.ca> To: info-performer@sgi.sgi.com Subject: GeoState corruption Status: O Hi everybody. I'm currently trying to integrate into my Performer program the great looking Flight format models that the good folks at Viewpoint were giving away at I/ITSEC. The problem is that the models are doing something to the lighting and/or material definitions (I'm not exactly sure which) that affects the lighting over the rest of the displayed scene. I am specifying default lights and light model and I tried adding a default material (pfApplyMtl( pfNewMtl( ... ) ) ) but the overall lighting still changes after one of the Viewpoint models is displayed. All my database geosets have geostates that do not specify lighting or material characteristics. These are all set globally, but, according to the pfGeoState man page, should be restored from the global state before the database's local geostates are applied. The following note from the pfGeoState man page attracted my attention: >> In some situations it may appear that pfGeoStates do inherit from each >> other. This is because IRIS Performer currently does not provide any >> defaults for the state attributes listed above such as PFSTATE_TEXTURE >> and PFSTATE_FRONTMTL. Consequently, if the application does not expli- >> citly set these attributes, it is possible for pfGeoStates which inherit >> these attributes to inherit them from previous pfGeoStates. Ok, so maybe there is a global state attribute I am not setting that is being changed by the Viewpoint models. The phrase "such as PFSTATE_TEXTURE and PFSTATE_FRONTMTL" seems a bit vague to me. What exactly are all the modes and attributes I should watch out for? I am specifying a global front material, and local textures, so is there anything else I should set? Is there an elegant way of insuring that an imported model or database leaves the graphics state unchanged after it gets drawn (without having to push/pop the state in pre/post-draw callbacks)? This isn't exactly a matter of life and death and I'm sure I could hack my way around it but I am curious about what exactly is going on here. Anybody knows the right way of dealing with this? ------------------------------------------------------------------- J.F. Richard CAE Electronics Ltd Montreal, Canada ------------------------------------------------------------------- From guest Wed Dec 14 13:38:32 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA17648; Wed, 14 Dec 1994 13:24:26 -0800 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 NAA17645; Wed, 14 Dec 1994 13:24:25 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA23967; Wed, 14 Dec 94 13:24:23 -0800 Received: from sgidev.mdc.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id NAA21866; Wed, 14 Dec 1994 13:24:14 -0800 Received: from marge.mdc.com by sgidev.mdc.com via SMTP (920213.SGI.UNSUPPORTED.PROTOTYPE/920323.SGI.UNSUPPORTED.PROTOTYPE) for info-performer@sgi.com id AA17422; Wed, 14 Dec 94 12:47:35 -0800 Received: by marge.mdc.com (931110.SGI/910805.SGI) for @sgidev.mdc.com:jrohlf@tubes.asd.sgi.com id AA28992; Wed, 14 Dec 94 13:41:05 -0800 From: "Salvador Cabaruvias" Message-Id: <9412141341.ZM28990@marge.mdc.com> Date: Wed, 14 Dec 1994 13:41:04 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: pfFrust Questions Cc: jrohlf@tubes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Dec 5, 2:57pm, John Rohlf wrote: > Subject: Re: pfFrust Questions > > > > To: info-performer@sgi.com > > Subject: pfFrust Questions > > ---text follows this line--- > > Hi, I'm new to Performer. We are running Performer 1.2 on Onyx with 6 cpus > > and 2 graphic pipes with 2 RM5s per pipe. We are using the Onyx to be our OTW > > image generator for our C17 simulator. > > > > The setup is a 2 channel system with the pilot and copilot sharing the same > > front channel and the pilot having a separate side view channel. We are > > using a wide angle collimated optics (WACO) system with the pilot side having > > zero gap mirrors for his front and side views (two channels). > > > > Now for my question: > > > > The WACO system has 45 degrees HFOV (hortizontal fiew of view) and 36 VFOV > > (vertical fiew of view). In addition, there is a 3 degree pitch in the > > VFOV to provide more down view angle. > > > > Using the pfMakeSimpleFrust and pfChanViewOffsets, I can setup the two > > channels but I can't account for the 3 degs of pitch. The way it's explained > > to me, is that 36 VFOV is +25 from the center and -31 down. Using the > > pfChanViewOffsets to add in the 3 degs simply makes a side window that is > > pitched down 3 degrees. This is not the affect I want. I want the window > > to stay at the original center line but with more down viewing angle. This > > is critical since we are using a real HUD. When we on the runway, the horizon > > is not where it should be when viewing thru the HUD with/out the 3 degs > > using the pfChanViewOffsets command. > > > > > > Has anyone done this before? Would you mind pointing me in the right > > direction? What are the calculations/calls I need to get this to align up? > > > > Thanks in advance, > > > > sal > > > > > > > > ----------------------------------------------------------------------------- > > Salvador Cabaruvias |email: sal@sgidev.mdc.com > > CSSL |saying: "Well I be done seen about > > McDonnell Douglas | everything when I see elephant > > (310) 593-6719 | fly!" --- Dumbo --- > > ----------------------------------------------------------------------------- > > > > > > Try this: > > pfFrustAspect(chan, PFFRUST_CALC_NONE); /* Needed to workaround a bug*/ > pfChanAutoAspect(chan, PFFRUST_CALC_NONE); > pfFrustNearFar(chan, near, far); > pfMakePerspFrust(chan, > -near * pfTan(22.5f), /* left */ > near * pfTan(22.5f), /* right */ > -near * pfTan(25.0f), /* bottom */ > near * pfTan(31.0f)); /* top */ > > > >-- End of excerpt from John Rohlf This did the trick with of course corrections for my math! The actual parameters were: 24 degs for both horizontals and 15 degs top Vertical and 21 degs bottom Vertical Thanks a bunch, sal From guest Wed Dec 14 20:01:29 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA18853; Wed, 14 Dec 1994 19:44:12 -0800 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 TAA18850; Wed, 14 Dec 1994 19:44:07 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA06998; Wed, 14 Dec 94 19:44:02 -0800 Received: from netcom.netcom.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id TAA14851; Wed, 14 Dec 1994 19:43:54 -0800 Received: by netcom.netcom.com (8.6.9/Netcom) id TAA18764; Wed, 14 Dec 1994 19:43:58 -0800 Date: Wed, 14 Dec 1994 19:43:58 -0800 From: chf@netcom.com (Cynthia H. Ferguson) Message-Id: <199412150343.TAA18764@netcom.netcom.com> To: info-performer@sgi.sgi.com Subject: pipe problems Status: O I am developing a VR authoring system using Performer. I would like to close a pipe and then reopen it in the same application. The motivation for this is so the user could close a view of a world and then open another one (of the same world or different world). I have tried using a Boolean which is set to false like this : if (firstTime) pfInit(); . . . . if (firstTime) { pfMultiprocess(WHATEVER); pfConfig(); firstTime = false; } and I found that the pipe didn't like the second pfInitPipe call. Without that second pfInitPipe call, the pipe doesn't know what GLX window to use for rendering so it defaults to the lower left corner of my screen and nothing is seen in that window (all black). (Everything works fine the first time around.) I would like the rendering to occur in the GLX window I created with its control panel, etc. Does anyone have any suggestions on how to work around this? Will pfExit() still exit to the OS in the next version of Performer? Cindy Talisman Dynamics, Inc. From guest Thu Dec 15 01:23:08 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA19622; Thu, 15 Dec 1994 01:05:42 -0800 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 BAA19619; Thu, 15 Dec 1994 01:05:37 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA12329; Thu, 15 Dec 94 01:05:36 -0800 Received: from bvr.co.il by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id BAA03441; Thu, 15 Dec 1994 01:03:06 -0800 Received: from prince.bvr.co.il by bvr.co.il via SMTP (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA03414; Thu, 15 Dec 94 11:03:03 +0200 Received: by prince.bvr.co.il (931110.SGI/911001.SGI) for @owl.bvr.co.il:info-performer@sgi.com id AA03588; Thu, 15 Dec 94 10:56:45 +0200 From: "Ran Yakir" Message-Id: <9412151056.ZM3586@prince.bvr.co.il> Date: Thu, 15 Dec 1994 10:56:40 +0000 In-Reply-To: dslayton@nvl.army.mil (David Slayton) "range finding from Z-Buffer values" (Dec 12, 10:21am) References: X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: dslayton@nvl.army.mil (David Slayton) Subject: Re: range finding from Z-Buffer values Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Dave, To begin with, you can not read Z buffer values, using lrectread(), when using multisampling. What it means is that you have to turn pfAntialias to OFF for it to work. Second, there is a bug in the RealityEngine graphics - zclear() always clears the Z buffer to a constant value, regardless of the values of getgconfig() or getgdesc(). 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-3-6995364 | Fax : 972-3-5715668 | From guest Thu Dec 15 07:30:49 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA20229; Thu, 15 Dec 1994 07:11:56 -0800 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 HAA20226; Thu, 15 Dec 1994 07:11:55 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA18097; Thu, 15 Dec 94 07:11:50 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id HAA20716; Thu, 15 Dec 1994 07:11:48 -0800 Received: from orca by sgihub.corp.sgi.com via ESMTP (940519.SGI.8.6.9/911001.SGI) for id HAA15615; Thu, 15 Dec 1994 07:11:47 -0800 Received: by orca (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA18987; Thu, 15 Dec 1994 09:11:00 -0600 From: "Howard Lo" Message-Id: <9412150910.ZM18985@orca.dallas.sgi.com> Date: Thu, 15 Dec 1994 09:10:56 -0600 In-Reply-To: "Lance R. Marrou" "Re: performer and FORMS library" (Dec 14, 2:15am) References: X-Mailer: Z-Mail (3.2.0 15oct94 MediaMail) To: "Lance R. Marrou" , Desmond Hii Toh Onn Subject: Re: performer and FORMS library Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 14, 2:15am, Lance R. Marrou wrote: > Subject: Re: performer and FORMS library > On Tue, 13 Dec 1994, Desmond Hii Toh Onn wrote: > > > Has anyone tried integrating Forms and performer? > > what are the issues involved? > Is there a reason NOT to use X/Motif ? --hl From guest Thu Dec 15 08:47:56 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA20356; Thu, 15 Dec 1994 08:24:09 -0800 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 IAA20353; Thu, 15 Dec 1994 08:24:08 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19559; Thu, 15 Dec 94 08:24:01 -0800 Received: from rubb.rz.ruhr-uni-bochum.de by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id IAA26902; Thu, 15 Dec 1994 08:23:24 -0800 Received: from midnite.neurobiologie.ruhr-uni-bochum.de (midnite.neurobiologie.ruhr-uni-bochum.de [134.147.120.6]) by rubb.rz.ruhr-uni-bochum.de (8.5/8.5) with SMTP id RAA08629; Thu, 15 Dec 1994 17:23:09 +0100 Received: by midnite.neurobiologie.ruhr-uni-bochum.de (NX5.67c/NX3.0S) id AA04127; Thu, 15 Dec 94 17:21:57 +0100 Date: Thu, 15 Dec 94 17:21:57 +0100 From: "Dr. Markus Lappe" Message-Id: <9412151621.AA04127@midnite.neurobiologie.ruhr-uni-bochum.de> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: info-performer@sgi.sgi.com Subject: Clear Screen is too slow, what else? Reply-To: lappe@neurobiologie.ruhr-uni-bochum.de Status: O I am trying to speed up the frame rate of an animation that simulates periodic movement towards only a few simple white star-like objects. Most of the screen is black and by far the greatest amount of drawing time is spent clearing the screen, i.e. drawing a black pfESky. Thus, I decided to use a draw function callback that only draws the objects and does not perform a screen clear. To remove the objects drawn in the previous frame I created a second channel that is supposedly rendered first. The draw function callback of this channel is supposed to draw the the same objects as seen from the previous viewpoint, but with the color of the objects set to black, the background color. To achieve the color change, I issued a cpack(0xFFFFFFFF) in the draw function callback of the channel supposed to draw white objects from the new viewpoint and a cpack(0xFF000000) in the draw function callback of the channel supposed to draw black objects from the old viewpoint. However, instead of the movement of the objects I get a superimposed view of the trajectory, i.e. the clearing of the old view does not seem to work. The program I use is a small variation of the simple.c example. It is short enought to be included with this mail. I also include a sample data file "one_object.obj" that I use. I am using an Indigo 2 XZ running IRIX 5.2. Does anybody have an idea what I am doing wrong? Thanks, Markus -------------------swing.c-------------------- #include #include #include #include #include #include #include "pfsgi.h" void DrawFunc(pfChannel *chan, void *data); void DrawFunc2(pfChannel *chan, void *data); int main (int argc, char *argv[]) { float t = 0.0f; pfScene *scene; pfPipe *p; pfChannel *chan,*chan2; pfNode *root; int draw_oldview; /* Initialize Performer */ pfInit(); /* Use default multiprocessing mode based on number of * processors. */ pfMultiprocess(PFMP_DEFAULT); /* Configure multiprocessing mode and start parallel * processes. */ pfConfig(); /* Configure and open pipe */ p = pfGetPipe(0); pfInitPipe(p, NULL); /* Append to PFPATH files in /usr/src/Performer/data */ pfFilePath(".:/usr/src/Performer/data"); /* Create a pfScene. */ scene = pfNewScene(); /* Create and configure a pfChannel. */ chan = pfNewChan(p); pfChanScene(chan, scene); pfChanNearFar(chan, 0.01f, 30.0f); pfChanFOV(chan, 45.0f, 0.0f); pfChanDrawFunc(chan, DrawFunc); /* Create and configure a second pfChannel. */ chan2 = pfNewChan(p); pfAttachChan(chan,chan2); pfChanShare(chan, PFCHAN_SWAPBUFFERS | PFCHAN_FOV | PFCHAN_NEARFAR | PFCHAN_SCENE | PFCHAN_EARTHSKY); pfChanDrawFunc(chan2, DrawFunc2); /* Read a single file, of any known type. */ if ((root = LoadFile(argv[1], NULL)) == NULL) { pfExit(); exit(-1); } /* Attach loaded file to a pfScene. */ pfAddChild(scene, root); draw_oldview = 0; pfInitClock (0.0f); /* Simulate */ while (t<5) { float s, c; pfCoord view; float phi; /* Go to sleep until next frame time. */ pfSync(); /* Compute new view position. */ t = pfGetTime(); /* Compute new viewpoint. */ /* Swing. */ phi = 4.0 * sin(sqrt(9.81 / 3.5) * t); pfSinCos(phi, &s, &c); pfSetVec3(view.xyz, 0.0f, 0.0f + 3.5f * s, - 3.5f + 3.5f * c); /* Compute new gaze direction. */ pfSetVec3(view.hpr, 0.0f, 0.0f, 0.0f); pfChanView(chan2, view.xyz, view.hpr); /* Initiate cull/draw for this frame. */ if(draw_oldview==1) pfFrame(); draw_oldview = 1; pfChanView(chan, view.xyz, view.hpr); } /* Terminate parallel processes and exit. */ pfExit(); return 0; } void DrawFunc(pfChannel *chan, void *data) { cpack(0xFF000000); pfDraw(); } void DrawFunc2(pfChannel *chan, void *data) { cpack(0xFFFFFFFF); pfDraw(); } -------------------one_object.obj------------- v -0.099391 0.800000 -0.166105 v -0.097226 0.800000 -0.167355 v -0.095061 0.800000 -0.166105 v -0.095061 0.800000 -0.163605 v -0.097226 0.800000 -0.162355 v -0.099391 0.800000 -0.163605 f 1 2 3 4 5 6 From guest Thu Dec 15 09:47:44 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA20546; Thu, 15 Dec 1994 09:29:03 -0800 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 JAA20543; Thu, 15 Dec 1994 09:28:46 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA21991; Thu, 15 Dec 94 09:28:44 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id JAA04282; Thu, 15 Dec 1994 09:28:42 -0800 Received: from grail.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA08235; Thu, 15 Dec 94 12:29:57 EST Received: by grail.vsl.ist.ucf.edu (920330.SGI) id AA29945; Thu, 15 Dec 94 12:29:12 -0500 Date: Thu, 15 Dec 1994 12:29:12 -0500 (EST) From: "Lance R. Marrou" To: Howard Lo Cc: info-performer@sgi.sgi.com Subject: Re: performer and FORMS library In-Reply-To: <9412150910.ZM18985@orca.dallas.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Thu, 15 Dec 1994, Howard Lo wrote: > Is there a reason NOT to use X/Motif ? Yes. It is far easier to use the FORMS form designer. Much more intuitive. Maybe one exists, but I have found nothing similar to aid in creating X widgets and the like. Nor is there anything like the browser object. Nor is it as easy to create new widget objects. For a quick, yet pleasant, interface, X leaves much to be desired. Now, is there a reason TO use X/Motif? Only speed and portability. Personally, I could care less about portability. If it doesn't run on an SGI, then it won't run. ;) Now, before you respond, understand that (for the issue of speed alone) I recommend the switch to X/Motif. In fact, I am struggling with it now. If, by some remarkable chance, you have an Xdesigner, please send it to me. _______________________________________________________ E-mail: marrou@vsl.ist.ucf.edu IST __ WWW: http://www.vsl.ist.ucf.edu/~marrou Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Thu Dec 15 10:10:35 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA20566; Thu, 15 Dec 1994 09:46:32 -0800 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 JAA20563; Thu, 15 Dec 1994 09:46:27 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA22738; Thu, 15 Dec 94 09:46:18 -0800 Received: from post.demon.co.uk by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id JAA06534; Thu, 15 Dec 1994 09:46:08 -0800 Received: from division.demon.co.uk by post.demon.co.uk id aa24077; 15 Dec 94 17:45 GMT Received: from [192.9.200.12] by division.demon.co.uk (AIX 3.2/UCB 5.64/4.03) id AA16541; Thu, 15 Dec 1994 17:48:32 GMT Received: by caliban.division.demon.co.uk (931110.SGI/921111.SGI) for @division.demon.co.uk:info-performer@holodeck.asd.sgi.com id AA18596; Thu, 15 Dec 94 17:41:49 GMT From: Angus Dorbie Message-Id: <9412151741.ZM18594@caliban.division.demon.co.uk> Date: Thu, 15 Dec 1994 17:41:48 +0000 In-Reply-To: "Dr. Markus Lappe" "Clear Screen is too slow, what else?" (Dec 15, 5:21pm) References: <9412151621.AA04127@midnite.neurobiologie.ruhr-uni-bochum.de> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: lappe@neurobiologie.ruhr-uni-bochum.de Subject: Re: Clear Screen is too slow, what else? Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > Thus, I decided to use a draw function callback that only draws the > objects and does not perform a screen clear. > To remove the objects drawn in the previous frame I created a second > channel that is supposedly rendered first. The draw function callback > of this channel is supposed to draw the the same objects as seen from > the previous viewpoint, but with the color of the objects set to > black, the background color. To achieve the color change, I issued a > cpack(0xFFFFFFFF) in the draw function callback of the channel > supposed to draw white objects from the new viewpoint and a > cpack(0xFF000000) in the draw function callback of the channel > supposed to draw black objects from the old viewpoint. Hi Marcus, the problem with your example code is that it it doesn't account for double buffering. The last view drawn (and the one you try to erase with black) is in the frontbuffer while you are drawing to the backbuffer. Try erasing using the view position of two frames ago. You will probably also have to disable the zbuffer in some way. Regards, -- ________________________________________________ Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.demon.co.uk UK ________________________________________________ From guest Thu Dec 15 10:41:30 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA20670; Thu, 15 Dec 1994 10:25:53 -0800 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 KAA20667; Thu, 15 Dec 1994 10:25:40 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA24382; Thu, 15 Dec 94 10:25:34 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id KAA12161; Thu, 15 Dec 1994 10:25:31 -0800 Received: from hawkeye.newport.sgi.com by sgihub.corp.sgi.com via ESMTP (940519.SGI.8.6.9/911001.SGI) for id KAA02443; Thu, 15 Dec 1994 10:25:30 -0800 Received: by hawkeye.newport.sgi.com (940816.SGI.8.6.9/911001.SGI) id KAA18997; Thu, 15 Dec 1994 10:25:01 -0800 From: millard@hawkeye.newport.sgi.com (Ed Millard) Message-Id: <199412151825.KAA18997@hawkeye.newport.sgi.com> Subject: Re: performer and FORMS library To: marrou@vsl.ist.ucf.edu (Lance R. Marrou) Date: Thu, 15 Dec 1994 10:25:01 -0800 (PST) Cc: hlo@orca.dallas.sgi.com, info-performer@sgi.sgi.com In-Reply-To: from "Lance R. Marrou" at Dec 15, 94 12:29:12 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1709 Status: O > > On Thu, 15 Dec 1994, Howard Lo wrote: > > > Is there a reason NOT to use X/Motif ? > > Yes. It is far easier to use the FORMS form designer. Much more intuitive. > Maybe one exists, but I have found nothing similar to aid in creating X > widgets and the like. Nor is there anything like the browser object. Nor > is it as easy to create new widget objects. For a quick, yet pleasant, > interface, X leaves much to be desired. > > Now, is there a reason TO use X/Motif? Only speed and portability. > Personally, I could care less about portability. If it doesn't run on an SGI, > then it won't run. ;) > > Now, before you respond, understand that (for the issue of speed alone) I > recommend the switch to X/Motif. In fact, I am struggling with it now. If, > by some remarkable chance, you have an Xdesigner, please send it to me. > There is a 3rd party GUI designed called builderXcessory which is widely used within SGI. It provides a visual front end for widget placement and design and then outputs Motif or Viewkit code. There is a demo version available on some of the HotMix CD's. Doug Young's Viewkit should also be investigated. It provides an object oriented layer on top of Motif to simply Motif UI programming. It is especially good for those who like C++. Viewkit is used in SGI products like WorkShop. ============================================================================= Ed Millard | 18201 Von Karman Avenue Silicon Graphics Inc. | Suite 100 Developer's Support Group | Irvine, CA 92715 millard@sgi.com | (714) 756-5975 ============================================================================= From guest Thu Dec 15 11:54:02 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA20954; Thu, 15 Dec 1994 11:36:33 -0800 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 LAA20951; Thu, 15 Dec 1994 11:36:28 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA27761; Thu, 15 Dec 94 11:36:24 -0800 Received: from server1.ctc.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id LAA24526; Thu, 15 Dec 1994 11:36:21 -0800 Received: by server1.ctc.com (5.65/DEC-Ultrix/4.3) id AA15640; Thu, 15 Dec 1994 14:01:04 -0500 Received: by sgi81.ctc.com (931110.SGI/921111.SGI.AUTO) for @server1.ctc.com:info-performer@sgi.com id AA22802; Thu, 15 Dec 94 14:00:47 -0500 Date: Thu, 15 Dec 94 14:00:47 -0500 From: koopman@ctc.com (Michael G. Koopman) Message-Id: <9412151900.AA22802@sgi81.ctc.com> To: marrou@vsl.ist.ucf.edu, hlo@orca.dallas.sgi.com Cc: info-performer@sgi.sgi.com In-Reply-To: "Lance R. Marrou"'s message of Thu, 15 Dec 1994 12:29:12 -0500 (EST) Subject: performer and FORMS library Reply-To: koopman@ctc.com Status: O Lance R. Marrou: > If, by some remarkable chance, you have an Xdesigner, please send it > to me. Did you intend to straif a product name? Xdesigner comes recommended as a product which make X/Motif design livable. You might try your third party software rep, tell 'em Roy from records sent you the fix. Though it don't do pfBillboards (only Xwindows) to my knowledge. Another 3x5 card cliff noted, summarily by, Mike Koopman internet: koopman@ctc.com phone: +1-814-269-2637 From guest Thu Dec 15 12:41:20 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA21048; Thu, 15 Dec 1994 12:26:28 -0800 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 MAA21045; Thu, 15 Dec 1994 12:26:23 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA29854; Thu, 15 Dec 94 12:26:26 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id MAA02522; Thu, 15 Dec 1994 12:26:25 -0800 Received: from orca by sgihub.corp.sgi.com via ESMTP (940519.SGI.8.6.9/911001.SGI) for id MAA13941; Thu, 15 Dec 1994 12:26:23 -0800 Received: by orca (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA12213; Thu, 15 Dec 1994 14:25:35 -0600 From: "Howard Lo" Message-Id: <9412151425.ZM12211@orca.dallas.sgi.com> Date: Thu, 15 Dec 1994 14:25:32 -0600 In-Reply-To: "Lance R. Marrou" "Re: performer and FORMS library" (Dec 15, 12:29pm) References: X-Mailer: Z-Mail (3.2.0 15oct94 MediaMail) To: "Lance R. Marrou" Subject: Re: performer and FORMS library Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 15, 12:29pm, Lance R. Marrou wrote: > Subject: Re: performer and FORMS library > On Thu, 15 Dec 1994, Howard Lo wrote: > > > Is there a reason NOT to use X/Motif ? > > Yes. It is far easier to use the FORMS form designer. Much more intuitive. > Maybe one exists, but I have found nothing similar to aid in creating X > widgets and the like. Nor is there anything like the browser object. Nor > is it as easy to create new widget objects. For a quick, yet pleasant, > interface, X leaves much to be desired. > > Now, is there a reason TO use X/Motif? Only speed and portability. > Personally, I could care less about portability. If it doesn't run on an SGI, > then it won't run. ;) > > Now, before you respond, understand that (for the issue of speed alone) I > recommend the switch to X/Motif. In fact, I am struggling with it now. If, > by some remarkable chance, you have an Xdesigner, please send it to me. I use Builder Accessory for creating my widgets and find that creating an interface is indeed intuitive. X/Motif has a lot more features. Drop pockets, drag and drop, thumbwheels, sliders, ... Customization is easier too, you can you Schemes to implement a cohesive color scheme, change fonts, etc... X/Motif is also more widely used, so support is easier. There are thousands of X/Motif programmers out there that you can hire to maintain your interface and build new one. Just some thought... --hl > > _______________________________________________________ > E-mail: marrou@vsl.ist.ucf.edu > IST __ WWW: http://www.vsl.ist.ucf.edu/~marrou > Visual / / ______ /\____ ______ ______ > Systems / / / _ / / __ // ____// ____/ > Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou > ________/____//____/\\/_/ /_//_____//_____/____________ > > >-- End of excerpt from Lance R. Marrou From guest Thu Dec 15 13:17:37 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA21131; Thu, 15 Dec 1994 13:01:23 -0800 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 NAA21128; Thu, 15 Dec 1994 13:01:22 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA01196; Thu, 15 Dec 94 13:01:22 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id NAA07167; Thu, 15 Dec 1994 13:01:20 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id NAA16602; Thu, 15 Dec 1994 13:01:18 -0800 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:chf@netcom.com id AA01182; Thu, 15 Dec 94 13:01:13 -0800 Received: by rose.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA04057; Thu, 15 Dec 1994 13:01:01 -0800 From: "Sharon Clay (Fischler)" Message-Id: <9412151301.ZM4055@rose.asd.sgi.com> Date: Thu, 15 Dec 1994 13:01:01 -0800 In-Reply-To: chf@netcom.com (Cynthia H. Ferguson) "pipe problems" (Dec 14, 7:43pm) References: <199412150343.TAA18764@netcom.netcom.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: chf@netcom.com (Cynthia H. Ferguson), info-performer@sgi.sgi.com Subject: Re: pipe problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Dec 14, 7:43pm, Cynthia H. Ferguson wrote: > Subject: pipe problems -> ->I am developing a VR authoring system using Performer. I would like ->to close a pipe and then reopen it in the same application. The motivation ->for this is so the user could close a view of a world and then open ->another one (of the same world or different world). FYI: Performer 2.0 will directly support this type of functionality. Channels will be assigned to windows and pfPipes will be able to have multiple windows. You will be able to create/close new windows at run-time. All of the channels and windows of a pfPipe will have to be on the same screen and will share the same draw process. This functionality will be supported for IRIS GL, Mixed Mode IRIS GL, and OpenGL. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Graphics Dev. src@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Fri Dec 16 08:25:45 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA22882; Fri, 16 Dec 1994 08:03:55 -0800 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 IAA22879; Fri, 16 Dec 1994 08:03:50 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA28471; Fri, 16 Dec 94 08:03:46 -0800 Received: from Lightning.McRCIM.McGill.EDU by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id IAA11933; Fri, 16 Dec 1994 08:03:44 -0800 Received: from Athena.McRCIM.McGill.EDU by Lightning.McRCIM.McGill.EDU (8.6.9) with ESMTP id <199412161600.LAA07967@Lightning.McRCIM.McGill.EDU>; Fri, 16 Dec 1994 11:00:13 -0500 From: Jean-Francois Panisset Received: (panisset@localhost) by Athena.McRCIM.McGill.EDU (8.6.9/8.6.9) id LAA02089 for info-performer@sgi.com; Fri, 16 Dec 1994 11:03:20 -0500 Date: Fri, 16 Dec 1994 11:03:20 -0500 Message-Id: <199412161603.LAA02089@Athena.McRCIM.McGill.EDU> To: info-performer@sgi.sgi.com Subject: Looking for past mail (and list archival) Status: O Sorry to bother everyone with a borderline administrative request... I'm looking for a message which appeared on this list within the last week or two and which discussed how to precisely align textures and avoid half pixel shifts: I forgot to save it away when I first read it, and it turns out I could very much use the information now. If anyone has a copy of it, I would very much appreciate if you could mail it to me. On a related note, is the info-performer list no longer being archived? I've looked in sgigate.sgi.com:pub/Performer/monthly-archives, but the most recent archive appears to be for June 94... It would be a shame if it were no longer being done, as I find the quality of the information available on this list to be very high. Thanks in advance, Jean-Francois From guest Fri Dec 16 09:29:26 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA22991; Fri, 16 Dec 1994 09:12:47 -0800 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 JAA22988; Fri, 16 Dec 1994 09:12:46 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA00477; Fri, 16 Dec 94 09:12:41 -0800 Received: from netcom.netcom.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id JAA19414; Fri, 16 Dec 1994 09:12:39 -0800 Received: by netcom.netcom.com (8.6.9/Netcom) id JAA27972; Fri, 16 Dec 1994 09:12:42 -0800 Date: Fri, 16 Dec 1994 09:12:41 -0800 (PST) From: "Paul S. Cutt" To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Can you please add me to your subscription list ? Thanks, Paul From guest Fri Dec 16 12:29:15 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA23708; Fri, 16 Dec 1994 12:12:29 -0800 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 MAA23705; Fri, 16 Dec 1994 12:12:28 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA09907; Fri, 16 Dec 94 12:12:27 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id MAA19761; Fri, 16 Dec 1994 12:12:26 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id MAA10071; Fri, 16 Dec 1994 12:12:23 -0800 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:halliday@banffcentre.ab.ca id AA09902; Fri, 16 Dec 94 12:12:20 -0800 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA01662; Fri, 16 Dec 1994 12:12:19 -0800 Message-Id: <199412162012.MAA01662@surreal.asd.sgi.com> To: halliday@banffcentre.ab.ca (Sean Halliday) Cc: info-performer@sgi.sgi.com Subject: Re: Multiprocessing. In-Reply-To: Your message of "Tue, 13 Dec 94 14:01:27 MST." <9412132101.AA03059@grizzly.BanffCentre.AB.CA> Date: Fri, 16 Dec 94 12:12:15 -0800 From: Jim Helman Status: O Performer handles data synchronization using multiple copies for libpf objects for APP, CULL and ISECT. With forked DRAW, the DRAW uses a pfDispList which includes things like matrices passed by value. This allows processes to have access to the data almost all the time, as well as providing frame-accurate data propagation. The alternative is single copy with locks, but this has performance implications because of possible contention for the lock. By contrast, libpr objects like geosets and geostates are not multibuffered. Performer 2.0 will have better support for multibuffering vertex and other geoset attribute arrays for handling dynamic geometry more conveniently. Currently, for safety, dynamic geometry must either be handled in the DRAW process or multibuffered by the application itself, e.g. with a pfSwitch node. sproc with only one thread rendering should work reliably. Multiple rendering threads requires locking and synchronization (e.g. gflush). It's conceivable that bad data could cause a pipe crash, but unlikely that valid floating point numbers such as those in a matrix would be a problem. There used to be a problem sending NaN's as normals, but it was fixed. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Dec 16 14:41:18 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA23900; Fri, 16 Dec 1994 14:25:53 -0800 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 OAA23897; Fri, 16 Dec 1994 14:25:49 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA17242; Fri, 16 Dec 94 14:25:47 -0800 Received: from eagle.lmsc.lockheed.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id OAA06759; Fri, 16 Dec 1994 14:25:45 -0800 Received: from sgi600.msd.lmsc.lockheed.com by eagle.lmsc.lockheed.com (5.65/DEC-Ultrix/4.3) id AA21970; Fri, 16 Dec 1994 14:24:43 -0800 Received: by sgi600.msd.lmsc.lockheed.com (931110.SGI/930416.SGI) for info-performer@sgi.com id AA13268; Fri, 16 Dec 94 14:25:42 -0800 Date: Fri, 16 Dec 94 14:25:42 -0800 From: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) Message-Id: <9412162225.AA13268@sgi600.msd.lmsc.lockheed.com> To: info-performer@sgi.sgi.com Subject: Any estimate of when Performer 2.0 will ship? Status: O I was wondering if the Performer Team would like to venture a best guess at a Performer 2.0 shipping date. 1st quarter 1995, 2nd quarter 1995, ... ? We are anxiously awaiting its arrival (especially the C++ bindings) and would like to make plans for the next year. Kenneth N. Sakai Email: sakai@lmsc.lockheed.com Research Specialist/Computer Graphics Phone: (408) 756-0682 Lockheed Missiles and Space Co. Sunnyvale, CA 94088-3504 From guest Fri Dec 16 15:27:04 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA23981; Fri, 16 Dec 1994 15:08:37 -0800 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 PAA23978; Fri, 16 Dec 1994 15:08:29 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA20217; Fri, 16 Dec 94 15:08:12 -0800 Received: from Arizona.EDU by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id PAA12886; Fri, 16 Dec 1994 15:08:06 -0800 Received: from crimson.mse.arizona.edu by Arizona.EDU (PMDF V4.3-10 #2381) id <01HKPTVYDOIOEWXOYR@Arizona.EDU>; Fri, 16 Dec 1994 16:07:58 -0700 (MST) Received: by crimson.mse.arizona.edu (931110.SGI/930416.SGI.AUTO) for @Hopey.Telcom.Arizona.EDU:info-performer@sgi.com id AA24338; Fri, 16 Dec 94 17:01:26 -0600 Date: Fri, 16 Dec 1994 17:01:24 -0700 From: "Frank J. Cherne" Subject: Re: Indigo Extreme II and Crystal Eyes To: info-performer@sgi.sgi.com Message-Id: <9412161701.ZM24336@crimson.mse.arizona.edu> Mime-Version: 1.0 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Status: O A while back, Jim Pinkerton, Univ. of New Mexico, was having trouble getting his crystal eyes to work properly on an Indigo Extreme. I too have been having trouble getting crystal eyes to work properly on a crimson VGXT system. It appears that I have found a solution to this problem. In my OpenPipeline subroutine which I use the equivalent to setmonitor(STR_RECT). Which then displays in a 120Hz steromode. Then my two channel viewports are set to the top and the bottom halves of the screen. This then overlays the two channels nicely. Then by adjusting the ChanViewOffsets and the Field's of view as illustrated in sfly, I was able to get a stereographic image. Now for my first question, we have a set of CrystalEyes and when we run the application in stereographic mode there appears to be some minor bleeding of the right image in the left eye and vice versa. Is there some way to correct this? Second question, being a newbie to performer and programming in general, how does on optimize computer code for speed? The code I have is a molecular dynamics simulation with a gl sphere for each atomic position for a total of 108 spheres. Based upon the Stats it appears that the Drawing portion of the routine takes the most amount of time. Frank J. Cherne III The University of Arizona From guest Fri Dec 16 17:10:27 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA24091; Fri, 16 Dec 1994 16:49:56 -0800 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 QAA24088; Fri, 16 Dec 1994 16:49:55 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA26936; Fri, 16 Dec 94 16:49:53 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id QAA27514; Fri, 16 Dec 1994 16:49:51 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id QAA06454; Fri, 16 Dec 1994 16:49:49 -0800 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:fjcherne@crimson.mse.arizona.edu id AA26924; Fri, 16 Dec 94 16:49:44 -0800 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA02346; Fri, 16 Dec 1994 16:49:43 -0800 Message-Id: <199412170049.QAA02346@surreal.asd.sgi.com> To: "Frank J. Cherne" Cc: info-performer@sgi.sgi.com Subject: Re: Indigo Extreme II and Crystal Eyes In-Reply-To: Your message of "Fri, 16 Dec 94 17:01:24 MST." <9412161701.ZM24336@crimson.mse.arizona.edu> Date: Fri, 16 Dec 94 16:49:40 -0800 From: Jim Helman Status: O > Now for my first question, we have a set of CrystalEyes and when we run the > application in stereographic mode there appears to be some minor bleeding of > the right image in the left eye and vice versa. Is there some way to correct > this? A number of things can conspire to cause this: 1) phosphor decay times (some green phosphors are especially bad), 2) LCD shutter extinction ratio (this tends to be particularly an issue near the edges of the LCD), 3) LCD shutter transition times. Most monitor phosphors are fast enough that #1 is not a problem (although for video projection tubes with a special green phosphor are available and do make a difference). I believe the largest problem with desktop stereo is usually #2. From what I've seen, the large polarization shutters that sit in front of the screen (like Tektronix) tend to have better extinction ratios and less ghosting than shutter glasses, but they are considerably more expensive for single-viewer use. While not addressing the fundamental problem, using a background with less contrast (e.g. gray instead of black) may reduce the percieved severity of the ghosting. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sun Dec 18 23:56:09 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA26260; Sun, 18 Dec 1994 23:11:39 -0800 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 XAA26257; Sun, 18 Dec 1994 23:11:31 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA05333; Sun, 18 Dec 94 23:11:24 -0800 Received: from mail.swip.net by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id XAA25825; Sun, 18 Dec 1994 23:11:22 -0800 Received: by mail.swip.net with UUCP (8.6.8/3.01) id IAA20364; Mon, 19 Dec 1994 08:12:56 +0100 Received: from pkabpc4.prosolvia.se by filip.konsult.prosolvia.se via SMTP (931110.SGI/930416.SGI.AUTO) for seunet!sgi.com!info-performer id AA18253; Mon, 19 Dec 94 08:11:21 -0800 Date: Mon, 19 Dec 94 08:11:21 -0800 Message-Id: <9412191611.AA18253@filip.konsult.prosolvia.se> X-Sender: stefan@128.0.0.26 X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: info-performer@sgi.sgi.com From: stefan%filip@mail.swip.net (Stefan Hallin) Subject: subscribe Status: O please enter my subscription Med v=E4nlig h=E4lsning/Yours sincerely Stefan Hallin ----------------------------------------------- Stefan Hallin President Clarus AB Stora Badhusgatan 18-20 S-411 21 G=F6teborg Sweden Phone: +46 31 774 37 80 Fax: +46 31 13 54 71 Email: stefan@clarus.se ----------------------------------------------- From guest Mon Dec 19 02:45:38 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA26473; Mon, 19 Dec 1994 02:17:04 -0800 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 CAA26470; Mon, 19 Dec 1994 02:16:58 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA07022; Mon, 19 Dec 94 02:16:47 -0800 Received: from mail.swip.net by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id CAA04387; Mon, 19 Dec 1994 02:16:44 -0800 Received: by mail.swip.net with UUCP (8.6.8/3.01) id LAA24730; Mon, 19 Dec 1994 11:18:13 +0100 Received: from pc1.prosolvia.se by filip.konsult.prosolvia.se via SMTP (931110.SGI/930416.SGI.AUTO) for seunet!sgi.com!info-performer id AA19488; Mon, 19 Dec 94 11:16:52 -0800 Date: Mon, 19 Dec 94 11:16:52 -0800 Message-Id: <9412191916.AA19488@filip.konsult.prosolvia.se> X-Sender: frederik@128.0.0.26 X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: info-performer@sgi.sgi.com From: frederik%filip@mail.swip.net (Frederik Gustafsson) Subject: subscribe Status: O please enter my subscription Med v=E4nlig h=E4lsning/Yours sincerely Frederik Gustafsson Frederik Gustafsson Clarus AB Stora Badhusgatan 18-20 411 21 G=F6teborg Sweden Phone +46 31 774 37 80 Fax +46 31 13 54 71 "Step into Virtual Reality with Vega VR" From guest Mon Dec 19 07:31:39 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA26736; Mon, 19 Dec 1994 07:01:32 -0800 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 HAA26733; Mon, 19 Dec 1994 07:01:27 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA11672; Mon, 19 Dec 94 07:01:20 -0800 Received: from josef.ifi.unizh.ch by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id HAA18181; Mon, 19 Dec 1994 07:01:16 -0800 Message-Id: <199412191501.HAA18181@sgi.sgi.com> Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00360-0@josef.ifi.unizh.ch>; Mon, 19 Dec 1994 16:00:36 +0100 To: info-performer@sgi.sgi.com Subject: In Ordnung? Date: Mon, 19 Dec 1994 16:00:36 +0100 From: Martin Roth Sender: roth@ifi.unizh.ch Status: O Hi folks, I'm in big trouble. If anyone is willing to read the following (lot of) information, I'd be very glad. I NEED YOUR HELP!!! I'm building a GIS-application which is capable of changing the scene (i. e. loading new parts and removing old ones) at run-time. This is done by parallel loading processes that are sproc'ed from the APP. Further the user interacts with the application through a GUI built upon the FORMS-library. Because FORMS- calls may only take place in the DRAW-process, configuration data that: 1. might be changed by the user through the FORMS panels (DRAW) 2. is used within the loading processes (APP) has to be allocated in shared memory (hasn't it?!). Up to now I had two big structs allocated in shared memory. Both of them over- load the new and delete operators in order to do accurate Performer allocation in shared memory. struct SharedData { long example; ... void *operator new(size_t sz, void *a) {return pfMalloc(sz, a); } void *operator new(size_t sz) {return pfMalloc(sz, NULL);} void operator delete(void *addr) {pfFree(addr);} }; struct CfgData { long example; ... void *operator new(size_t sz, void *a) {return pfMalloc(sz, a); } void *operator new(size_t sz) {return pfMalloc(sz, NULL);} void operator delete(void *addr) { pfFree(addr);} }; In the main application two instances of these structs are allocated: SharedData *shared; CfgData *cfg; ... int main (int argc, char **argv) { void *arena; pfInit(); arena = pfGetSharedArena(); shared = new(arena) SharedData(); cfg = new(arena) CfgData(); fl_init(); // FORMS initialisation create_the_forms(); // creation of FORMS panels ... run the application ... pfExit(); } Using this version, everything worked fine. Except that it worked extremly slow. Sometimes it even stuck, without crashing, but nothing went on. The only explanation of this peculiar loss of speed was the following: Maybe it was due to the fact that the parallel processes had to access the same structs in shared memory, running into access conflicts. In this case the Performer synchronization facility would lock the whole struct when only accessing a single field. Fine, I thought, and changed the structs into a lot of normal pointer variables, allocated in shared memory. Getting a fine granularity seemed a good way to decrease the probability of running into access conflicts. To stuck with the example mentioned above, it now looked the following way: long *shared_example; ... long *cfg_example; ... int main (int argc, char **argv) { void *arena; pfInit(); arena = pfGetSharedArena(); shared_example = (long *)pfMalloc(sizeof(long), arena); shared_example = (long *)pfMalloc(sizeof(long), arena); fl_init(); // FORMS initialisation create_the_forms(); // creation of FORMS panels ... run the application ... pfExit(); } Fine, I thought again, and tried the thing. But the application which hadn't changed in any significant way just slipped into the Nirwana. I didn't even get a core dump, segmentation fault, bus error or something like that. The process just terminated. Now I started tracing the spot where the application would fail. And I found it within the fl_init() call. I had the following call stack: gl_g_winopen(); failure at line 766 in the (gl?!) file mex_window.c fl_init_colormap(); call to winopen at line 206 in the FORMS file draw.c fl_init(); call to fl_init_colormap at line 39 in the FORMS file support.c That means, my application didn't even make it through the initialization! Calling fl_init() never was a problem and worked fine till now. Now, for all those who haven't stopped reading that sad story, my questions: Does anyone know what is happening to my application? Does anyone know what things are made on line 766 in "mex_window.c"? Is it necessary to have that configuration stuff mentioned above in a shared memory arena or will the draw process (to be exact the FORMS panels) be able to access the configuration data anyway? (I tried allocating on the heap, the failure remained the same.) What exactly has to be in shared memory when using different process split models? Does anyone have an other explanation for my application being this slow when having two big structs in shared memory? If yes, do you have a remedy? Thanks for all those who made it through to that spot. Double thanks for all of you being able to give me some hints. Martin _______________________________________________________________________________ /| /|) S. H. Martin Roth / |/ |\OTH Student in Computer Science ETHZ, Swiss Federal Institute of Technology Zuerich email: sroth@iiic.ethz.ch UniZh, University of Zuerich email: roth@ifi.unizh.ch From guest Mon Dec 19 12:12:16 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA27146; Mon, 19 Dec 1994 11:51:29 -0800 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 LAA27143; Mon, 19 Dec 1994 11:51:25 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA20599; Mon, 19 Dec 94 11:51:16 -0800 Received: from gts07.elan.af.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id LAA23103; Mon, 19 Dec 1994 11:49:58 -0800 Received: by gts07.elan.af.mil (931110.SGI/930416.SGI) for info-performer@sgi.com id AA03590; Mon, 19 Dec 94 10:37:45 -0800 From: "Tracy Hunt" Message-Id: <9412191037.ZM3588@gts.elan.af.mil> Date: Mon, 19 Dec 1994 10:37:43 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Transformation Matrix Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Question: I have converted DMA data using MultiGen into terrain files with specific lats and longs or XY position. I want to place these files in their exact XY locations using pfNewSCS. How do I create the transformation matrix with the exact coordinates necessary for proper placement? Should I use a bounding sphere or is there another way without enter the coordinates by hand? I'm running Performer 1.2 on an Onyx with 5.2. ,,,, (o ~) /-----oOO--(_)--OOo--------\--------------------------------/ | Tracy Hunt | There was a time when / | Edwards AFB | religion ruled the world. / | Avionic Test & Evaluation| It was known as the / | Complex | Dark Ages. / | hunt@gts.elan.af.mil | / | | / | Tel: (805) 277-5212 | -Ruth Green / \--------------------------/--------------------------------/ -- Tracy Hunt From guest Mon Dec 19 16:27:51 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA28247; Mon, 19 Dec 1994 16:11:42 -0800 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 QAA28243; Mon, 19 Dec 1994 16:11:37 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA00463; Mon, 19 Dec 94 16:11:36 -0800 Received: from relay3.UU.NET by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id QAA04714; Mon, 19 Dec 1994 16:11:34 -0800 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQxvae25968; Mon, 19 Dec 1994 19:11:33 -0500 Received: from multigen.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Mon, 19 Dec 1994 19:11:34 -0500 Received: from MAIL_CENTER (QM 3.0) by multigenuunet.UU.NET (UMCP\QM 2.0.1) id AA00545; Mon, 19 Dec 1994 17:12:35 PST Message-Id: <00581.2870701955.545@multigenuunet.UU.NET> Organization: MultiGen, Inc. X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Mon, 19 Dec 1994 17:10:33 PST Subject: Re: Performer Cloned Instanc Status: O Reply to: RE>Performer Cloned Instancing >From: Marco Crocetta >Subject: Performer Cloned Instancing >To: info-performer@sgi.com >Date: Wed, 14 Dec 94 9:32:25 MET > >Hi, > >I built a model whit MultiGen V.11. >In this model some objects are instanced more times. >As you know, when the loader encounters one instance reference bead, >it make a cloning operation. >Now, I need to move at run-time some parts of these cloned instances, >one instance independently from each other. >In other words, I need to find the specific instance that I have >to move, and his dynamic parts. > > >The question is: >How can I find the groups to move ? >I couldn't find the names of the MultiGen groups that represent >the instance, even in disabling the scene tree optimization in the loader. > >Thanks in Advance > >-------------------------- >Marco Crocetta >DATAMAT SpA, Rome >E-Mail: onyx@datamat.it >-------------------------- All local instances in the scene graph are pfClones. The original nodes are *never* attached to the scene graph. As a side effect of this, the pfNodes that are exported via the Flight loader callback (say a DOF's pfDCS) will not be found in the scene graph if they are part of an instanced subtree. Hmm ... this is weak ... instance loading needs improvement. It's now on my list of things to do. In the meantime ... To find all the pfDCS nodes that were cloned because of local (and external) instancing, you'll have to perform a post load traversal of the scene graph and look for them by type and pathname. Assuming PFFLT_CLEAN is disabled (as you said) , each cloned instanced will have a unique pathname. It'll be a concatenation of the node names of the unique base nodes plus the non-unique cloned nodes. You can build the pathname (and matrix stack) as you traverse down. Still, matching up the cloned pfDCS's with the corresponding DOF bead information could get complicated. >From the point of view of the DOF callback, it's a one (bead) to many (pfNode) relationship. Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4118 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Mon Dec 19 19:45:53 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA29203; Mon, 19 Dec 1994 19:19:18 -0800 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 TAA29200; Mon, 19 Dec 1994 19:19:10 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA05938; Mon, 19 Dec 94 19:19:05 -0800 Received: from relay3.UU.NET by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id TAA29151; Mon, 19 Dec 1994 19:19:03 -0800 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQxvar13817; Mon, 19 Dec 1994 22:18:59 -0500 Received: from multigen.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 19 Dec 1994 22:18:58 -0500 Received: from MAIL_CENTER (QM 3.0) by multigenuunet.UU.NET (UMCP\QM 2.0.1) id AA00546; Mon, 19 Dec 1994 20:22:16 PST Message-Id: <00581.2870713336.546@multigenuunet.UU.NET> Organization: MultiGen, Inc. X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Mon, 19 Dec 1994 18:20:00 PST Subject: Re: Transformation Matrix Status: O Reply to: RE>Transformation Matrix >From: "Tracy Hunt" >Message-Id: <9412191037.ZM3588@gts.elan.af.mil> >Date: Mon, 19 Dec 1994 10:37:43 -0800 >To: info-performer@sgi.com >Subject: Transformation Matrix > >Question: > >I have converted DMA data using MultiGen into terrain files with >specific lats and longs or XY position. I want to place these files >in their exact XY locations using pfNewSCS. How do I create the >transformation matrix with the exact coordinates necessary for proper >placement? Should I use a bounding sphere or is there another way >without enter the coordinates by hand? I'm running Performer 1.2 >on an Onyx with 5.2. > >Tracy Hunt The MultiGen Terrain option stores the lat/long projection information in the database header record. You can get this data from the OpenFlight loader via the loader callback facility. See the loader readme file (i.e. README.SS.R14_1) or The MultiGen Newsletter vol 1, issues 2 and 3 for details on how to setup the loader callback. Look in pfflt.h for the HEADERcb structure definition, wherein the data you want is packaged and passed back to your loader callback function. Also: 1. The OpenFlight loader converts everything into meters. 2. Consider handling the non-uniform lat/long scale in your pfSCS too. Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4118 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Tue Dec 20 02:21:07 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA29564; Tue, 20 Dec 1994 02:04:16 -0800 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 CAA29561; Tue, 20 Dec 1994 02:04:11 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA13191; Tue, 20 Dec 94 02:04:06 -0800 Received: from david.zfe.siemens.de by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id CAA21815; Tue, 20 Dec 1994 02:03:54 -0800 From: epp@d019f063.zfe.siemens.de Received: from ztivax.zfe.siemens.de by david.zfe.siemens.de with SMTP id AA06602 (5.67a/IDA-1.5 for ); Tue, 20 Dec 1994 11:03:39 +0100 Received: from D019F063.zfe.siemens.de (d019f063) by ztivax.zfe.siemens.de with SMTP id AA26935 (5.67a/IDA-1.5 for ); Tue, 20 Dec 1994 11:03:40 +0100 Received: from pgtf0006.z6 by D019F063.zfe.siemens.de (4.1/SMI-4.1) id AA01659; Tue, 20 Dec 94 11:01:30 +0100 Date: Tue, 20 Dec 94 11:01:30 +0100 Message-Id: <9412201001.AA01659@D019F063.zfe.siemens.de> To: info-performer@sgi.sgi.com Subject: subscribe Status: O subscribe From guest Tue Dec 20 06:44:31 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA29760; Tue, 20 Dec 1994 06:22:29 -0800 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 GAA29757; Tue, 20 Dec 1994 06:22:24 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA16403; Tue, 20 Dec 94 06:22:23 -0800 Received: from mail.swip.net by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id GAA03586; Tue, 20 Dec 1994 06:22:18 -0800 Received: by mail.swip.net with UUCP (8.6.8/3.01) id PAA06891; Tue, 20 Dec 1994 15:23:51 +0100 Received: from pc2.prosolvia.se by filip.konsult.prosolvia.se via SMTP (931110.SGI/930416.SGI.AUTO) for seunet!sgi.com!info-performer id AA28570; Tue, 20 Dec 94 14:46:26 -0800 Message-Id: <9412202246.AA28570@filip.konsult.prosolvia.se> X-Sender: patrik@filip X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Dec 1994 14:43:25 +0100 To: info-performer@sgi.sgi.com From: patrik%filip@mail.swip.net (Patrik Larking) Subject: subscribe Status: O please enter my subscription __________________________________________________ Patrik Larking CLARUS AB Stora Badhusgatan 18-20, S-411 21 Gothenburg, SWEDEN Tel +46 31 774 37 81, Fax +46 31 13 54 71 patrik@clarus.se __________________________________________________ From guest Tue Dec 20 09:20:03 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA29952; Tue, 20 Dec 1994 09:01:40 -0800 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 JAA29949; Tue, 20 Dec 1994 09:01:38 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19443; Tue, 20 Dec 94 09:01:33 -0800 Received: from wolfy.ina.fr by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id JAA17003; Tue, 20 Dec 1994 09:01:24 -0800 Received: from ina.fr (nuucp@localhost) by wolfy.ina.fr (8.6.9/8.6.9) with UUCP id RAA11808 for info-performer@sgi.com; Tue, 20 Dec 1994 17:04:12 GMT Received: by ina.fr, Tue, 20 Dec 94 16:49:59 +0100 Date: Tue, 20 Dec 94 16:49:59 +0100 From: gce@ina.fr (Cedric Gautier) Message-Id: <9412201549.AA12443@ina.fr> To: info-performer@sgi.sgi.com Subject: subscribe Status: O subscribe From guest Tue Dec 20 10:14:25 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA00063; Tue, 20 Dec 1994 09:51:10 -0800 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 JAA00060; Tue, 20 Dec 1994 09:51:05 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA21103; Tue, 20 Dec 94 09:51:00 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id JAA23031; Tue, 20 Dec 1994 09:50:58 -0800 Received: from viva.paris.sgi.com by sgihub.corp.sgi.com via ESMTP (940519.SGI.8.6.9/911001.SGI) for id JAA24491; Tue, 20 Dec 1994 09:50:55 -0800 Received: by viva.paris.sgi.com (940719.SGI.8.6.9/911001.SGI) for info-performer@sgi.sgi.com id RAA12951; Tue, 20 Dec 1994 17:51:13 +0100 Date: Tue, 20 Dec 1994 17:51:13 +0100 From: fsanchez@viva.paris.sgi.com (FRANCOIS SANCHEZ) Message-Id: <199412201651.RAA12951@viva.paris.sgi.com> To: info-performer@sgi.sgi.com Subject: flybox problem with Performer Status: O question from a developper: I work with Performer 1.2 to build an application with big task of drawing an intersection. sometimes my application hangs until I move the mouse. I am on a 2 cpu's Onyx and I initialize events with pfuInitInput, I'm only interested on flybox events. Francois. From guest Tue Dec 20 10:19:38 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA00090; Tue, 20 Dec 1994 10:02:03 -0800 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 KAA00087; Tue, 20 Dec 1994 10:02:02 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA21525; Tue, 20 Dec 94 10:02:01 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id KAA24284; Tue, 20 Dec 1994 10:01:56 -0800 Received: from crusader.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA26864; Tue, 20 Dec 94 13:03:16 EST Received: by crusader.vsl.ist.ucf.edu (920330.SGI) id AA22215; Tue, 20 Dec 94 13:02:29 -0500 Date: Tue, 20 Dec 1994 13:02:29 -0500 (EST) From: "Lance R. Marrou" To: Performer List Subject: stress and channel statistics Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi, First, I am using Performer 1.2 on an Indigo2 Extreme with IRIX 4.0.5H. I have been working on dynamic load management and analyzing the channel statistics. I have turned on the fast clock and fast itimers (with a call to "ftimer -f on -i on"). My first question: is the pfClearChan supposed to take a long time (with respect to the hardware I am using). It says in the Performer manual that "under normal circumstances" the first segment in the statistics graph shouldn't be visible at all. Does channel pass through data also heavily affect this? My second question: With a flag, I can call a GL object to throw stars (points) up on the screen before anything else, i.e. pfDraw, so that they are in the background. While true, the first segment is large and the time for the pfDraw is not so big. While false, the first segment is small, but then the pfDraw time gets much bigger (twice the usual). What could be causing this? I know those stars should be in some performer structure so that they can be rendered in the pfDraw function (and probably be more efficient), but I haven't had the time yet. For now, I am happy with turning them off or on. My third question: Load is never, I repeat never, below the low boundary of the hysteresis band. Is this a result of the limited capability of the Extreme? I know Performer is primarily geared for the Reality Engine, but it seems low-end capability would get the most use out of the dynamic load management. Also, the load fluctuates quite a lot. I assume this is due to external processes (like NFS, et al), causing me to swap. If I lock the code in memory, do you think this fluctuation should disappear? (just so you know, it doesn't :) The result of the stress never dropping below the low boundary is that the stress eventually reaches the maximum (the speed of this depending upon the scale, of course). Thanks in advance and may pfSanta be generous to you all. :) _______________________________________________________ E-mail: marrou@vsl.ist.ucf.edu IST __ WWW: http://www.vsl.ist.ucf.edu/~marrou Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Thu Dec 22 05:45:43 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA05977; Thu, 22 Dec 1994 05:22:15 -0800 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 FAA05974; Thu, 22 Dec 1994 05:22:14 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA18557; Thu, 22 Dec 94 05:22:04 -0800 Received: from relay.nswc.navy.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id FAA09582; Thu, 22 Dec 1994 05:22:01 -0800 From: lelkins@relay.nswc.navy.mil Received: from oanews (oanews.nswc.navy.mil) by relay.nswc.navy.mil (4.1/SMI-4.1) id AA10721; Thu, 22 Dec 94 08:21:50 EST Received: by oanews (4.1/SMI-4.1) id AA03553; Thu, 22 Dec 94 08:18:14 EST Message-Id: <9412221318.AA03553@oanews> Subject: pfCylAroundSegs API To: info-performer Date: Thu, 22 Dec 94 8:18:14 EST Cc: lelkins@relay.nswc.navy.mil (Leslie R. Elkins) X-Mailer: ELM [version 2.3 PL11] Status: O Hello... I'm trying to make a segment intersection routine run faster by adding bounding cylinders to the pfSegSet when I have a number of segments to look at. My problem is in sending the segments to pfCylAroundSegments. So consider the following code fragment... #include long segment_intersect(pfSegSet vol_segset, pfNode *target, long cursegment, struct points_struct *pts) { static pfHit **hits[100]; static long isect, counter; static pfCylinder dst; /* Build the bits... */ if(cursegment>0) vol_segset.activeMask=0x01; else vol_segset.activeMask=0x0; for(counter=1;counter make making OPT version of volcol cc -xansi -D__STvolcol__ -I.. -I.. -I/usr/src/Performer/include -I/usr/include/Performer -O -c ../volcol.c cfe: Warning 709: ../volcol.c, line 44: Incompatible pointer type assignment pfCylAroundSegs(&dst, &(vol_segset.segs), cursegment); --------------------------^ The man page for pfCylAroundSegs says that it has the following prototype: void pfCylAroundSegs(pfCylinder *dst, pfSeg **segs, long nseg); So what it wants there is a pfSeg**.... However, vol_segset is a pfSegSet: typedef struct _pfSegSet { long mode; void * userData; pfSeg segs[PFIS_MAX_SEGS]; ulong activeMask; ulong isectMask; void * bound; long (*discFunc)(pfHit*); } pfSegSet; so vol_segset.segs should be a (pfSeg *), and it seems to me that &(vol_segset.segs) should be a (pfSeg **)... But the compiler doesn't like it. I have also tried the following fragment: if(cursegment<3) { vol_segset.bound=NULL; vol_segset.mode=vol_segset.mode&(!((long)PFTRAV_IS_BCYL)); } else { pfSeg **ssseg; ssseg=(pfSeg **)&(vol_segset.segs); vol_segset.mode=vol_segset.mode|PFTRAV_IS_BCYL; pfCylAroundSegs(&dst, ssseg, cursegment); vol_segset.bound=&dst; } This also fails to compile... onyx2:elkins:/usr/people/elkins/perfsrc/volcol/temp> make making OPT version of volcol cc -xansi -D__STvolcol__ -I.. -I.. -I/usr/src/Performer/include -I/usr/include/Performer -O -c ../volcol.c cfe: Warning 709: ../volcol.c, line 51: Incompatible pointer type assignment pfCylAroundSegs(&dst, ssseg, cursegment); --------------------------^ What am I missing? Probably something horribly simple in the typecasting, but I'm at a loss to see it at the moment. System particulars: IRIX 5.2, Performer 1.2, Onyx I eoe1 03/05/94 IRIX Execution Environment 1, 5.2 I eoe2 10/14/94 IRIX Execution Environment 2, 5.2 I performer_dev 10/14/94 IRIS Performer1.2/Irix5 Development Software I c_dev 10/14/94 C, 3.18 Thanks in advance for any pointers.... Les Elkins ---------------------------------------------------------------------- lelkins@relay.nswc.navy.mil The views expressed herein do not represent those of NSWC, the Navy, Les Elkins or the federal government. Naval Surface Warfare Center Dahlgren Division (And anybody who says otherwise is Silver Spring, MD itching for a fight...) From guest Thu Dec 22 06:00:10 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA06013; Thu, 22 Dec 1994 05:36:05 -0800 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 FAA06010; Thu, 22 Dec 1994 05:36:05 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA18649; Thu, 22 Dec 94 05:35:56 -0800 Received: from vega.cc.upv.es by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id FAA10128; Thu, 22 Dec 1994 05:35:47 -0800 From: degi@degi.upv.es Message-Id: <199412221335.FAA10128@sgi.sgi.com> Received: from degi.upv.es (manolin.degi.upv.es) by vega.cc.upv.es with SMTP (1.37.109.11/16.2) id AA267863190; Thu, 22 Dec 1994 14:33:10 +0100 Received: by manolin.degi.upv.es (1.37.109.4/16.2) id AA01600; Thu, 22 Dec 94 13:17:33 GMT Subject: literature about PERFOREMER To: info-performer@sgi.sgi.com Date: Thu, 22 Dec 94 13:17:32 "GMT Mailer: Elm [revision: 70.85] Status: O we would like to know, if someone could send us a list of literature about PERFORMER, from SGI editorial and other editorials. OUR ADDRES: Dr. Mariano Alcaniz Raya GRUPO DE DESARROLLO DE IMAGEN Y DISENO ESCUELA TECNICA SUPERIOR DE INGENIEROS AGRONOMOS UNIVERSIDAD POLITECNICA DE VALENCIA camino de vera 14 46022 VALENCIA SPAIN Phone: 6 (Valencia) 3877518 Fax: 6 3877139 Email: degi@degi.upv.es From guest Thu Dec 22 06:15:52 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA06038; Thu, 22 Dec 1994 05:54:07 -0800 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 FAA06035; Thu, 22 Dec 1994 05:53:59 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA18805; Thu, 22 Dec 94 05:53:55 -0800 Received: from chris.gcs.redstone.army.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id FAA11256; Thu, 22 Dec 1994 05:53:11 -0800 Received: by chris.gcs.redstone.army.mil (931110.SGI/930416.SGI) for info-performer@sgi.com id AA10245; Thu, 22 Dec 94 07:55:20 -0600 Date: Thu, 22 Dec 94 07:55:20 -0600 From: mcclure@chris.gcs.redstone.army.mil (Kevin R. McClure) Message-Id: <9412221355.AA10245@chris.gcs.redstone.army.mil> To: "<""@chris.gcs.redstone.army.mil>"@chris.gcs.redstone.army.mil Subject: VIEIWING Matrix Status: O Hey, I am looking for a way to get the Performer VIEWING matrix. From guest Thu Dec 22 07:14:00 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA06228; Thu, 22 Dec 1994 06:50:55 -0800 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 GAA06225; Thu, 22 Dec 1994 06:50:37 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19703; Thu, 22 Dec 94 06:50:32 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id GAA14675; Thu, 22 Dec 1994 06:50:29 -0800 Received: from crusader.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA02930; Thu, 22 Dec 94 09:51:44 EST Received: by crusader.vsl.ist.ucf.edu (920330.SGI) id AA02988; Thu, 22 Dec 94 09:50:53 -0500 Date: Thu, 22 Dec 1994 09:50:52 -0500 (EST) From: "Lance R. Marrou" To: lelkins@relay.nswc.navy.mil Cc: info-performer, "Leslie R. Elkins" Subject: Re: pfCylAroundSegs API In-Reply-To: <9412221318.AA03553@oanews> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Thu, 22 Dec 1994 lelkins@relay.nswc.navy.mil wrote: ... > The man page for pfCylAroundSegs says that it has the following prototype: > > void pfCylAroundSegs(pfCylinder *dst, pfSeg **segs, long nseg); However, the actual prototype is: extern void pfCylAroundSegs(pfCylinder* _dst, const pfSeg** _segs, long _nseg); ... > > What am I missing? Probably something horribly simple in the typecasting, > but I'm at a loss to see it at the moment. ... Not horribly simple at all. The following will work though: pfCylAroundSegs(&dst, (const pfSeg**)&(vol_segset.segs), cursegment); I think the problem lies in the cc compiler. You can use (correctly) a simple typecast of (pfSeg **), ignoring the const declaration if you compile with CC. With cc, you need the const. Either way, you need the pfSeg**. _______________________________________________________ E-mail: marrou@vsl.ist.ucf.edu IST __ WWW: http://www.vsl.ist.ucf.edu/~marrou Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Thu Dec 22 12:16:49 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA07076; Thu, 22 Dec 1994 11:56:48 -0800 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 LAA07069; Thu, 22 Dec 1994 11:56:43 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA28237; Thu, 22 Dec 94 11:56:38 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id LAA18869; Thu, 22 Dec 1994 11:56:36 -0800 Received: from grail.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA04222; Thu, 22 Dec 94 14:57:56 EST Received: by grail.vsl.ist.ucf.edu (920330.SGI) id AA06375; Thu, 22 Dec 94 14:57:08 -0500 Date: Thu, 22 Dec 1994 14:57:07 -0500 (EST) From: "Lance R. Marrou" To: Performer List Subject: GLX windows pushing/popping/moving Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Ok, In using GLX windows for my Performer application, I cannot get the window to push, pop, or move. This is what I tried: GLXwinset(IGshared->xWinInfo.dsp, IGshared->xWinInfo.glWin); if (IGshared->win_push_pop == WIN_PUSH) winpush(); else if (IGshared->win_push_pop == WIN_POP) winpop(); GLXwinset(IGshared->xWinInfo.dsp, IGshared->xWinInfo.glWin); if (IGshared->win_push_pop == WIN_PUSH) XLowerWindow((Display *)IGshared->xWinInfo.dsp,IGshared->xWinInfo.xWin); else if (IGshared->win_push_pop == WIN_POP) XRaiseWindow((Display *)IGshared->xWinInfo.dsp,IGshared->xWinInfo.xWin); IGshared is a pointer to a shared memory structure (obviously similar to the ViewState structure in perfly). I do not know how to get the GLX window to do this. I do not even have a way to attempt moving or resizing the window. Can anyone offer a pointer? Also, I noticed that the XRaiseWindow and XLowerWindow routines need the type cast, but the GLXwinset doesn't. I assume this is because of the void * argument to GLXwinset (different from the man page). Why is it void *? _______________________________________________________ E-mail: marrou@vsl.ist.ucf.edu IST __ WWW: http://www.vsl.ist.ucf.edu/~marrou Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Thu Dec 22 12:28:35 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA07151; Thu, 22 Dec 1994 12:08:02 -0800 Return-Path: Received: from surreal.asd.sgi.com by holodeck.asd.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA07148; Thu, 22 Dec 1994 12:08:02 -0800 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA22289; Thu, 22 Dec 1994 12:07:52 -0800 Message-Id: <199412222007.MAA22289@surreal.asd.sgi.com> To: lelkins@relay.nswc.navy.mil cc: info-performer Subject: Re: pfCylAroundSegs API In-reply-to: Your message of "Thu, 22 Dec 94 08:18:14 EST." <9412221318.AA03553@oanews> Date: Thu, 22 Dec 94 12:07:44 -0800 From: Jim Helman Status: O Like the rest of the math functions which take a group of input structures (e.g. boxes, spheres, etc.), pfCylAroundSegs takes an array of pointers to segments rather than an array of segment structures. The reason for this convention in the math API is to reduce the need for copying dispersed structures into an array of structures just to pass it to a math routine. In many cases, the time spent doing such a copy would be comparable to or exceed the time spent in the routine itself. This passing convention is usually faster and at worst requires a pointer copy per input structure. The latter is the case with a pfSegSet, so you must do something like: pfSeg *segp[32]; for (i = 0 ; i < nSeg ; i++) segp[i] = &segset.segs[i]; pfCylAroundSegs(&cyl, segp, nSeg); rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 22 12:57:55 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA07262; Thu, 22 Dec 1994 12:32:53 -0800 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 MAA07259; Thu, 22 Dec 1994 12:32:48 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA29505; Thu, 22 Dec 94 12:32:47 -0800 Received: from vision.arc.nasa.gov by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id MAA23565; Thu, 22 Dec 1994 12:32:33 -0800 Received: from fechner.arc.nasa.gov (fechner.arc.nasa.gov [128.102.121.161]) by vision.arc.nasa.gov (8.6.9/8.6.5) with ESMTP id MAA04439 for ; Thu, 22 Dec 1994 12:32:15 -0800 Received: (carlo@localhost) by fechner.arc.nasa.gov (8.6.7/8.6.5) id UAA16010 for info-performer@sgi.com; Thu, 22 Dec 1994 20:32:09 GMT Date: Thu, 22 Dec 1994 20:32:09 GMT From: "Carlo L. Tiana" Message-Id: <199412222032.UAA16010@fechner.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: Performer under 6.0 Status: O I am considering purchasing a PowerIndigo 2 Extreme, which I believe runs IRIX 6.0. I was wondering if anyone has had any experience with Performer on this platform with this OS - I am looking for whether a) it works at all and if not, when a version that does is xpected to be out b) how its performance compares to say an Indigo 2 Extreme under 5.2 c) any other things I should watch out for as they relate to Performer Thanks very much, Carlo. From guest Thu Dec 22 14:04:27 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA07472; Thu, 22 Dec 1994 13:20:20 -0800 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 NAA07469; Thu, 22 Dec 1994 13:20:20 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA00649; Thu, 22 Dec 94 13:20:19 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id NAA28361; Thu, 22 Dec 1994 13:20:16 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id NAA06784; Thu, 22 Dec 1994 13:20:15 -0800 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:panisset@cim.mcgill.ca id AA00645; Thu, 22 Dec 94 13:20:10 -0800 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA23097; Thu, 22 Dec 1994 13:20:00 -0800 Message-Id: <199412222120.NAA23097@surreal.asd.sgi.com> To: Jean-Francois Panisset Cc: info-performer@sgi.sgi.com Subject: Re: Looking for past mail (and list archival) In-Reply-To: Your message of "Fri, 16 Dec 94 11:03:20 EST." <199412161603.LAA02089@Athena.McRCIM.McGill.EDU> Date: Thu, 22 Dec 94 13:19:59 -0800 From: Jim Helman Status: O > I've looked in sgigate.sgi.com:pub/Performer/monthly-archives, but the most > recent archive appears to be for June 94... It would be a shame if it were > no longer being done, as I find the quality of the information available > on this list to be very high. Archives of info-performer for July through November '94 have just been added to sgigate.sgi.com:pub/Performer/monthly-archives. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 22 14:59:16 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA07673; Thu, 22 Dec 1994 14:11:58 -0800 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 OAA07670; Thu, 22 Dec 1994 14:11:57 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA01954; Thu, 22 Dec 94 14:11:49 -0800 Received: from chris.gcs.redstone.army.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id OAA05516; Thu, 22 Dec 1994 14:11:26 -0800 Received: by chris.gcs.redstone.army.mil (931110.SGI/930416.SGI) for info-performer@sgi.com id AA11044; Thu, 22 Dec 94 16:13:55 -0600 Date: Thu, 22 Dec 94 16:13:55 -0600 From: mcclure@chris.gcs.redstone.army.mil (Kevin R. McClure) Message-Id: <9412222213.AA11044@chris.gcs.redstone.army.mil> To: "<""@chris.gcs.redstone.army.mil>"@chris.gcs.redstone.army.mil Subject: Viewing Matrix Status: O Hello, I am tring to calculate clip coordinates for objects in my frustrum by creating a transformation matrix (Projection matrix * Viewing matrix) and passing the object vector (xpos,ypos,zpos,1) through the transformation matrix then dividing the resultant vector with the homogeneous value. My problem is getting the viewing matrix. I am unable to use the MMODE VIEWING for, it gives me the model matrix + the view matrix. Any suggestions? From guest Thu Dec 22 15:09:06 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA07873; Thu, 22 Dec 1994 14:39:41 -0800 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 OAA07870; Thu, 22 Dec 1994 14:39:37 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA02641; Thu, 22 Dec 94 14:39:36 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id OAA09089; Thu, 22 Dec 1994 14:39:32 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id OAA12643; Thu, 22 Dec 1994 14:24:16 -0800 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:carlo@vision.arc.nasa.gov id AA02234; Thu, 22 Dec 94 14:24:07 -0800 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA23353; Thu, 22 Dec 1994 14:24:03 -0800 Message-Id: <199412222224.OAA23353@surreal.asd.sgi.com> To: "Carlo L. Tiana" Cc: info-performer@sgi.sgi.com Subject: Re: Performer under 6.0 In-Reply-To: Your message of "Thu, 22 Dec 94 20:32:09 GMT." <199412222032.UAA16010@fechner.arc.nasa.gov> Date: Thu, 22 Dec 94 14:23:59 -0800 From: Jim Helman Status: O Under IRIX 6.0, you can run Performer 1.2 in a 32bit application with 32bit IrisGL. If you want to do graphics in a 64bit application, you need Performer 2.0 and 64bit OpenGL. (Customers with requirements for 64bit Performer before 2.0's release should contact Ralph Humphries, ralphh@sgi.com). As for performance, the R8000 is much faster for floating point, so a lot depends on how intensive your FP computations are. The basic graphics performance will be about the same. As for Performer traversal and scene graph operations, I don't have any benchmarks but would expect moderate improvement, perhaps 10-25%. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 22 18:04:39 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA08495; Thu, 22 Dec 1994 17:44:25 -0800 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 RAA08492; Thu, 22 Dec 1994 17:44:24 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA07430; Thu, 22 Dec 94 17:44:23 -0800 Received: from nova.unix.portal.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id RAA29410; Thu, 22 Dec 1994 17:44:21 -0800 Received: from uucp1.unix.portal.com (uucp1.unix.portal.com [156.151.1.100]) by nova.unix.portal.com (8.6.9/8.6.5) with ESMTP id RAA26063; Thu, 22 Dec 1994 17:44:12 -0800 Received: from cory.UUCP (uucp@localhost) by uucp1.unix.portal.com (8.6.9/8.6.5) with UUCP id RAA00546; Thu, 22 Dec 1994 17:32:29 -0800 Received: by cory (920330.SGI/911001.SGI) for portal!sgi.com!info-performer id AA29484; Thu, 22 Dec 94 17:31:45 -0800 From: davec@cory.coryphaeus.com (Dave Cooper) Message-Id: <9412230131.AA29484@cory> Subject: Re: Viewing Matrix To: mcclure@chris.gcs.redstone.army.mil (Kevin R. McClure) Date: Thu, 22 Dec 1994 17:31:44 -0800 (PST) Cc: info-performer@sgi.sgi.com In-Reply-To: <9412222213.AA11044@chris.gcs.redstone.army.mil> from "Kevin R. McClure" at Dec 22, 94 04:13:55 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1044 Status: O > > Hello, > I am tring to calculate clip coordinates for objects in my > frustrum by creating a transformation matrix (Projection matrix > * Viewing matrix) and passing the object vector (xpos,ypos,zpos,1) > through the transformation matrix then dividing the resultant > vector with the homogeneous value. My problem is getting the > viewing matrix. I am unable to use the MMODE VIEWING for, it > gives me the model matrix + the view matrix. Any suggestions? > If you have a copy of pfdwb.c (version 2.32 or above) there are the functions clipRegionOn clipRegionOff map_viewport wtoscrn that do the following: Take a lower left corner and upper right world values convert those to screen space and then uses callbacks to clip that object when its drawn. There may be something in that code that you can reuse. If you dont have a recent release let me know and I'll send you a copy. Or if your models are in dwb format then you can just mark the group as a clip region and leave the rest up to the loader. DaveC From guest Fri Dec 23 00:05:56 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA08994; Thu, 22 Dec 1994 23:44:23 -0800 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 XAA08988; Thu, 22 Dec 1994 23:44:19 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA12076; Thu, 22 Dec 94 23:44:10 -0800 Received: from mail.swip.net by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id XAA18991; Thu, 22 Dec 1994 23:44:08 -0800 Received: by mail.swip.net with UUCP (8.6.8/3.01) id IAA09686; Fri, 23 Dec 1994 08:45:47 +0100 Received: from pc2.prosolvia.se by filip.prosolvia.se via SMTP (931110.SGI/930416.SGI.AUTO) for seunet!sgi.com!info-performer id AA18266; Fri, 23 Dec 94 08:44:05 +0100 Message-Id: <9412230744.AA18266@filip.prosolvia.se> X-Sender: patrik@filip X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Dec 1994 08:40:56 +0100 To: info-performer@sgi.sgi.com From: patrik%filip@mail.swip.net (Patrik Larking) Subject: unsubscribe Status: O Please unsubscribe me __________________________________________________ Patrik Larking CLARUS AB Stora Badhusgatan 18-20, S-411 21 Gothenburg, SWEDEN Tel +46 31 774 37 81, Fax +46 31 13 54 71 patrik@clarus.se __________________________________________________ From guest Fri Dec 23 09:30:27 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA10194; Fri, 23 Dec 1994 09:10:38 -0800 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 JAA10191; Fri, 23 Dec 1994 09:10:37 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA18390; Fri, 23 Dec 94 09:10:36 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id JAA15253; Fri, 23 Dec 1994 09:10:34 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for id JAA05447; Fri, 23 Dec 1994 09:10:33 -0800 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@sgi.sgi.com id AA18387; Fri, 23 Dec 94 09:10:33 -0800 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA10497; Fri, 23 Dec 1994 09:08:57 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <199412231708.JAA10497@tubes.asd.sgi.com> Subject: Re: pfLightPoint bug? To: guest (Marcus) Date: Fri, 23 Dec 94 9:08:57 PST Cc: info-performer@sgi.sgi.com In-Reply-To: ; from "Marcus" at Oct 20, 94 1:18 pm X-Mailer: ELM [version 2.3 PL8] Status: O > I was recently looking at the ASCII output of a scene graph that > has lightpoints in it: > > [5:0]pfLightPoint pfId=8 0x82e800 { > trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff > bsphere: ctr(-65.000000, -8.660254, -5.000000) rad=11.180340 > Num Points: 5, Size: 2.000000 FogScales: 2.000000 2.000000 > shape: dir=PFLP_OMNIDIRECTIONAL henv=179.000000 venv=179.000000 > falloff=4.000000 > Rot: azim=0.000000 elev=0.000000 roll=0.000000 > Color mode: PFGS_OVERALL, color: 0.109804 0.874510 0.168627 1.000000 > Point 263527468: -70.000000 -17.320507 -10.000000 > Point 263527468: -60.000000 -17.320507 -10.000000 Point 263527468: -70.000000 -8.660254 -5.000000 056q> Point 263527468: -60.000000 -8.660254 -5.000000 > Point 263527468: -60.000000 0.000000 0.000000 > ^^^^^^^^^^^^^^^^ > [5:0]} pfLightPoint 8 0x82e800 > > Notice that the RPointS numbers are outrageous. I would expect > them to be 0, 1, 2, 3, and 4. This is a bug in pfPrint() which has been fixed. From guest Fri Dec 23 09:43:26 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA10238; Fri, 23 Dec 1994 09:27:50 -0800 Return-Path: Received: from tubes.asd.sgi.com by holodeck.asd.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA10235; Fri, 23 Dec 1994 09:27:49 -0800 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA10540; Fri, 23 Dec 1994 09:26:14 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <199412231726.JAA10540@tubes.asd.sgi.com> Subject: Re: pfSequences Stop Working..... To: guest (Hillel Steinberg) Date: Fri, 23 Dec 94 9:26:14 PST Cc: info-performer In-Reply-To: <199411150201.VAA08546@tove.cs.UMD.EDU>; from "Hillel Steinberg" at Nov 14, 94 9:01 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > > I have spent a long time trying to find out what the problem is with my > sequences, maybe you can help. I am using Performer 1.2 and have objects > in the scene (groups of nodes), some of which are sequences. All my > sequences are set to cycle infinitely through a series of rectangles with > textures - i.e. an explosion and whatnot. This works most of the time, > usually, but not always. The symptom during a run of my application > is that somtimes ALL sequences in the scene suddenly stop working - i.e., > the sequence cycling stops on a particular frame. Sometimes it starts again - > I don't see what triggers this. > > There is supposed to be a bug in 1.0 or somthing that says that intersections > can stop sequences accidently - but I am using Performer 1.2. Anybody > seen this yet, or have an idea as to what triggers the sequences to stop? > I am doing intersections. > > One point to note. Sometimes I put the same sequence into the scene under > two different groups. This seems to work, i.e. the same explosion may > appear in the scene in two places simultaneously as ONE sequence under > two groups. Could I screw things up if the same sequence shows up in > the scene twice - does Performer get messed up trying to keep track of > which frame the sequence is in? Most of the time this seems to work. > It shouldn't be this difficult because I am working all under ONE process, An instanced pfSequence node does not have 2 frame counts, e.g, if you have 2 explosions represented by the same pfSequence, they will sequence in lock-step. How do you specify an infinite sequence? From guest Fri Dec 23 10:17:14 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA10406; Fri, 23 Dec 1994 09:57:32 -0800 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 JAA10401; Fri, 23 Dec 1994 09:57:31 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19465; Fri, 23 Dec 94 09:57:30 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id JAA19209; Fri, 23 Dec 1994 09:57:28 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for id JAA10839; Fri, 23 Dec 1994 09:57:27 -0800 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@sgi.sgi.com id AA19457; Fri, 23 Dec 94 09:57:26 -0800 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA10791; Fri, 23 Dec 1994 09:55:50 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <199412231755.JAA10791@tubes.asd.sgi.com> Subject: Re: pfMaterial To: guest (Angus Dorbie uid) Date: Fri, 23 Dec 94 9:55:50 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9412070210.ZM13059@ariel.division.demon.co.uk>; from "Angus Dorbie uid" at Dec 7, 94 2:10 am X-Mailer: ELM [version 2.3 PL8] Status: O > > In my last email I said I intended to override back and front materials > independently. As always front material overrides work, but after some trial > and error I can't override the back facing material. I've guessed this is a > result of the documented limitations of the Iris GL call lmcolor(). I've tried > both the default pfMtlColorMode() setting on my materials and PFMTL_CMODE_COLOR > applied to PFMTL_BOTH surfaces. You are correct that IrisGL lmcolor does not work for back-sided materials so there's no real solution until OpenGL. > I need PFMTL_CMODE_COL for material transparency, which has the side effect of > disabling colour per primitive information on some triangular meshes I create. > This is understandable but frustrating because of its requirement for > transparent materials. A mode where alpha is applied from the material and > diffuse & ambient from lmcolor would be handy. Can you use CMODE_AD and set the pfGeoSets' alpha to that of the material? Note that this situation is why we chose to support c4f rather than c3f in pfGeoSets. > Is there a known workaround for my material override, or colour per primitive > with transparent material problems, or have I miss-diagnosed the symptoms? > Also, would it be possible for someone to elaborate on what performer is doing > with materials in "Iris GL speak" to assist my understanding? I've tried to > glean this information from the manuals but in some respects it's not clear > what's supposed to be happening under there. > We do nothing special with lighting - a pfMaterial is simply a wrapper around GL materials and pfMtlColorMode simply sets lmcolor(). From guest Fri Dec 23 10:22:26 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA10429; Fri, 23 Dec 1994 10:03:19 -0800 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 KAA10426; Fri, 23 Dec 1994 10:03:18 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19609; Fri, 23 Dec 94 10:03:17 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id KAA19972; Fri, 23 Dec 1994 10:03:15 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for id KAA11592; Fri, 23 Dec 1994 10:03:14 -0800 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@sgi.sgi.com id AA19603; Fri, 23 Dec 94 10:03:13 -0800 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA10805; Fri, 23 Dec 1994 10:01:37 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <199412231801.KAA10805@tubes.asd.sgi.com> Subject: Re: Multiprocessing. To: guest (Sean Halliday) Date: Fri, 23 Dec 94 10:01:37 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9412132101.AA03059@grizzly.BanffCentre.AB.CA>; from "Sean Halliday" at Dec 13, 94 2:01 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > I have an old application that I will eventually convert from GL to > Performer. What I tried to to as a quick fix is to make it two processes, > app and draw (I used sproc.) This worked most of the time. After a > random amount of time the graphics pipeline (RE2) would crash. I am not doing > any GL calls in the app. I think the problem was that the app could be > writing to data (like a matrix) while the draw was accessing it (like > multmatrix). Can that be a problem? How does perfromer handle this? > Does fork and shared memory fix the problem or does Performer make a copy > of the data before making a GL call? > Performer maintains multiple copies of variable data, one per process, so avoid such data collisions. For more details check out the Siggraph94 paper on Performer. From guest Fri Dec 23 10:27:16 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA10440; Fri, 23 Dec 1994 10:07:44 -0800 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 KAA10437; Fri, 23 Dec 1994 10:07:43 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19975; Fri, 23 Dec 94 10:07:42 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id KAA20493; Fri, 23 Dec 1994 10:07:40 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for id KAA11993; Fri, 23 Dec 1994 10:07:39 -0800 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@sgi.sgi.com id AA19969; Fri, 23 Dec 94 10:07:38 -0800 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA10815; Fri, 23 Dec 1994 10:06:04 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <199412231806.KAA10815@tubes.asd.sgi.com> Subject: Re: Performer Cloned Instancing To: guest (Marco Crocetta) Date: Fri, 23 Dec 94 10:06:03 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <199412140911.AA17785@relay.iunet.it>; from "Marco Crocetta" at Dec 14, 94 9:32 am X-Mailer: ELM [version 2.3 PL8] Status: O > > Hi, > > I built a model whit MultiGen V.11. > In this model some objects are instanced more times. > As you know, when the loader encounters one instance reference bead, > it make a cloning operation. > Now, I need to move at run-time some parts of these cloned instances, > one instance independently from each other. > In other words, I need to find the specific instance that I have > to move, and his dynamic parts. > > > The question is: > How can I find the groups to move ? > I couldn't find the names of the MultiGen groups that represent > the instance, even in disabling the scene tree optimization in the loader. In 1.2, you need to rename the root of the cloned subgraph. Then you can use a pathname to fine nodes underneath the clone, e.g., pfFind("cloned/part"); Note that the next release of Performer will contain friendlier database access routines to make this kind of thing trivial. From guest Fri Dec 23 11:09:31 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA10713; Fri, 23 Dec 1994 10:49:01 -0800 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 KAA10710; Fri, 23 Dec 1994 10:49:00 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA21515; Fri, 23 Dec 94 10:48:59 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id KAA24391; Fri, 23 Dec 1994 10:48:57 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for id KAA15260; Fri, 23 Dec 1994 10:48:56 -0800 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@sgi.sgi.com id AA21511; Fri, 23 Dec 94 10:48:51 -0800 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA05021; Fri, 23 Dec 1994 10:47:17 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <199412231847.KAA05021@tubes.asd.sgi.com> Subject: Re: GeoState corruption To: guest (Jean-Francois Richard) Date: Fri, 23 Dec 94 10:47:16 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9412141728.AA12237@cae.ca>; from "Jean-Francois Richard" at Dec 14, 94 12:28 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > Hi everybody. > > I'm currently trying to integrate into my Performer program > the great looking Flight format models that the good folks > at Viewpoint were giving away at I/ITSEC. > > The problem is that the models are doing something to the > lighting and/or material definitions (I'm not exactly sure > which) that affects the lighting over the rest > of the displayed scene. I am specifying default lights and > light model and I tried adding a default material > (pfApplyMtl( pfNewMtl( ... ) ) ) but the overall lighting > still changes after one of the Viewpoint models is displayed. > > All my database geosets have geostates that do not specify > lighting or material characteristics. These are all set globally, > but, according to the pfGeoState man page, should be restored > from the global state before the database's local geostates are > applied. > > The following note from the pfGeoState man page attracted my > attention: > > >> In some situations it may appear that pfGeoStates do inherit from each > >> other. This is because IRIS Performer currently does not provide any > >> defaults for the state attributes listed above such as PFSTATE_TEXTURE > >> and PFSTATE_FRONTMTL. Consequently, if the application does not expli- > >> citly set these attributes, it is possible for pfGeoStates which inherit > >> these attributes to inherit them from previous pfGeoStates. > > Ok, so maybe there is a global state attribute I am not setting that is > being changed by the Viewpoint models. The phrase "such as PFSTATE_TEXTURE > and PFSTATE_FRONTMTL" seems a bit vague to me. What exactly are > all the modes and attributes I should watch out for? I am specifying > a global front material, and local textures, so is there anything > else I should set? > > Is there an elegant way of insuring that an imported model or > database leaves the graphics state unchanged after it gets > drawn (without having to push/pop the state in pre/post-draw > callbacks)? > > > This isn't exactly a matter of life and death and I'm > sure I could hack my way around it but I am curious about > what exactly is going on here. Anybody knows the right way > of dealing with this? pfGeoStates are *the* elegant way of ensuring that graphics state is not inherited across geometry. pfGeoStates have been thrashed to death so I doubt that you've run into a geostate bug. Exactly how is the lighting changed by the Viewpoint models? Can you point me to the models which cause the problem? N.B.: The graphics state is not immediately popped after a pfGeoState is applied. Rather, any "dirty" state is popped *after* the next pfGeoState is applied so that no state is unnecessarily popped. Consequently after a pfGeoState is applied, the graphics state is that of the pfGeoState. If you want a return to the global state, either apply a pfGeoState which inherits everything or call pfFlushState(). This lazy popping of state is a significant performance feature of pfGeoStates. From guest Sun Dec 25 07:28:18 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA14259; Sun, 25 Dec 1994 06:58:28 -0800 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 GAA14256; Sun, 25 Dec 1994 06:58:27 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA14495; Sun, 25 Dec 94 06:58:26 -0800 Received: from bvr.co.il by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id GAA26292; Sun, 25 Dec 1994 06:57:55 -0800 Received: from amcor.bvr.co.il by bvr.co.il via SMTP (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA07491; Sun, 25 Dec 94 17:02:02 +0200 Received: by amcor.bvr.co.il (931110.SGI/911001.SGI) for @owl.bvr.co.il:info-performer@sgi.com id AA08567; Sun, 25 Dec 94 16:55:38 +0200 From: "Ran Yakir" Message-Id: <9412251655.ZM8565@amcor.bvr.co.il> Date: Sun, 25 Dec 1994 16:55:36 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: uunet.UU.NET!multigen!marcus Subject: bug id LoadTexMono Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Marcus, I've located a bug in the flt14 loader, in the function ReadimageSGI, called from LoadTexMono. When the type of the rgb image is RLE, the function allocates space for one channel only for the image : line 4852 : *image = ( unsigned char * ) malloc ( wordsxrnd * Patheight ); This will cause a Bus Error later, since the function reads more than wordsxrnd * Patheight bytes from the file. In my private version I've changed this line to : *image = ( unsigned char * ) malloc ( wordsxrnd * Patheight * zsize ); Another minor point is that after calling LoadTexMono() from getTexture(), the code proceeds and reads the old (rgb or rgba) texture attribute file. I suppose it doesn't matter, since the only difference is the image type, but for cleanness I would suggest you add the line strcpy (path, outfilename); right after the loading of the monochrome image in LoadTexMono(). 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-3-6995364 | Fax : 972-3-5715668 | From guest Tue Dec 27 17:07:59 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA19207; Tue, 27 Dec 1994 16:46:14 -0800 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 QAA19204; Tue, 27 Dec 1994 16:46:13 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19194; Tue, 27 Dec 94 16:46:12 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id QAA08672; Tue, 27 Dec 1994 16:46:11 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id QAA10863; Tue, 27 Dec 1994 16:46:08 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:roth@ifi.unizh.ch id AA19190; Tue, 27 Dec 94 16:46:02 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA28697; Tue, 27 Dec 1994 16:45:59 -0800 From: "Michael Jones" Message-Id: <9412271645.ZM28695@babar.asd.sgi.com> Date: Tue, 27 Dec 1994 16:45:59 -0800 In-Reply-To: Martin Roth "Geographical Texture Data" (Dec 12, 6:18pm) References: <199412121718.JAA02229@sgi.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Martin Roth , info-performer@sgi.sgi.com Subject: Re: Geographical Texture Data Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 12, 6:18pm, Martin Roth wrote: > Subject: Geographical Texture Data :At the time we are dealing with three levels of detail. We are working on a :4 Mbyte texture RAM Onyx. In order not to run out of texture RAM it probably :will be inevitable to introduce the concept of LODs into the texturing, too. Yes. :Is there an easy (and RAM saving) way to realise texture LODs, eventually :preventing the possibility of incrementally loading higher LODs? If you can do without MIP-mapping, you can us the "subtexload()" command to perform incremental updates to your terrain texture as you fly. This is the most commonly implemented RealityEngine approach to huge terrain texture processing. :In order to realise the incremental loading is it possible to expand the actual :texture bitmap in a fast way and then add details to the expanded texels? Not that I know of. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Dec 27 17:03:20 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA19200; Tue, 27 Dec 1994 16:42:26 -0800 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 QAA19197; Tue, 27 Dec 1994 16:42:25 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19101; Tue, 27 Dec 94 16:42:24 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id QAA08334; Tue, 27 Dec 1994 16:42:22 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id QAA10549; Tue, 27 Dec 1994 16:42:19 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:dslayton@nvl.army.mil id AA19088; Tue, 27 Dec 94 16:42:17 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA28687; Tue, 27 Dec 1994 16:42:10 -0800 From: "Michael Jones" Message-Id: <9412271642.ZM28685@babar.asd.sgi.com> Date: Tue, 27 Dec 1994 16:42:10 -0800 In-Reply-To: dslayton@nvl.army.mil (David Slayton) "range finding from Z-Buffer values" (Dec 12, 10:21am) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: dslayton@nvl.army.mil (David Slayton), info-performer@sgi.sgi.com Subject: Re: range finding from Z-Buffer values Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 12, 10:21am, David Slayton wrote: > Subject: range finding from Z-Buffer values :I am attempting to write a range-finding routine as a post-pfdraw function :in performer based upon the values contained in the Z-Buffer after pfdraw :has completed. The values my routine is returning are inconsistent and :non-intuitive. I expect to see values appoaching farplane +nearplane at their :largest and nearplane at their smallest, but am not getting anything like this. :When I'm looking at things far away, the range values seem to make sense. :However, when I'm looking at things up close, the values still remain large :(close to the value of farplane). If you have a RealityEngine system in its deluxe anti-aliasing mode (MultiSample mode) then there is no Z-value available to be read. Once you disable MultiSampling (or if you lack it to start with) then it reduces to a problem of decoding the Z-buffer contents after you read them back. It will save you time if you consult the little equation below. This is how to interpret (decode) the Z-buffer values which you are seeking. It can be tedious to work out by hand. ;-) z = value in z buffer after rendering (input) range = distance to pixel in database units (output) np = distance to near clipping plane (database units) fp = distance far clipping plane (database units) nz = near-clip z value (lsetdepth) fz = far-clip z value (lsetdepth) where you (or Performer on your behalf) did: lsetdepth(nz, fz); you must evaluate this equation for each Z-buffer value: fp*np(fz-nz) ------------ fp-np - range = -------------------------- (fp+np)(fz-nz) fz+nz z - -------------- - ----- 2(fp-np) 2 -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Dec 27 17:16:03 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA19217; Tue, 27 Dec 1994 16:55:14 -0800 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 QAA19214; Tue, 27 Dec 1994 16:55:14 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19387; Tue, 27 Dec 94 16:55:12 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id QAA09605; Tue, 27 Dec 1994 16:55:10 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id QAA12343; Tue, 27 Dec 1994 16:55:08 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:thom@temp4.rest.tasc.com id AA19154; Tue, 27 Dec 94 16:44:11 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA28691; Tue, 27 Dec 1994 16:43:59 -0800 From: "Michael Jones" Message-Id: <9412271643.ZM28689@babar.asd.sgi.com> Date: Tue, 27 Dec 1994 16:43:59 -0800 In-Reply-To: "Thom DeCarlo" "Performer reads .iv. NOT!" (Dec 12, 11:04am) References: <9412121104.ZM13883@temp4.is.rest.tasc.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Thom DeCarlo" , info-performer@sgi.sgi.com Subject: Re: Performer reads .iv. NOT! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O The IRIS Inventor loader shipped with IRIS Performer 1.2 is very minimal and only reads a subset of the Inventor format. We are working hard to get the complete and comprehensive loader through the performance tuning phase and posted here in the mailing list within the next few days. Stay tuned for more information... -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Dec 27 17:15:50 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA19212; Tue, 27 Dec 1994 16:53:35 -0800 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 QAA19209; Tue, 27 Dec 1994 16:53:34 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19345; Tue, 27 Dec 94 16:53:29 -0800 Received: from chris.gcs.redstone.army.mil by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id QAA09483; Tue, 27 Dec 1994 16:53:24 -0800 Received: from sgigate.SGI.COM by chris.gcs.redstone.army.mil via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.com id AA15559; Tue, 27 Dec 94 18:55:57 -0600 Received: from sgihub.corp.sgi.com by sgigate.sgi.com via ESMTP (940627.SGI.8.6.9/911001.SGI) id QAA14025; Tue, 27 Dec 1994 16:53:09 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id QAA11675; Tue, 27 Dec 1994 16:53:02 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:curry@chris.gcs.redstone.army.mil id AA19335; Tue, 27 Dec 94 16:52:59 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA28702; Tue, 27 Dec 1994 16:52:57 -0800 From: "Michael Jones" Message-Id: <9412271652.ZM28700@babar.asd.sgi.com> Date: Tue, 27 Dec 1994 16:52:57 -0800 In-Reply-To: curry@chris.gcs.redstone.army.mil (Tim Curry) "Accessing Frame Buffer" (Dec 12, 1:22pm) References: <9412121922.AA19696@chris.gcs.redstone.army.mil> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: curry@chris.gcs.redstone.army.mil (Tim Curry), "<""@chris.gcs.redstone.army.mil>"@chris.gcs.redstone.army.mil Subject: Re: Accessing Frame Buffer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 12, 1:22pm, Tim Curry wrote: > Subject: Accessing Frame Buffer :I am trying to read the video frame buffer very quickly so I can :perform some image processing on the image and write it back to the frame :buffer. Doing lrectreads is very very slow because I am trying to achieve 60 Hz. :I would like to see SGI give the user access to the VRAM via fast cache :or RAM. I know the RE hardware documents the voltages to the frame buffer :for 3rd party hardware to interface. Does anyone have a faster solution :to reading the frame buffer. There are two choices: lrectread() and DVI. The lrectread approach can sometimes be optimized by packing the data for transfer so that it uses less bits. Are 24 (or 32) bits necessary for your application? There is a user interface on the "back-end" of the RealityEngine that can be used to drain the frame buffer. This is used by several of the hardware-in-the-loop simulation customers who need to perform special operations on the video output stream. I can say that the hardware frame-buffer interface of the RealityEngine and RealityEngine2 (the same interface) and future unnamed products are different so it is probably not reasonable to build an RE2-style board at this point -- more than two years after RE was first introduced. :email: Tim Curry/MICOM :phone: (205)876-7219 : >-- End of excerpt from Tim Curry Could it be that the famous "Dr. Frankenfurter" is a Performer user? -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Dec 27 17:19:18 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA19223; Tue, 27 Dec 1994 16:59:11 -0800 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 QAA19220; Tue, 27 Dec 1994 16:59:10 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19474; Tue, 27 Dec 94 16:59:08 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id QAA09928; Tue, 27 Dec 1994 16:59:07 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id QAA12878; Tue, 27 Dec 1994 16:59:04 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:maytorre@NMSU.Edu id AA19467; Tue, 27 Dec 94 16:58:56 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA28714; Tue, 27 Dec 1994 16:58:49 -0800 From: "Michael Jones" Message-Id: <9412271658.ZM28712@babar.asd.sgi.com> Date: Tue, 27 Dec 1994 16:58:49 -0800 In-Reply-To: maytorre@NMSU.Edu "Performer reads iv. Maybe!" (Dec 12, 12:59pm) References: <199412121959.MAA18246@NMSU.Edu> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: maytorre@NMSU.Edu, info-performer@sgi.sgi.com Subject: Re: Performer reads iv. Maybe! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 12, 12:59pm, maytorre@NMSU.Edu wrote: > Subject: Performer reads iv. Maybe! : We've had partial success loading inventor files into perfly program. :Particularly I've created a simple black box (cube) with showcase and :saved it as an Inventor file. I can the see the Inventor file with an :Inventor ivquicken. When I tried loading the box.iv *BINARY* file into :perfly I obtained similar problems as you did. My solution was to use :ivquicken to "improve" the inventor scene graph's rendering performance :and to convert it to an ascii file. Then perfly had no problem loading :the ascii file, though perfly may have problems with some Inventor ascii :files some of the time etc. Anyway, I've read that the Performer's :function that reads the iv files is not complete and thus misbehaves when :its given an Inventor symbol that it does not recognize. The Inventor loader shipped with IRIS Performer 1.2 is a wimpy one. It only reads the ASCII format files. In fact, page 209 of the IRIS Performer Programming Guide says: The IRIS Inventor data-file loader provided with IRIS Performer reads only ASCII-format IRIS Inventor 1.0 files. If you have files in the IRIS Inventor binary format you must convert them to ASCII using the ivcat program before importing them into IRIS Performer. :But I sure wish that Performer had it together with these Inventor files. Good news for you, then, since the next release of IRIS Performer will include the fully-capable loader for IRIS Inventor 2.0 files that we are now in the final testing and tuning stages of developing. We hope to make it available to the info-performer mailing list readers within the next few days for your evaluation. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Dec 27 17:49:16 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA19373; Tue, 27 Dec 1994 17:27:50 -0800 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 RAA19369; Tue, 27 Dec 1994 17:27:49 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA20148; Tue, 27 Dec 94 17:27:47 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id RAA12697; Tue, 27 Dec 1994 17:27:45 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id RAA14828; Tue, 27 Dec 1994 17:27:41 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:thom@temp4.rest.tasc.com id AA20143; Tue, 27 Dec 94 17:27:35 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA28790; Tue, 27 Dec 1994 17:27:30 -0800 From: "Michael Jones" Message-Id: <9412271727.ZM28788@babar.asd.sgi.com> Date: Tue, 27 Dec 1994 17:27:30 -0800 In-Reply-To: "Thom DeCarlo" "Re: Performer reads iv. Maybe!" (Dec 12, 4:02pm) References: <199412121959.MAA18246@NMSU.Edu> <9412121602.ZM892@temp4.is.rest.tasc.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Thom DeCarlo" , maytorre@nmsu.edu Subject: Re: Performer loading Inventor files -- The whole story (long) Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 12, 4:02pm, Thom DeCarlo wrote: > Subject: Re: Performer reads iv. Maybe! :Yeah, IMHO, the Performer team blew it big time by not giving Inventor better :coverage. It was my decision, not the team's. At the time of our release I felt that it was necessary to support both IRIX 4.0.5 and 5.x customers with our IRIS Performer 1.2 product. Since the version of IRIS Inventor for 4.0.5 lacks the key feature required for a successful Inventor-format loader, I just gave up on a complete solution and hacked out the loader that you love to hate one afternoon a week before our release. The key feature is the ability to ask Inventor to give back the polygons it would draw at any node. This is required to allow for importation of procedural objects such as cones and spline-edged text. Without it we'd have to implement all of Inventor just to provide file import capability. Since the next release of IRIS Performer will be based on IRIX 5.3, we can now take advantage of this feature of IRIS Inventor 2.0 to bring you a fully working loader that reads *all* Inventor files (binary and ASCII) and handles complexity-nodes, NURB surfaces, and the other "hard to translate just by looking at the file format" nodes correctly. It's hard for me to agree that this course of action was a big mistake since the number of Inventor users seemed very small at the time and our desire to have identical capability in the IRIX 4.0.5 and 5.x versions of Performer was so very great. If its any consolation, we're working hard on robust IRIS Inventor support at this time. In fact, now that Silicon Studio has selected IRIS Performer for it's entertainment authoring developments and the IRIS Inventor format for the external representation, we have a very focused effort to support both the complete format and the full set of Inventor widgets and manipulators within the Performer scene-graph. Anybody who uses either Inventor or Performer is sure to benefit from these current development efforts. :I read in the FAQ that a more complete Inventor reader was to be :distributed through the info-performer mailing list "at a future time." I guess :the future hasn't happened yet. In the mean time, I've pulled a copy of pfiv.c :out of /usr/src/Performer/... and I'm trying to hack out my own LoadIv() :function. The future was delayed slightly as we strove to make the new loader more efficient. The first version, though complete in it's support, lacked automatic sharing of textures and materials throughout the scene-graph, reducing performance to about 2x that of IRIS Inventor. Now that we've put more effort into the loader and it's ingenuity about sharing geostates and the geostate components, we've been able to considerably improve that ratio closer to the IRIS Performer efficiency with other file formats, such as Wavefront, OpenFlight, and Designer's Workbench. We're working hard to get the new loader out via the mailing list this week, so check your email for the latest info. Remember though that this will only work for those IRIS Performer 1.2 users who have upgraded to IRIX 5.x -- IRIX 4.0.5 users will never have full Inventor import capability. :That's another thing. I've been reading Gavin Bell's postings in :comp.sys.sgi.graphics. He is asking if any Inventor users would be upset if :Inventor's C API were to disappear in a future (the next?) release. I guess :we'd better hope the Performer team is moving to C++ or we are really going to :be left out in the cold. IRIS Performer's written in C, C++, and MIPS Assembler. The utility code and all other source is distributed in C for broadest usability. The new Inventor loader is in both C and C++, so you'll need the C++ compiler if you want to recompile it. We'll be distributing the object code DSO as well as the source though, so you can use it without having the C++ compiler if you don't want to change it. We will be compiling all of Performer with the C++ compiler in the next release but plan to keep the utility library source in C. Any comments on this plan? What would you prefer? :Thanks again. :Thom Thank you for your postings. We try to serve each of our customers well and we slip from time to time. Thanks for being patient with us on the Inventor-loader issue. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Dec 27 17:55:36 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA19433; Tue, 27 Dec 1994 17:32:00 -0800 Return-Path: Received: from babar.asd.sgi.com by holodeck.asd.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA19430; Tue, 27 Dec 1994 17:31:59 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA28823; Tue, 27 Dec 1994 17:31:52 -0800 From: "Michael Jones" Message-Id: <9412271731.ZM28821@babar.asd.sgi.com> Date: Tue, 27 Dec 1994 17:31:52 -0800 In-Reply-To: michael@ifr.luftfahrt.uni-stuttgart.de "Re: Performer reads iv. Maybe!" (Dec 13, 9:36am) References: <9412130836.AA06472@ifr1.Luftfahrt.Uni-Stuttgart.DE> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: michael@ifr.luftfahrt.uni-stuttgart.de, Jim Helman Subject: Re: Performer reads iv. Maybe! Cc: info-performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 13, 9:36am, michael@ifr.luftfahrt.uni-stuttgart.de wrote: > Subject: Re: Performer reads iv. Maybe! :What about the Ada95 interface to Performer. I haven't heared :anything about it for quite a while now. I hope there are many :more people interested in that and not just me. This is planned and undertaken by SGI's Ada-guru, Wes Embry. If you want to vote for the Ada API shipping with the next release of IRIS Performer, send your request to: Wes Embry wes@wpd.sgi.com (415)390-1563 The Ada group, like the rest of Silicon Graphics engineering, tries to respond to needs voiced by customers. Give Wes a call or send email if the Ada API is important to you. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Dec 27 18:02:04 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA19468; Tue, 27 Dec 1994 17:37:36 -0800 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 RAA19465; Tue, 27 Dec 1994 17:37:36 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA20381; Tue, 27 Dec 94 17:37:35 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id RAA13290; Tue, 27 Dec 1994 17:37:34 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id RAA15210; Tue, 27 Dec 1994 17:37:32 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:fuja@dis.anl.gov id AA20373; Tue, 27 Dec 94 17:37:31 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA28838; Tue, 27 Dec 1994 17:37:30 -0800 From: "Michael Jones" Message-Id: <9412271737.ZM28836@babar.asd.sgi.com> Date: Tue, 27 Dec 1994 17:37:30 -0800 In-Reply-To: Russell Fuja "Conversion from MicroStation to Performer" (Dec 13, 2:20pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Russell Fuja , info-performer@sgi.sgi.com Subject: Re: Conversion from MicroStation to Performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 13, 2:20pm, Russell Fuja wrote: > Subject: Conversion from MicroStation to Performer :I have an application where I need to take a number of 3d models :from an Intergraph MicroStation and eventually display them in :Performer. I am looking for help in determining how to convert :the models into a format suitable for a 3d modeling packages :such as ModelGen or whatever. MicroStation supports export :into DXF (which CANNOT be used because of the information lost in :conversion) and the IGES format. Does anyone know how to convert :a model in IGES into something Performer can read (like OpenFlight, :or IRIS Inventor, or whatever is appropriate)? Can someone point :me to a modeler program or a bit of conversion code? The IRIS Inventor group has developed a new suite of sophisticated file converters which I believe includes the IGES format. Once our new comprehensive Inventor-format loader is available, the best sounding route would be: MicroStation -> IGES -> IGEStoIV -> LoadIv -> Performer My understanding is that the Inventor group is now in the beta-test phase on the new converters, so you may want to check with Gavin Bell (gavin@engr.sgi.com) about obtaining the IGES converter and then keep checking the info-performer mailing list for the availablity of our new comprehensive Inventor loader. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Dec 27 18:12:00 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA19518; Tue, 27 Dec 1994 17:48:56 -0800 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 RAA19515; Tue, 27 Dec 1994 17:48:56 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA20582; Tue, 27 Dec 94 17:48:55 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id RAA14109; Tue, 27 Dec 1994 17:48:53 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id RAA15878; Tue, 27 Dec 1994 17:48:52 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:sakai@sgi600.msd.lmsc.lockheed.com id AA20577; Tue, 27 Dec 94 17:48:43 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA28863; Tue, 27 Dec 1994 17:48:42 -0800 From: "Michael Jones" Message-Id: <9412271748.ZM28861@babar.asd.sgi.com> Date: Tue, 27 Dec 1994 17:48:42 -0800 In-Reply-To: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) "Any estimate of when Performer 2.0 will ship?" (Dec 16, 2:25pm) References: <9412162225.AA13268@sgi600.msd.lmsc.lockheed.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai), info-performer@sgi.sgi.com Subject: Re: Any estimate of when Performer 2.0 will ship? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 16, 2:25pm, Ken Sakai wrote: > Subject: Any estimate of when Performer 2.0 will ship? :I was wondering if the Performer Team would like to venture a best guess :at a Performer 2.0 shipping date. 1st quarter 1995, 2nd quarter 1995, ... ? :We are anxiously awaiting its arrival (especially the C++ bindings) and would :like to make plans for the next year. We are on schedule to achieve manufacturing release of IRIS Performer 2.0 in March of 1995. This is when we give the "golden CD" to manufacturing for reproduction and distribution. Actual shipment will occur one to three weeks after that date, so expect your CD's to arrive in mid to late April if you have software maintenance, or else contact your sales office. This is the plan, and like all plans, is subject to change in the event of unforseen circumstances. We're on schedule, looking good, and working hard, so I don't expect any schedule or feature slips. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Dec 27 18:30:39 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA19573; Tue, 27 Dec 1994 18:06:17 -0800 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 SAA19570; Tue, 27 Dec 1994 18:06:13 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA21075; Tue, 27 Dec 94 18:06:12 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id SAA15626; Tue, 27 Dec 1994 18:06:10 -0800 Received: from indy.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA19306; Tue, 27 Dec 94 21:07:32 EST From: fred@vsl.ist.ucf.edu (ALFREDO) Received: by indy.vsl.ist.ucf.edu (931110.SGI) id AA12590; Tue, 27 Dec 94 21:06:43 -0500 Date: Tue, 27 Dec 94 21:06:43 -0500 Message-Id: <9412280206.AA12590@indy.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: intersection callback Status: O Hi, I am trying to implement an intersection callback function (using the pfSegsIsectNode function) to avoid jumping on bridges, trees or whatever while driving on my terrain. 1) In the definition of the pfSegSet structure, there is a 'void* userData'. How can I get a pointer to it in my callback function ? 2) I am doing several intersections at the same time. The first segment is for this ground collision problem. I thought that I could use a call to pfQueryHit with a PFQHIT_SEGNUM type, but it seems to return pointer values instead of an index number -> is it what I should get? is it a bug or am i stupid ? (please, don't answer directly to this last question) Thank you for any comment, and happy new year!!!! ____________________ / \ ! TAZ for ! ! PRESIDENT ! \____________________/ ! ! ! ! L_ ! / _)! "%@&*&*&(*()*^(()^(% ", he said / /__L _____/ (____) Al Fredo (____) _____ (____) \_(____) ! ! ! ! \__/ From guest Wed Dec 28 11:11:06 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA21122; Wed, 28 Dec 1994 10:49:07 -0800 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 KAA21119; Wed, 28 Dec 1994 10:49:06 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03217; Wed, 28 Dec 94 10:49:05 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id KAA03409; Wed, 28 Dec 1994 10:49:04 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id KAA24756; Wed, 28 Dec 1994 10:49:02 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:fred@vsl.ist.ucf.edu id AA03212; Wed, 28 Dec 94 10:48:50 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id KAA00030; Wed, 28 Dec 1994 10:48:46 -0800 From: "Michael Jones" Message-Id: <9412281048.ZM28@babar.asd.sgi.com> Date: Wed, 28 Dec 1994 10:48:45 -0800 In-Reply-To: fred@vsl.ist.ucf.edu (ALFREDO) "intersection callback" (Dec 27, 9:06pm) References: <9412280206.AA12590@indy.vsl.ist.ucf.edu> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: fred@vsl.ist.ucf.edu (ALFREDO), info-performer@sgi.sgi.com Subject: Re: intersection callback Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 27, 9:06pm, ALFREDO wrote: > Subject: intersection callback :I am trying to implement an intersection callback function (using the :pfSegsIsectNode function) to avoid jumping on bridges, trees or whatever :while driving on my terrain. An even easier method is available to you. Change the intersection search vector geometry. Right now, the default mechanism is to send a vector down toward the eyepoint from way up in the air (I think its 25000 meters). Just change this to be downward from a few inches or feet above the last intersection result and you'll be OK in most situations. Alternately, you can get back all the results, and take the closest one to the last intersection. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Wed Dec 28 11:17:04 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA21143; Wed, 28 Dec 1994 10:55:56 -0800 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 KAA21140; Wed, 28 Dec 1994 10:55:55 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA03309; Wed, 28 Dec 94 10:55:55 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id KAA03973; Wed, 28 Dec 1994 10:55:53 -0800 Received: from indy.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA21144; Wed, 28 Dec 94 13:57:14 EST From: fred@vsl.ist.ucf.edu (ALFREDO) Received: by indy.vsl.ist.ucf.edu (931110.SGI) id AA14734; Wed, 28 Dec 94 13:56:25 -0500 Date: Wed, 28 Dec 94 13:56:25 -0500 Message-Id: <9412281856.AA14734@indy.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: intersection callback Status: O Hi, well, that's right, I decided to use a smaller intersection vector (that actually helps me to take into account the limitations of my vehicle, i.e. the maximum slope it can handle...), and I change the intersection masks of the different elements of my terrain. However, while I was experimenting, I could not get any correct value from my pfMQueryHit call in my callback function, but the exact same query in the main application works fine. I don't use multiprocess mode (to simplify your suggestions). And I'd like to know what could be wrong anyway, in case of future use.... Same thing for this 'void* userData' pointer in the pfSegSet structure..... Thank you ____________________ / \ ! TAZ for ! ! PRESIDENT ! \____________________/ ! ! ! ! L_ ! / _)! "%@&*&*&(*()*^(()^(% ", he said / /__L _____/ (____) Al Fredo (____) _____ (____) \_(____) ! ! ! ! \__/ From guest Wed Dec 28 11:55:27 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA21300; Wed, 28 Dec 1994 11:33:20 -0800 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 LAA21297; Wed, 28 Dec 1994 11:33:19 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA04361; Wed, 28 Dec 94 11:33:15 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id LAA08184; Wed, 28 Dec 1994 11:33:13 -0800 Received: from indy.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA21296; Wed, 28 Dec 94 14:34:35 EST From: fred@vsl.ist.ucf.edu (ALFREDO) Received: by indy.vsl.ist.ucf.edu (931110.SGI) id AA14850; Wed, 28 Dec 94 14:33:45 -0500 Date: Wed, 28 Dec 94 14:33:45 -0500 Message-Id: <9412281933.AA14850@indy.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: intersection callback Status: O Hi, well, that's right, I decided to use a smaller intersection vector (that actually helps me to take into account the limitations of my vehicle, i.e. the maximum slope it can handle...), and I changed the intersection masks of the different elements of my terrain. However, while I was experimenting, I could not get any correct value from my pfMQueryHit call in my callback function, but the exact same query in the main application works fine. I don't use multiprocess mode (to simplify your suggestions). And I'd like to know what could be wrong anyway, in case of future use.... Same thing for this 'void* userData' pointer in the pfSegSet structure..... Thank you ____________________ / \ ! TAZ for ! ! PRESIDENT ! \____________________/ ! ! ! ! L_ ! / _)! "%@&*&*&(*()*^(()^(% ", he said / /__L _____/ (____) Al Fredo (____) _____ (____) \_(____) ! ! ! ! \__/ From guest Wed Dec 28 18:55:43 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA22338; Wed, 28 Dec 1994 18:37:32 -0800 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 SAA22335; Wed, 28 Dec 1994 18:37:31 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA13825; Wed, 28 Dec 94 18:37:30 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id SAA15401; Wed, 28 Dec 1994 18:37:29 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id SAA06962; Wed, 28 Dec 1994 18:37:27 -0800 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:fred@vsl.ist.ucf.edu id AA13820; Wed, 28 Dec 94 18:37:26 -0800 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id SAA11566; Wed, 28 Dec 1994 18:37:25 -0800 Message-Id: <199412290237.SAA11566@surreal.asd.sgi.com> To: fred@vsl.ist.ucf.edu (ALFREDO) Cc: info-performer@sgi.sgi.com Subject: Re: intersection callback In-Reply-To: Your message of "Tue, 27 Dec 94 21:06:43 EST." <9412280206.AA12590@indy.vsl.ist.ucf.edu> Date: Wed, 28 Dec 94 18:37:25 -0800 From: Jim Helman Status: O The most efficient method of restricting intersection cases is to use the intersection masks in the scene graph to create different classes of geometry. If you don't care about intersections with a particular class of geometry, then don't OR its bit into the query's intersection mask. > 1) In the definition of the pfSegSet structure, there is a 'void* userData'. > How can I get a pointer to it in my callback function ? The pfSegSet's userdata pointer can be queried from the pfHit using pfGetUserData. 2.0's man pages will mention this. > 2) I am doing several intersections at the same time. The first segment > is for this ground collision problem. I thought that I could use a call > to pfQueryHit with a PFQHIT_SEGNUM type, but it seems to return pointer > values instead of an index number -> is it what I should get? It should be returning the index of the line segment. I can't duplicate the problem, but will look at it if you can narrow your problem down to a small test case. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 29 03:58:30 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA23137; Thu, 29 Dec 1994 03:34:18 -0800 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 DAA23134; Thu, 29 Dec 1994 03:34:14 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19480; Thu, 29 Dec 94 03:34:13 -0800 Received: from iss.nus.sg by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id DAA07196; Thu, 29 Dec 1994 03:34:09 -0800 Received: from whitehead.iss.nus.sg by iss.nus.sg (5.x/SMI-SVR4) id AA26069; Thu, 29 Dec 1994 19:38:18 +0800 Date: Thu, 29 Dec 1994 19:38:18 +0800 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9412291138.AA26069@iss.nus.sg> Received: by whitehead.iss.nus.sg (5.0/SMI-SVR4) id AA00707; Thu, 29 Dec 94 19:38:17 SST To: info-performer@sgi.sgi.com Subject: Character strings Status: O Hi, I need to attach strings to objects in a scene. Unfortunately text strings don't seem to be in Performer (an odd ommision). In: ./src/pguide/libpf/progs/text.c there is an example on how to use gl text. My question is: Is this the best way to do things? It seems quite clumsy and slow. We would have to do a callback in the draw process, grab the text string off the data field of the node, push the matrix, draw the text, pop the matrix, etc. Is there any other way to do this? In general, can anyone send me examples on how to use multifont and/or translateable text? thanks, Kim. From guest Thu Dec 29 08:28:37 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA23681; Thu, 29 Dec 1994 08:03:38 -0800 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 IAA23678; Thu, 29 Dec 1994 08:03:37 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA22230; Thu, 29 Dec 94 08:03:36 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id IAA18094; Thu, 29 Dec 1994 08:03:35 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id IAA03170; Thu, 29 Dec 1994 08:03:32 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:fair@iss.nus.sg id AA22225; Thu, 29 Dec 94 08:03:28 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/911001.SGI) id IAA03657; Thu, 29 Dec 1994 08:03:23 -0800 From: "Michael Jones" Message-Id: <9412290803.ZM3655@babar.asd.sgi.com> Date: Thu, 29 Dec 1994 08:03:22 -0800 In-Reply-To: fair@iss.nus.sg (Kim Michael Fairchild) "Character strings" (Dec 29, 7:38pm) References: <9412291138.AA26069@iss.nus.sg> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: fair@iss.nus.sg (Kim Michael Fairchild), info-performer@sgi.sgi.com Subject: Re: Character strings Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Dec 29, 7:38pm, Kim Michael Fairchild wrote: > Subject: Character strings :I need to attach strings to objects in a scene. Unfortunately text :strings don't seem to be in Performer (an odd ommision). I can see how this omission would seem odd. The fact is, though, that the hardware supports only one kind of "text" and that's bit-map fonts. Any more sophisticated type of text, such as vector fonts or 2D and 3D polygonal text, is simply a collection of lines or triangles -- which IRIS Performer supports well. :In: ./src/pguide/libpf/progs/text.c :there is an example on how to use gl text. Exactly. :My question is: : :Is this the best way to do things? In fact, it is the only way... :It seems quite clumsy and slow. We would have to do a callback in the :draw process, grab the text string off the data field of the node, :push the matrix, draw the text, pop the matrix, etc. ...exactly what a pfBitmapText node would need to do. There seems to be no performance advantage to us doing it inside Performer, which is why we left it out. However, ... :Is there any other way to do this? In general, can anyone send me :examples on how to use multifont and/or translateable text? ...if it's going to be too much of a hastle for people, we could look into providing pfutil code to handle text. How many people feel that this would be more important than, say, multi-axis billboards? -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Thu Dec 29 08:58:26 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA23709; Thu, 29 Dec 1994 08:35:05 -0800 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 IAA23706; Thu, 29 Dec 1994 08:34:53 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA22654; Thu, 29 Dec 94 08:34:52 -0800 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id IAA20412; Thu, 29 Dec 1994 08:34:51 -0800 Received: from knuth.oslo.sgi.com by sgihub.corp.sgi.com via ESMTP (940519.SGI.8.6.9/911001.SGI) for id IAA05186; Thu, 29 Dec 1994 08:34:48 -0800 Received: by knuth.oslo.sgi.com (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.sgi.com id QAA00962; Thu, 29 Dec 1994 16:39:35 +0100 From: "knut ivar foshaug" Message-Id: <9412291639.ZM960@knuth.oslo.sgi.com> Date: Thu, 29 Dec 1994 16:39:35 +0100 X-Mailer: Z-Mail-SGI (3.0S.1016 16oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Please unsubscribe me ! Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O knut@oslo.sgi.com -- ------------------------------------------------- - Knut Ivar Foshaug - - Email: knut@oslo.sgi.com - - Tlf: +47 22 73 00 29 - - Mailstop: INO-335 - - VoiceMail: 5-8600 - ------------------------------------------------- From guest Thu Dec 29 14:15:26 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA24816; Thu, 29 Dec 1994 13:56:03 -0800 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 NAA24813; Thu, 29 Dec 1994 13:55:58 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA00692; Thu, 29 Dec 94 13:55:54 -0800 Received: from killerbee.jsc.nasa.gov by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id NAA25398; Thu, 29 Dec 1994 13:55:53 -0800 Received: by killerbee.jsc.nasa.gov (8.6.9/Ultrix4.2) id PAA08702; Thu, 29 Dec 1994 15:57:37 -0600 From: petert@killerbee.jsc.nasa.gov (Peter Tran) Message-Id: <199412292157.PAA08702@killerbee.jsc.nasa.gov> Subject: unsubscribe ! To: info-performer@sgi.sgi.com Date: Thu, 29 Dec 1994 15:57:35 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 35 Status: O petert@killerbee.jsc.nasa.gov From guest Thu Dec 29 18:40:47 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA25695; Thu, 29 Dec 1994 18:18:58 -0800 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 SAA25692; Thu, 29 Dec 1994 18:18:54 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA09103; Thu, 29 Dec 94 18:18:49 -0800 Received: from redgate.vislab.su.edu.au by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id SAA19064; Thu, 29 Dec 1994 18:18:46 -0800 Received: from cazneaux.vislab.su.edu.au by redgate.vislab.su.edu.au via SMTP (931110.SGI/921111.SGI) for info-performer@sgi.com id AA19267; Fri, 30 Dec 94 13:18:43 +1100 Received: by cazneaux.vislab.su.edu.au (931110.SGI/921111.SGI) for info-performer@sgi.com id AA09974; Fri, 30 Dec 94 13:18:42 +1100 From: "Chris Willing" Message-Id: <9412301318.ZM9972@cazneaux.vislab.su.edu.au> Date: Fri, 30 Dec 1994 13:18:42 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Character strings Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Regarding requests for indications of the relative importance of text handling vs. multi-axis billboards, my vote is for TEXT HANDLING. Multi-axis billboards will be nice sometime, but I could use some text handling utilities right about now. -- -- +----------------------------------------------------------------------+ | Chris Willing Telephone 02 692 3914 | | VisLab, A28 Facsimile 02 660 2903 | | University of Sydney email chris@vislab.su.edu.au | | NSW 2006 Australia cwilling@isu.usyd.edu.au | +----------------------------------------------------------------------+ From guest Fri Dec 30 01:15:33 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA26505; Fri, 30 Dec 1994 00:55:19 -0800 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 AAA26502; Fri, 30 Dec 1994 00:55:15 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA19115; Fri, 30 Dec 94 00:55:10 -0800 Received: from hp720a.csc.cuhk.hk by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id AAA08992; Fri, 30 Dec 1994 00:55:01 -0800 Message-Id: <199412300855.AAA08992@sgi.sgi.com> Received: from hell.csc.cuhk.hk by hp720a.csc.cuhk.hk with SMTP (1.37.109.10G/16.2) id AA063827710; Fri, 30 Dec 1994 16:55:10 +0800 Date: Fri, 30 Dec 1994 16:55:10 +0800 From: anton-lam@cuhk.hk (Anton Lam) To: info-performer@sgi.sgi.com Subject: TECH: Logitech's 3D Flying Mouse and SGI Performer Newsgroups: sci.virtual-worlds Organization: The Chinese University of Hong Kong Status: O Dear all, Is anyone using the 3D Flying Mouse from Logitech with SGI, especially with Performer? Do we need to do any low-level programming with the serial port in order to communicate with the Mouse? Any info are welcome. -- Anton Lam Computer Services Centre The Chinese University of Hong Kong From guest Fri Dec 30 05:33:03 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA26817; Fri, 30 Dec 1994 05:12:10 -0800 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 FAA26814; Fri, 30 Dec 1994 05:12:06 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA23630; Fri, 30 Dec 94 05:12:01 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id FAA18034; Fri, 30 Dec 1994 05:12:00 -0800 Received: from grandpa.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA25705; Fri, 30 Dec 94 08:13:22 EST Received: by grandpa.vsl.ist.ucf.edu (931110.SGI) id AA12038; Fri, 30 Dec 94 08:13:20 -0500 Date: Fri, 30 Dec 1994 08:13:19 -0500 (EST) From: "Michael J. Smith" To: performer Subject: ALT Key in the Event Q Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I was looking through the ways to access the special keys on the keyboard such as the shift, ctrl, and alt keys. It appears there is support for both the shift and the ctrl keys, but not the alt keys. Is this an oversight on my part, or was it simply not included? ----------------------------------------------------------------------------- | 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 | ----------------------------------------------------------------------------- From guest Fri Dec 30 05:53:05 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA26836; Fri, 30 Dec 1994 05:33:49 -0800 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 FAA26833; Fri, 30 Dec 1994 05:33:45 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA24014; Fri, 30 Dec 94 05:33:44 -0800 Received: from server1.ctc.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id FAA18632; Fri, 30 Dec 1994 05:33:42 -0800 Received: by server1.ctc.com (5.65/DEC-Ultrix/4.3) id AA21956; Fri, 30 Dec 1994 08:34:33 -0500 Received: by sgi81.ctc.com (931110.SGI/921111.SGI.AUTO) for @server1.ctc.com:info-performer@sgi.com id AA17994; Fri, 30 Dec 94 08:34:31 -0500 Date: Fri, 30 Dec 94 08:34:31 -0500 From: koopman@ctc.com (Michael G. Koopman) Message-Id: <9412301334.AA17994@sgi81.ctc.com> To: chris@vislab.su.edu.au Cc: info-performer@sgi.sgi.com In-Reply-To: "Chris Willing"'s message of Fri, 30 Dec 1994 13:18:42 -0500 <9412301318.ZM9972@cazneaux.vislab.su.edu.au> Subject: Character strings Reply-To: koopman@ctc.com Status: O Chris Willing and others interested in "TEXT HANDLING." What is it in your visual simulation that requires so much text handling? Heads-up displays are about the only simulation augmentation that seems to require significant text handling. Even at that, this type of text handling seems to benefit from use of billboards. > Multi-axis billboards will be nice sometime, but I could use some text > handling utilities right about now. Text handling on multi-axis billboards seems like a most useful concept to me. This would allow a text indicator to read differently depending on perspective, and if the "text handling" was what it should be cut out to do for such things - would size fonts, use 2D or 3D fonts, etc. based on POV quantities such as line of sight distance, viewing frustrum distended. But, if we ask to go to the stars, the performer group might just get us to Mars (Although, robots would be cheaper and eat so much less). Thanks for listening, Michael Koopman (mike) Computer Systems Specialist Concurrent Technologies Corporation internet: koopman@ctc.com 1450 Scalp Avenue phone: +1-814-269-2637 Johnstown, PA 15904-3321 USA telefax: +1-814-269-2402 From guest Fri Dec 30 12:33:21 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA27455; Fri, 30 Dec 1994 12:11:07 -0800 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 MAA27452; Fri, 30 Dec 1994 12:11:06 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA00586; Fri, 30 Dec 94 12:11:05 -0800 Received: from ucsd.edu by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id MAA13845; Fri, 30 Dec 1994 12:11:03 -0800 From: sbrown@nestor.UCSD.EDU Received: from nestor by ucsd.edu; id MAA04832 sendmail 8.6.9/UCSD-2.2-sun via SMTP Fri, 30 Dec 1994 12:11:02 -0800 for <@ucsd.edu:info-performer@sgi.com> Received: by nestor (931110.SGI/930416.SGI) for @ucsd.edu:info-performer@sgi.com id AA07327; Fri, 30 Dec 94 12:09:07 -0800 Message-Id: <9412301209.ZM7325@nestor.ucsd.edu> Date: Fri, 30 Dec 1994 12:09:04 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: (Fwd) TECH: Logitech's 3D Flying Mouse and SGI Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Get the libraries for support from Logitech. You may have to bug them a few times, but they do have them, and they do work with Performer. The only problems that we have found is that they do error checking too often and that needs to be buffered. On Dec 30, 4:55pm, Anton Lam wrote: > Subject: TECH: Logitech's 3D Flying Mouse and SGI Performer > Dear all, > > Is anyone using the 3D Flying Mouse from Logitech with SGI, especially > with Performer? > Do we need to do any low-level programming with the serial port in order > to communicate with the Mouse? > > Any info are welcome. > > -- > Anton Lam > Computer Services Centre > The Chinese University of Hong Kong >-- End of excerpt from Anton Lam -- Sheldon Brown Assistant Professor Visual Arts Dept. University of California at San Diego 9500 Gilman Drive La Jolla, CA 92093 (619) 534-2423 Fax (619)534-7944 sgbrown@ucsd.edu From guest Fri Dec 30 12:39:25 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA27468; Fri, 30 Dec 1994 12:18:12 -0800 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 MAA27465; Fri, 30 Dec 1994 12:18:12 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA00849; Fri, 30 Dec 94 12:18:11 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id MAA14314; Fri, 30 Dec 1994 12:18:09 -0800 Received: from osiris.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA26999; Fri, 30 Dec 94 15:19:32 EST From: fred@vsl.ist.ucf.edu (ALFREDO) Received: by osiris.vsl.ist.ucf.edu (931110.SGI) id AA05666; Fri, 30 Dec 94 15:19:30 -0500 Date: Fri, 30 Dec 94 15:19:30 -0500 Message-Id: <9412302019.AA05666@osiris.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: pfuTraverser Status: O Hi, I am using a pfuTraverser to check for attributes in my scene. I set the 'data' field to a pointer value, a basic trav.data=(void*)this. If I compile under irix 4.05, it works fine and I can get the value with a classType* instance = (classType*)trav->data in the traverser callback function. But if I compile under 5.2, it does not work at all and I get a null value for 'instance' in the callback function. Any idea???? Thanks ____________________ / \ ! TAZ for ! ! PRESIDENT ! \____________________/ ! ! ! ! L_ ! / _)! "%@&*&*&(*()*^(()^(% ", he said / /__L _____/ (____) Al Fredo (____) _____ (____) \_(____) ! ! ! ! \__/ From guest Fri Dec 30 16:43:54 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA27800; Fri, 30 Dec 1994 16:25:13 -0800 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 QAA27797; Fri, 30 Dec 1994 16:25:08 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA06876; Fri, 30 Dec 94 16:25:04 -0800 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for id QAA16180; Fri, 30 Dec 1994 16:25:02 -0800 Received: from crusader.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA27324; Fri, 30 Dec 94 17:12:43 EST Received: by crusader.vsl.ist.ucf.edu (920330.SGI) id AA09391; Fri, 30 Dec 94 17:11:54 -0500 Date: Fri, 30 Dec 1994 17:11:53 -0500 (EST) From: "Lance R. Marrou" To: Performer List Subject: GL and X input Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O As Mike mentioned, ALT key polling is not supported in the pfu input routines (neither X nor GL input). You can still get the events, though, through the user handler function, but it might be just as easy to support polling yourself in the draw process (through the typical Performer shared memory structure :). Also, I noticed a problem with the X polling of the modifier keys. The 'keymod' variable is reset to 0 everytime that the X input is collected in the asynchronous process. (in collectXInput of input.c). This makes those modifier keys non-polling. Although collectGLInput does the same, I assume the X returns true only upon events (rather the getdev which will return true as long as the key is held down). Am I mistaken here? _______________________________________________________ E-mail: marrou@vsl.ist.ucf.edu IST __ WWW: http://www.vsl.ist.ucf.edu/~marrou Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Sat Dec 31 08:08:10 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA29243; Sat, 31 Dec 1994 07:43:08 -0800 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 HAA29240; Sat, 31 Dec 1994 07:43:04 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA16868; Sat, 31 Dec 94 07:43:00 -0800 Received: from netcom.netcom.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id HAA20763; Sat, 31 Dec 1994 07:42:59 -0800 Received: by netcom.netcom.com (8.6.9/Netcom) id HAA08334; Sat, 31 Dec 1994 07:42:29 -0800 From: watsen@netcom.com (Kent Watsen) Message-Id: <199412311542.HAA08334@netcom.netcom.com> Subject: D/L-ing textures in draw space To: info-performer@sgi.sgi.com (performer) Date: Sat, 31 Dec 1994 07:42:28 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 909 Status: O Hello, I've just recently parallelized my DIS simulation application , it took less then a day, but I still have one nasty issue to address... In the unparallelized version, I would load all geometry from disk at load time. This geometry included the terrain and an instance of each moving model likely to be needed. Also at this time I would d/l the textures associated with the geometry into hardware texture memory. When parallelized, the above code is considered to be in the app process space, but the d/l-ing of textures must be in draw process space. I have considered several approaches to this, but they all seem kludgy (having to use a first-time static variable to indicate the need to do the work). I figure that there must be some support or, at least, a commonly accepted approach to do this work efficiently. Anybody? Kent Watsen DCS Corporation Simulation Branch 703.683.8430 x369 From guest Sat Dec 31 08:29:14 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA29255; Sat, 31 Dec 1994 08:01:27 -0800 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 IAA29252; Sat, 31 Dec 1994 08:01:22 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA16963; Sat, 31 Dec 94 08:01:18 -0800 Received: from netcom.netcom.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id IAA21260; Sat, 31 Dec 1994 08:01:17 -0800 Received: by netcom.netcom.com (8.6.9/Netcom) id IAA09635; Sat, 31 Dec 1994 08:00:47 -0800 From: watsen@netcom.com (Kent Watsen) Message-Id: <199412311600.IAA09635@netcom.netcom.com> Subject: State changes for post-draw GL callbacks To: info-performer@sgi.sgi.com (performer) Date: Sat, 31 Dec 1994 08:00:46 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1127 Status: O Hello, My applications often require 2-D symbology to be overlayed on top of a simulation channel. The 2-D symbology could be a VAPS or a DWB object, but when its trivial in nature I like to use home-brewed GL code. A typical GL overlay call would assume an orthogonal view in a unit channel between -1 and 1. Since Performer is a 3-D application, I must performer the transformations myself. An example of this follows: (please excude psuedocode as I have neither manual not code with me :) postdraw () { pfPushState(); pfBasicState(); something to overwrite pizels in z-buffer ortho2(-1.0, 1.0, -1.0, 1.0); pushmatrix(); create a 4x4 identity matrix loadmatrix(); update_overlay ( overlay_data ); popmatrix(); reset z-buffer pfPopState(); } This code works just fine, but I wonder if the state and matrix changes are seriously affecting frame-rate in the most time-critical section of the rendering loop. It should be noted that this procedure if sometimes repeated (up to four times) for each channel, with up to six channels, 20 times a second. Kent Watsen DCS Corporation Simulation Lab 703.683.8430 x369 From guest Sat Dec 31 08:59:16 1994 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA29319; Sat, 31 Dec 1994 08:30:29 -0800 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 IAA29316; Sat, 31 Dec 1994 08:30:23 -0800 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for info-performer@holodeck.asd.sgi.com id AA17219; Sat, 31 Dec 94 08:30:19 -0800 Received: from netcom.netcom.com by sgi.sgi.com via ESMTP (941129.SGI.8.6.9/910110.SGI) for id IAA22027; Sat, 31 Dec 1994 08:30:17 -0800 Received: by netcom.netcom.com (8.6.9/Netcom) id IAA11359; Sat, 31 Dec 1994 08:29:47 -0800 From: watsen@netcom.com (Kent Watsen) Message-Id: <199412311629.IAA11359@netcom.netcom.com> Subject: Determining vector direction thru channel To: info-performer@sgi.sgi.com (performer) Date: Sat, 31 Dec 1994 08:29:47 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1622 Status: O Hello, I sometimes have the need to calculate the direction of a vector through any pixel on the screen. The target pixel may be identified via mouse or touchscreen input. The direction of the vector is to be used to perform intersection tests in the otw scene graph. Given : There may be multiple channels per viewport All channels assumed to be unit normal -1 to 1 The left, right, bottom, and top of each channel The horizontal and vertical fov (usually the same) The hpr of each channel Assume : Z up, Y forward, X right First, assume a target pixel is found. That pixel can be tested against the boundaries of each channel and the channel it in in determined. Furthermore, the pixel's reletive position within the unit noraml channel can be calculated as dx, dy. (-1.0 <= dx,dy <= 1.0). Using the euler angle matrix (321 direction cosine matrix with hpr) transform X, Y, Z to X^, Y^, Z^. Note that Y^ is the direction of the vector in world coordinates for the pixel in the center of a channel. But our pixel my not at the center of the channel. However, we do know how far away it is (dx,dy) and we know the width, height, horizontal fov, and vertical fov. Therefore, one can calculate the horizontal and vertical delta angle for dx and dy (DangleX, DangleY). The final vector R = Y^ + X^*DangleX + Z^*DangleY This should work (as it did for the raytracer I wrote for my thesis), but I made the assumption that there was a linear mapping between pixels and delta-angles. Is this true for Performer? Kent Watsen DCS Corporation Simulation Branch 703.683.8430 x369