From guest Sun Mar 31 21:14:16 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id VAA23733; Sun, 31 Mar 1996 21:12:35 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id VAA23730; Sun, 31 Mar 1996 21:12:34 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18574; Sun, 31 Mar 96 21:12:29 -0800 Received: from nypinet.nyp.ac.sg by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id VAA04282; Sun, 31 Mar 1996 21:10:58 -0800 Received: from mgate.nyp.ac.sg. (mgate.nyp.ac.sg [202.12.95.26]) by nypinet.nyp.ac.sg (8.7.1/8.7.1) with SMTP id NAA08049; Mon, 1 Apr 1996 13:08:05 +0700 (SST) Received: by mgate.nyp.ac.sg. with Microsoft Mail id <316045AB@mgate.nyp.ac.sg.>; Mon, 01 Apr 96 13:07:55 PST From: "Ng Kian Bee, SIT/CS" To: Angus , performer , OpenGL Subject: Question. Pls Need help. Date: Mon, 01 Apr 96 13:01:00 PST Message-Id: <316045AB@mgate.nyp.ac.sg.> Encoding: 25 TEXT X-Mailer: Microsoft Mail V3.0 Status: O Hi, I dunno if these are the right questions to ask over here. If yes, pls help, if no, appreciate if someone could direct me to the right place. 1. I'm trying to implement a pin-ball game using OpenGL. The trouble is OpenGL doesnt seem to be able to recognise 2 simultaneous keyboard input. I've 2 keys representing the 2 levels of the pin-ball machine. When I've one key input, I cannot have another key input. So, I cant simulate two levels being pressed together. Anyone knows how to do it? Or is there similar codes out in the net? Please help! 2. Last time I used to use the public doman of VOGL where I've the function of getmatrix(). But in OpenGL, there doesnt seem to have such function. Could someone help me how to implement a getmatrix() function in OpenGL? What I want to do is to get the current matrix from the Model/View matrix stack, and multiply it with my own matrix. Anyone? Thanx!!! Rgds. Kian ngkb@nyp.ac.sg From guest Mon Apr 1 00:34:23 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id AAA24156; Mon, 1 Apr 1996 00:31:42 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA24153; Mon, 1 Apr 1996 00:31:41 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22119; Mon, 1 Apr 96 00:31:37 -0800 Received: from mandator.se by deliverator.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id AAA07390; Mon, 1 Apr 1996 00:31:20 -0800 Received: by mandator.se (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA6726; Mon, 01 Apr 96 09:25:49 -0500 Message-Id: <9604011425.AA6726@mandator.se> Received: from Mandator with "Lotus Notes Mail Gateway for SMTP" id 607DE1A747906B3E802562FF0033DDD2; Mon, 1 Apr 96 09:25:43 To: performer From: Ulf Yngwe/COMATOR/HELSINGBORG/SE/MANDATOR AB Date: 1 Apr 96 10:30:34 Subject: Re: Unable to load DSO for .3ds file Mime-Version: 1.0 Content-Type: Text/Plain Status: O Maybe you have set the setuid-bit on your file, then the runtime-linker won't use the LD_LIBRARY_PATH environement variable. If that is the case link your program with "-rpath /usr/lib/libpfdb". From guest Mon Apr 1 00:32:09 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id AAA24148; Mon, 1 Apr 1996 00:29:03 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA24145; Mon, 1 Apr 1996 00:28:59 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21971; Mon, 1 Apr 96 00:28:50 -0800 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id AAA10679; Mon, 1 Apr 1996 00:28:48 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA10494; Mon, 1 Apr 1996 09:25:39 +0100 From: "Angus Dorbie" Message-Id: <9604010925.ZM10491@bitch.reading.sgi.com> Date: Mon, 1 Apr 1996 09:25:38 +0100 In-Reply-To: "Ng Kian Bee, SIT/CS" "Question. Pls Need help." (Apr 1, 1:01pm) References: <316045AB@mgate.nyp.ac.sg.> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Ng Kian Bee, SIT/CS" , performer , OpenGL Subject: Re: Question. Pls Need help. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O You don't say how you are getting your input. Rather than polling the keys try and read press & release events if this is supported via whatever API youre using for your input, use this to keep your own track of the key status. Rgds, Angus. On Apr 1, 1:01pm, Ng Kian Bee, SIT/CS wrote: > Subject: Question. Pls Need help. > > Hi, > I dunno if these are the right questions to ask over here. If yes, pls help, > if no, appreciate if someone could direct me to the right place. > > 1. I'm trying to implement a pin-ball game using OpenGL. The trouble is > OpenGL doesnt seem to be able to recognise 2 simultaneous keyboard > input. I've 2 keys representing the 2 levels of the pin-ball machine. When > I've one key input, I cannot have another key input. So, I cant simulate > two levels being pressed together. Anyone knows how to do it? Or > is there similar codes out in the net? > Please help! > > 2. Last time I used to use the public doman of VOGL where I've > the function of getmatrix(). But in OpenGL, there doesnt > seem to have such function. Could someone help me how to implement > a getmatrix() function in OpenGL? What I want to do is to get the current > matrix from the Model/View matrix stack, and multiply it with my own > matrix. Anyone? > > Thanx!!! > > Rgds. > Kian > ngkb@nyp.ac.sg >-- End of excerpt from Ng Kian Bee, SIT/CS -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Mon Apr 1 02:23:48 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA24651; Mon, 1 Apr 1996 01:47:46 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA24648; Mon, 1 Apr 1996 01:47:38 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24660; Mon, 1 Apr 96 01:47:19 -0800 Received: from barney.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id BAA12854; Mon, 1 Apr 1996 01:47:12 -0800 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id KAA15904; Mon, 1 Apr 1996 10:47:07 +0100 From: "Rob Jenkins" Message-Id: <9604011047.ZM15902@barney.reading.sgi.com> Date: Mon, 1 Apr 1996 10:47:06 +0100 In-Reply-To: "Ng Kian Bee, SIT/CS" "Question. Pls Need help." (Apr 1, 1:01pm) References: <316045AB@mgate.nyp.ac.sg.> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Ng Kian Bee, SIT/CS" , OpenGL , performer Subject: Re: Question. Pls Need help. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 1, 1:01pm, Ng Kian Bee, SIT/CS wrote: > Subject: Question. Pls Need help. > > Hi, > I dunno if these are the right questions to ask over here. If yes, pls help, > if no, appreciate if someone could direct me to the right place. > a good place for straight OpenGL questions is comp.graphics.api.opengl > 2. Last time I used to use the public doman of VOGL where I've > the function of getmatrix(). But in OpenGL, there doesnt > seem to have such function. Could someone help me how to implement > a getmatrix() function in OpenGL? What I want to do is to get the current > matrix from the Model/View matrix stack, and multiply it with my own > matrix. Anyone? > checkout man on glget, use GL_MODELVIEW_MATRIX/GL_PROJECTION_MATRIX tokens Cheers Rob > Thanx!!! > > Rgds. > Kian > ngkb@nyp.ac.sg >-- End of excerpt from Ng Kian Bee, SIT/CS -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. Forum 1, Station Road, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Mon Apr 1 03:42:57 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id DAA24811; Mon, 1 Apr 1996 03:06:58 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id DAA24808; Mon, 1 Apr 1996 03:06:54 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA25772; Mon, 1 Apr 96 03:06:49 -0800 Received: from barney.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id DAA14936; Mon, 1 Apr 1996 03:06:38 -0800 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id MAA16070; Mon, 1 Apr 1996 12:06:23 +0100 From: "Rob Jenkins" Message-Id: <9604011206.ZM16068@barney.reading.sgi.com> Date: Mon, 1 Apr 1996 12:06:23 +0100 In-Reply-To: cheng@satchmo.virtualprototypes.ca (Thomas Cheng) "smoke trail" (Mar 29, 4:40pm) References: <9603292140.AA18752@satchmo.virtualprototypes.ca> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: cheng@satchmo.virtualprototypes.ca (Thomas Cheng), info-performer@sgi.sgi.com Subject: Re: smoke trail Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O have a look at the libpfutil smoke functions with pfuSmokeType PFUSMOKE_MISSILE, try man pfuSmoke - source is in the libpfutil dir. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. Forum 1, Station Road, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Mon Apr 1 07:27:44 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA25282; Mon, 1 Apr 1996 07:25:53 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA25279; Mon, 1 Apr 1996 07:25:51 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03889; Mon, 1 Apr 96 07:25:42 -0800 Received: from inesc.inesc.pt by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA25387; Mon, 1 Apr 1996 07:23:54 -0800 Received: from minerva.inesc.pt (minerva-2.inesc.pt) by inesc.inesc.pt with SMTP; id AA03882 (/); Mon, 1 Apr 1996 16:22:11 +0200 Received: from minerva (localhost) by minerva.inesc.pt (4.1/Sun OS 4.1.1) id AA02541; Mon, 1 Apr 96 17:23:14 +0200 Sender: mgo@minerva.inesc.pt Message-Id: <315FF4E2.41C67EA6@minerva.inesc.pt> Date: Mon, 01 Apr 1996 17:23:14 +0200 From: Nuno Godinho X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Rob Jenkins Cc: Veraart , performer Subject: Re: Unable to load DSO for .3ds file References: <199603291442.PAA14522@s00sn1.fel.tno.nl> <9603291654.ZM8138@barney.reading.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Rob Jenkins wrote: > > If you have Performer 2.0 installed ( as you should on Impact ) then in > /usr/lib/libpfdb you should have: > > libpf3ds.so libpf3ds_igl.so.2 libpf3ds_ogl.so.2 > libpf3ds_igl.so libpf3ds_ogl.so > > if not then install from performer_eoe.sw. I beleive the 3ds loader is pf 2.0 > only. Hi. I have pf 2.0 and all the above files in the correct directory. Nevertheless I get the following output: mgo@eolo ~[19] = perfly cafetabl.3ds PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "3ds" PF Info: All 4 processors available on this machine. PF Warning/Usage: No hardware support for VSYNC, frame sync may vary.Assuming 60Hz. PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "3ds" PF Warning: pfdLoadFile() - Unable to load file cafetabl.3ds because of problem finding pfdLoadFile_3ds PF Notice: WARNING: could not load "cafetabl.3ds" How can this be explained? Nuno From guest Mon Apr 1 07:34:47 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA25291; Mon, 1 Apr 1996 07:32:46 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA25288; Mon, 1 Apr 1996 07:32:46 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04042; Mon, 1 Apr 96 07:32:45 -0800 Received: from ciup1.ncc.up.pt by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA26350; Mon, 1 Apr 1996 07:32:20 -0800 Received: from garf.fe.up.pt (garfield.fe.up.pt) by ciup1.ncc.up.pt with SMTP id AA26084 (5.65c/IDA-1.4.4 for ); Mon, 1 Apr 1996 17:30:54 +0200 Received: from onyx (onyx.fe.up.pt) by garf.fe.up.pt with SMTP id AA06406 (5.65c/IDA-1.4.4 for <@garfield:info-performer@sgi.sgi.com>); Mon, 1 Apr 1996 16:33:40 +0100 Received: by onyx (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.sgi.com id HAA21525; Mon, 1 Apr 1996 07:31:08 -0800 Date: Mon, 1 Apr 1996 07:31:08 -0800 From: asilva@onyx.fe.up.pt (Antonio Manuel Ferreira da Silva) Message-Id: <199604011531.HAA21525@onyx> To: info-performer@sgi.sgi.com Subject: Unsubscribe Status: O Unsubscribe please! asilva@onyx.fe.up.pt From guest Mon Apr 1 07:35:12 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA25296; Mon, 1 Apr 1996 07:33:09 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA25293; Mon, 1 Apr 1996 07:33:08 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04054; Mon, 1 Apr 96 07:33:08 -0800 Received: from ciup1.ncc.up.pt by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA25914; Mon, 1 Apr 1996 07:29:55 -0800 Received: from garf.fe.up.pt (garfield.fe.up.pt) by ciup1.ncc.up.pt with SMTP id AA26038 (5.65c/IDA-1.4.4 for ); Mon, 1 Apr 1996 17:29:25 +0200 Received: by garf.fe.up.pt id AA06367 (5.65c/IDA-1.4.4 for info-performer@sgi.sgi.com); Mon, 1 Apr 1996 16:32:09 +0100 Date: Mon, 1 Apr 1996 16:32:09 +0100 From: Antonio Manuel Ferreira da Silva Message-Id: <199604011532.AA06367@garf.fe.up.pt> To: info-performer@sgi.sgi.com Subject: Unsubscribe Status: O Unsubscribe please! asilva@garfield.fe.up.pt From guest Mon Apr 1 08:06:11 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA25455; Mon, 1 Apr 1996 08:04:24 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA25452; Mon, 1 Apr 1996 08:04:23 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04737; Mon, 1 Apr 96 08:04:22 -0800 Received: from inesc.inesc.pt by deliverator.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id IAA03755; Mon, 1 Apr 1996 08:04:11 -0800 Received: from minerva.inesc.pt (minerva-2.inesc.pt) by inesc.inesc.pt with SMTP; id AA07300 (/); Mon, 1 Apr 1996 17:02:28 +0200 Received: from minerva (localhost) by minerva.inesc.pt (4.1/Sun OS 4.1.1) id AA02760; Mon, 1 Apr 96 18:03:31 +0200 Sender: mgo@minerva.inesc.pt Message-Id: <315FFE52.167EB0E7@minerva.inesc.pt> Date: Mon, 01 Apr 1996 18:03:30 +0200 From: Nuno Godinho X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Ulf Yngwe/COMATOR/HELSINGBORG/SE/MANDATOR AB Cc: performer Subject: Re: Unable to load DSO for .3ds file References: <9604011425.AA6726@mandator.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Ulf Yngwe/COMATOR/HELSINGBORG/SE/MANDATOR AB wrote: > > Maybe you have set the setuid-bit on your file, then the runtime-linker won't > use the > LD_LIBRARY_PATH environement variable. If that is the case link your program > with > "-rpath /usr/lib/libpfdb". This would work if I couldn't load any of the file types! I seem to only have problems with 3dStudio format. thanks Nuno From guest Mon Apr 1 08:46:03 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA25706; Mon, 1 Apr 1996 08:44:10 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA25703; Mon, 1 Apr 1996 08:44:10 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06768; Mon, 1 Apr 96 08:44:09 -0800 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA02514; Mon, 1 Apr 1996 08:44:07 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA06764; Mon, 1 Apr 96 08:44:04 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id IAA17897; Mon, 1 Apr 1996 08:44:04 -0800 Date: Mon, 1 Apr 1996 08:44:04 -0800 From: mtj@babar (Michael Jones) Message-Id: <199604011644.IAA17897@babar.asd.sgi.com> To: info-performer@sgi.sgi.com, mgo@minerva.inesc.pt Subject: RE: continuing 3ds saga Status: O Nuno: Raise the notification level so that perfly/pfdLoadFile/Performer will print a detailed log of their actions: perfly -n5 cafetabl.3ds and let us all know what you see. Michael Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Mon Apr 1 08:53:07 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA25733; Mon, 1 Apr 1996 08:50:20 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA25730; Mon, 1 Apr 1996 08:50:19 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07011; Mon, 1 Apr 96 08:50:18 -0800 Received: from inesc.inesc.pt by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA02967; Mon, 1 Apr 1996 08:50:11 -0800 Received: from minerva.inesc.pt (minerva-2.inesc.pt) by inesc.inesc.pt with SMTP; id AA10494 (/); Mon, 1 Apr 1996 17:49:02 +0200 Received: from minerva (localhost) by minerva.inesc.pt (4.1/Sun OS 4.1.1) id AA03050; Mon, 1 Apr 96 18:50:05 +0200 Sender: mgo@minerva.inesc.pt Message-Id: <3160093C.2781E494@minerva.inesc.pt> Date: Mon, 01 Apr 1996 18:50:04 +0200 From: Nuno Godinho X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Michael Jones Cc: info-performer@sgi.sgi.com, mgo@minerva.inesc.pt Subject: Re: continuing 3ds saga References: <199604011644.IAA17897@babar.asd.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Raise the notification level so that perfly/pfdLoadFile/Performer will print > a detailed log of their actions: > > perfly -n5 cafetabl.3ds > > and let us all know what you see. Done it: mgo@eolo ~[135] = perfly -n5 cafetabl.3ds PF Debug: PF Debug: pfdFindConverterDSO() - DSO search path is: PF ".:" PF ":" PF ":" PF "/usr/lib/libpfdb:" PF "/usr/share/Performer/lib/libpfdb" PF Debug: pfdFindConverterDSO() - can't get version of libpfdu.so, using sgi2.0 PF Debug: pfdFindConverterDSO() - Did not find optimized DSO "libpf3ds_igl.so" PF Debug: pfdFindConverterDSO() - Did not find debug DSO "libpf3ds_igl-g.so" PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "3ds" PF Info: All 1 processors available on this machine. PF Warning/Usage: No hardware support for VSYNC, frame sync may vary.Assuming 60Hz. PF Debug/Resource: pfDataPool::create() - pid 7239 - 131072 bytes at 0x2808e000 succeeded for /usr/tmp/pfutil7239.pfdpool PF Debug: pfInitUtil(): pid 7239 created pfUtil data pool: pfutil7239 PF Debug: PF Debug: pfdFindConverterDSO() - DSO search path is: PF ".:" PF ":" PF ":" PF "/usr/lib/libpfdb:" PF "/usr/share/Performer/lib/libpfdb" PF Debug: pfdFindConverterDSO() - can't get version of libpfdu.so, using sgi2.0 PF Debug: pfdFindConverterDSO() - Did not find optimized DSO "libpf3ds_igl.so" PF Debug: pfdFindConverterDSO() - Did not find debug DSO "libpf3ds_igl-g.so" PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "3ds" PF Warning: pfdLoadFile() - Unable to load file cafetabl.3ds because of problem finding pfdLoadFile_3ds PF Notice: WARNING: could not load "cafetabl.3ds" Tell me what you think. Oh, I got a message from Angus saying that 3ds loader was not included in 2.0 release. What do you know about this? thanks in advance Nuno From guest Mon Apr 1 08:57:07 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA25771; Mon, 1 Apr 1996 08:55:06 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA25768; Mon, 1 Apr 1996 08:55:05 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07176; Mon, 1 Apr 96 08:55:04 -0800 Received: from dragon.ti.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id IAA03451; Mon, 1 Apr 1996 08:54:59 -0800 Received: from tilde.csc.ti.com ([128.247.160.56]) by dragon.ti.com (8.6.13/ac3i.dseg.ti.com) with ESMTP id KAA11417; Mon, 1 Apr 1996 10:55:33 -0600 Received: from rts.dseg.ti.com (m2.dseg.ti.com [128.247.216.212]) by tilde.csc.ti.com (8.7.5/8.7.3) with SMTP id KAA13042; Mon, 1 Apr 1996 10:54:23 -0600 (CST) Received: by rts.dseg.ti.com (4.1/SMI-4.1) id AA14995; Mon, 1 Apr 96 10:57:31 CST Date: Mon, 1 Apr 96 10:57:31 CST From: tpravata@rts.dseg.ti.com (Todd R Pravata) Message-Id: <9604011657.AA14995@rts.dseg.ti.com> To: info-performer@sgi.sgi.com Cc: mtj@babar, matomira@lig.di.epfl.ch In-Reply-To: <199603181917.LAA29945@babar.asd.sgi.com> (mtj@babar.asd.sgi.com) Subject: 2.0.1 on IRIX 5.3 Reply-To: Status: O Does anyone know if this list bug fixes for 2.0.1 went out? If not, will someone publish this? Thanks > What we can do is to send out the complete list of "what's > fixed in 2.0.1" from the release notes here on the mailing > list and let you judge for yourself how urgent the upgrade > to 6.2 is for you. If it's urgent, a call to SGI's Global > Customer Satisfaction group should be sufficient to expedite > your 6.2 upgrade mailing. > > Contact Allan Schaffer for this type of information. > > Michael Jones > > Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 > Michael T. Jones Silicon Graphics, Advanced Systems Division > mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 -- Todd Pravata todd.pravata@ti.com 214-575-6126 Visual Simulation Lab, Texas Instruments "The significant problems that we face cannot be solved at the same level of thinking we were at when we created them." -- Albert Einstein ** Views expressed are not necessarily those of Texas Instruments ** From guest Mon Apr 1 09:20:01 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA26844; Mon, 1 Apr 1996 09:18:05 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA26841; Mon, 1 Apr 1996 09:18:05 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08669; Mon, 1 Apr 96 09:18:03 -0800 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA05830; Mon, 1 Apr 1996 09:18:02 -0800 Received: from hell.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA08653; Mon, 1 Apr 96 09:17:55 -0800 Received: by hell.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id JAA18544; Mon, 1 Apr 1996 09:17:54 -0800 From: "Don Hatch" Message-Id: <9604010917.ZM18542@hell.asd.sgi.com> Date: Mon, 1 Apr 1996 09:17:53 -0800 In-Reply-To: mtj@babar (Michael Jones) "RE: continuing 3ds saga" (Apr 1, 8:44am) References: <199604011644.IAA17897@babar.asd.sgi.com> X-Face: /7QDEc=iPrsQG=j>iQo4F||T'ys-t--1bb9IJ9qo~4|i0nB|OG%gK}I3J2{/u*-q.I8=OSv/&K}V(pw:~5aIV!Y4:y+Vk#AAX)|i'B-jHf+r(?U'"B'9"D|<-(/1PD32tUN X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.sgi.com, mgo@minerva.inesc.pt Subject: Re: continuing 3ds saga Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 1, 8:44am, Michael Jones wrote: > Subject: RE: continuing 3ds saga > Nuno: > > Raise the notification level so that perfly/pfdLoadFile/Performer will print > a detailed log of their actions: > > perfly -n5 cafetabl.3ds > > and let us all know what you see. Also do this: setenv PFLD_LIBRARY_PATH . (as described in a dark corner in the pfdLoadFile man page) to see all the error messages from the run-time linker. Usually when this happens with the 3ds loader it means you are missing libcil.so (install it from the inst subsystem called "il_eoe.sw.c"). Don -- Don Hatch hatch@sgi.com (415) 933-5150 Silicon Graphics, Inc. From guest Mon Apr 1 09:11:01 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA25943; Mon, 1 Apr 1996 09:08:49 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA25940; Mon, 1 Apr 1996 09:08:49 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07988; Mon, 1 Apr 96 09:08:47 -0800 Received: from bhole.cae.ca by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id JAA09617; Mon, 1 Apr 1996 09:08:46 -0800 Received: from poster.cae.ca (poster.cae.ca [142.39.22.1]) by bhole with SMTP (DuhMail/2.0) id MAA08070; Mon, 1 Apr 1996 12:05:49 -0500 Received: from zola.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA10799; Mon, 1 Apr 1996 12:03:24 -0500 Received: from localhost by zola.cae.ca via SMTP (940816.SGI.8.6.9/930416.SGI) for id MAA07947; Mon, 1 Apr 1996 12:06:14 -0500 Message-Id: <199604011706.MAA07947@zola.cae.ca> To: info-performer@sgi.com Subject: Inventor loader, directional and spot lights Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 01 Apr 1996 12:06:12 -0500 From: "Pierre P. Tremblay" Status: O Hello Performers, I am trying to find a quick way of creating a Performer 2.0 database to demonstrate aircraft landing lights with projected textures, as described in chapter 8 of the "IRIS Performer Programmer's Guide". I have tried to use an Inventor ASCII database to do this, using the Inventor SpotLight construct. Unfortunately, with the environment variable PFNFYLEVEL=5, I get the following message from the Inventor loader: PF Debug/Resource: PF Debug/Resource: pfLoad_iv() SoLight conversion not enabled. Call PF Debug/Resource: pfLoad_ivMode(PFIV_CONVERT_LIGHTS, 1) to enable PF Debug/Resource: SoLight conversion. PF Debug/Resource: !!!WARNING: Converted lights will have GLOBAL sco pe!!! As could be expected, the result is that the spotlight is not loaded and does not appear in the database tree structure that can be displayed under perfly. A grep of the Inventor loader source files for pfLoad_ivMode was unsuccessful --- no definition of the function can be found. I therefore have a few questions: 1) Is the ASCII Inventor format an appropriate way of testing out landing lights? In particular, will it use projected textures? If so, what does the texture it is going to project look like? Some kind of circularly-symmetric lobe? 2) If an ASCII-format Inventor file is an appropriate route, where can I find the source to the pfLoad_ivMode() function? 3) What is an easy way to tie a landing light to the own-ship? I am prepared to augment an existing loader / roll my own if required. Thanks for any help, Pierre -- Pierre P. Tremblay ppt@cae.ca From guest Mon Apr 1 10:16:14 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA27461; Mon, 1 Apr 1996 10:14:23 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA27458; Mon, 1 Apr 1996 10:14:22 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12793; Mon, 1 Apr 96 10:14:21 -0800 Received: from physics.ucla.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA13034; Mon, 1 Apr 1996 10:14:14 -0800 Received: from scotch.physics.ucla.edu by physics.ucla.edu (5.x/SMI-SVR4) id AA12161; Mon, 1 Apr 1996 10:17:20 -0800 Received: by scotch.physics.ucla.edu (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.sgi.com id KAA27955; Mon, 1 Apr 1996 10:03:13 -0800 Date: Mon, 1 Apr 1996 10:03:13 -0800 From: chris@scotch.physics.ucla.edu (chris) Message-Id: <199604011803.KAA27955@scotch.physics.ucla.edu> To: info-performer@sgi.sgi.com Subject: Subscribe Status: O Resubscribe, please. //////////////////////////////////////////////////// //Chris Mitchell -- // //Institute of Plasma and Fusion Research (IPFR) // //UCLA Physics Department 310-206-1772 // //chris@scotch.physics.ucla.edu // //mitchell@physics.ucla.edu // //chrism@ucla.edu // // // //"Self Reliance, the height and perfection of // // man, is reliance on God." // // --Ralph Waldo Emmerson // //////////////////////////////////////////////////// From guest Mon Apr 1 10:27:36 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA27499; Mon, 1 Apr 1996 10:25:32 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA27496; Mon, 1 Apr 1996 10:25:32 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13503; Mon, 1 Apr 96 10:25:30 -0800 Received: from nirvana.neu.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA14527; Mon, 1 Apr 1996 10:25:27 -0800 Received: by nirvana.neu.sgi.com (940816.SGI.8.6.9/911001.SGI) id UAA20231; Mon, 1 Apr 1996 20:25:24 +0200 From: "Simon Hayhurst" Message-Id: <9604012025.ZM20229@nirvana.neu.sgi.com> Date: Mon, 1 Apr 1996 20:25:23 -0600 In-Reply-To: "Pierre P. Tremblay" "Inventor loader, directional and spot lights" (Apr 1, 12:06pm) References: <199604011706.MAA07947@zola.cae.ca> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Pierre P. Tremblay" , info-performer@sgi.sgi.com Subject: Re: Inventor loader, directional and spot lights Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Pierre, You can get the source to the Inventor loader from sgigate.sgi.com, by anonymous ftp. pfiv_src1.6.tar.Z at /pub/Performer/src/pf1.2 If you look in the file pfiv16/src/lib/libpfiv/pfiv.C at lines around 1100 you'll see the part of the code that deals with SoLights, so this is a problem you can fix. It hasn't yet been tackled by anyone here at SGI ... sorry. >From the source, you may want to speak to :- jrohlf@sgi.com who has put his name to this section. I don't guarantee that he has the time to do anything, but he may be able to save you some time. Hope this helps. Simon -- -------------------------------------------------------------------------------- Simon Hayhurst Phone (41)-38-433733 Supercomputing Technology Centre Fax (41)-38-433905 Core Technology Group Voice Mail 5-7269 SGI, Cortaillod, Switzerland Internet simon @ neu.sgi.com -------------------------------------------------------------------------------- From guest Mon Apr 1 11:03:53 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA27764; Mon, 1 Apr 1996 11:01:53 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA27761; Mon, 1 Apr 1996 11:01:52 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16307; Mon, 1 Apr 96 11:01:51 -0800 Received: from alcor.unm.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA18841; Mon, 1 Apr 1996 11:01:50 -0800 Received: from venus.unm.edu by alcor.unm.edu with smtp (Smail3.1.29.1 #24) id m0u3orM-00009zC; Mon, 1 Apr 96 12:01 MST Date: Mon, 1 Apr 1996 12:01:47 -0700 (MST) From: Maria Gallegos To: info-performer@sgi.sgi.com Subject: unsuscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Please take me off of the list thank you, maria From guest Mon Apr 1 11:54:01 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA27988; Mon, 1 Apr 1996 11:52:10 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA27985; Mon, 1 Apr 1996 11:52:09 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19644; Mon, 1 Apr 96 11:52:08 -0800 Received: from trifid.cleveland.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA25106; Mon, 1 Apr 1996 11:52:06 -0800 Received: by trifid.cleveland.sgi.com (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.sgi.com id OAA04571; Mon, 1 Apr 1996 14:53:48 -0500 From: "Mark J. Collins" Message-Id: <9604011453.ZM4569@trifid.cleveland.sgi.com> Date: Mon, 1 Apr 1996 14:53:48 -0500 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Please unsubscribe me. Thanks. Mark Collins From guest Mon Apr 1 12:22:28 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA28233; Mon, 1 Apr 1996 12:20:06 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA28228; Mon, 1 Apr 1996 12:20:06 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21837; Mon, 1 Apr 96 12:20:04 -0800 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA28385; Mon, 1 Apr 1996 12:20:02 -0800 Received: from osprey.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA14832; Mon, 1 Apr 1996 15:13:07 -0500 Received: by osprey.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id PAA01484; Mon, 1 Apr 1996 15:15:55 -0500 Date: Mon, 1 Apr 1996 15:15:55 -0500 From: nicolas@cae.ca (Nicolas Gauvin) Message-Id: <199604012015.PAA01484@osprey.cae.ca> To: info-performer@sgi.sgi.com Subject: Tired of unsubscribe/subscribe request? Status: O I am the only one tired of those never ending subscribe/unsubscribe requests on the mailing list? How about this idea: An automatic message (via a cron) could be send to the mailing list on a weekly basis. It would be titled: How to subscribe/unsubscribe and would contain the info-performer-request@sgi.com adress that many people seem to forget ;) I think this could decrease the amount of traffic. ___/ | ___/ Nicolas Gauvin e-mail: nicolas@cae.ca / / | / Software Developper voice: (514) 341-2000 x2275 / / | __/ CAE Electronics Ltd. fax: (514) 340-5496 / ___ | / 8585 Cote De Liesse, P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Mon Apr 1 12:40:13 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA28332; Mon, 1 Apr 1996 12:38:15 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA28329; Mon, 1 Apr 1996 12:38:14 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22836; Mon, 1 Apr 96 12:38:13 -0800 Received: from mail.ucsd.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA00501; Mon, 1 Apr 1996 12:38:11 -0800 From: sbrown@nestor.UCSD.EDU Received: from nestor by mail.ucsd.edu; id MAA15773 sendmail 8.6.12/UCSD-2.2-sun via ESMTP Mon, 1 Apr 1996 12:38:09 -0800 for <@mail.ucsd.edu:info-performer@sgi.sgi.com> Received: by nestor (951211.SGI.8.6.12.PATCH1042/) for info-performer@sgi.sgi.com id MAA15471; Mon, 1 Apr 1996 12:34:55 -0800 Message-Id: <9604011234.ZM15469@nestor.ucsd.edu> Date: Mon, 1 Apr 1996 12:34:51 -0800 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Tired of unsubscribe/subscribe request? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O The mail volume is very high on this group. How about another level of service? One that would present a weekly digest, perhaps just containing subject and author of each message. The messages themselves could then be accesable at a web site. -- Sheldon Brown Assistant Professor Visual Arts Dept. University of California at San Diego 9500 Gilman Drive La Jolla, CA 92093 voice/fax (619) 534-2423 sgbrown@ucsd.edu http://grasshopper.ucsd.edu/95_96/FACULTY/sheldon.html From guest Mon Apr 1 12:47:05 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA28423; Mon, 1 Apr 1996 12:45:16 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA28420; Mon, 1 Apr 1996 12:45:15 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23212; Mon, 1 Apr 96 12:45:14 -0800 Received: from huey.ntsc.navy.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA01211; Mon, 1 Apr 1996 12:44:59 -0800 From: william_marinelli@ntsc.navy.mil Received: from CCMAIL.NTSC.NAVY.MIL ([192.44.253.30]) by huey.ntsc.navy.mil (4.1/SMI-4.1) id AA02953; Mon, 1 Apr 96 15:36:11 EST Received: from ccMail by CCMAIL.NTSC.NAVY.MIL (SMTPLINK V2.11) id AA828402191; Mon, 01 Apr 96 15:40:41 EST Date: Mon, 01 Apr 96 15:40:41 EST Message-Id: <9603018284.AA828402191@CCMAIL.NTSC.NAVY.MIL> To: info-performer@sgi.sgi.com, nicolas@cae.ca (Nicolas Gauvin) Subject: Re: Tired of unsubscribe/subscribe request? Status: O Nicolas wrote: >I am the only one tired of those never ending >subscribe/unsubscribe requests on the mailing list? No >How about this idea: >An automatic message (via a cron) could be send >to the mailing list on a weekly basis. >It would be titled: How to subscribe/unsubscribe >and would contain the info-performer-request@sgi.com >adress that many people seem to forget ;) Good idea. >I think this could decrease the amount of traffic. I disagree with an inderlying assumption that caused you to make this claim. From guest Mon Apr 1 13:43:22 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA28821; Mon, 1 Apr 1996 13:41:34 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA28818; Mon, 1 Apr 1996 13:41:34 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26616; Mon, 1 Apr 96 13:41:32 -0800 Received: from ptolemy.arc.nasa.gov by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA07298; Mon, 1 Apr 1996 13:41:30 -0800 Received: by ptolemy.arc.nasa.gov (4.1/) id for info-performer@sgi.sgi.com; Mon, 1 Apr 96 13:41:14 PST Date: Mon, 1 Apr 1996 13:41:13 -0800 (PST) From: Ken Lindsay To: sbrown@nestor.UCSD.EDU Cc: info-performer@sgi.sgi.com Subject: Re: Tired of unsubscribe/subscribe request? In-Reply-To: <9604011234.ZM15469@nestor.ucsd.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O bravo sheldon! in fact that is exactly what the java people did at sun a couple of months ago. they too had a list with hundreds of messages per week. now they send out a summary instead. a better solution to the subscribe/unsubscribe errors would be for the system person(s) on this list to add a filter which automatically re-routes any message with either key word in the subject or body of the message. ken On Mon, 1 Apr 1996 sbrown@nestor.UCSD.EDU wrote: > > The mail volume is very high on this group. > > How about another level of service? One that would present a weekly digest, > perhaps just containing subject and author of each message. The messages > themselves could then be accesable at a web site. > > -- > Sheldon Brown > Assistant Professor > Visual Arts Dept. > University of California at San Diego > 9500 Gilman Drive > La Jolla, CA 92093 > voice/fax (619) 534-2423 > > sgbrown@ucsd.edu > http://grasshopper.ucsd.edu/95_96/FACULTY/sheldon.html > > -==- ken "fire a few neurons" lindsay kl@ptolemy.arc.nasa.gov neuro-graphics programmer Neuro-Engineering Team (NET) NASA Ames Research Center Caelum Research Corp. Mail Stop 269-1 (415) 604 3594 (fax) Moffett Field, CA 94035-1000 (415) 604 3181 (vox) OVERNIGHT DELIVERIES --> USE "BUILDING 269, ROOM 281" AND INCLUDE MY NAME, PHONE NUMBER, P.O. NUMBER, AND OTHER PERTINENT TRACKING INFO From guest Mon Apr 1 13:58:45 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA28922; Mon, 1 Apr 1996 13:57:03 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA28919; Mon, 1 Apr 1996 13:57:03 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27736; Mon, 1 Apr 96 13:57:01 -0800 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA09449; Mon, 1 Apr 1996 13:56:59 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id WAA01687; Mon, 1 Apr 1996 22:53:38 +0100 From: "Angus Dorbie" Message-Id: <9604012253.ZM1685@bitch.reading.sgi.com> Date: Mon, 1 Apr 1996 22:53:38 +0100 In-Reply-To: sbrown@nestor.ucsd.edu "Re: Tired of unsubscribe/subscribe request?" (Apr 1, 12:34pm) References: <9604011234.ZM15469@nestor.ucsd.edu> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: sbrown@nestor.ucsd.edu, info-performer@sgi.sgi.com Subject: Re: Tired of unsubscribe/subscribe request? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O No pain, no gain. On Apr 1, 12:34pm, sbrown@nestor.ucsd.edu wrote: > Subject: Re: Tired of unsubscribe/subscribe request? > > The mail volume is very high on this group. > > How about another level of service? One that would present a weekly digest, > perhaps just containing subject and author of each message. The messages > themselves could then be accesable at a web site. > >-- End of excerpt from sbrown@nestor.ucsd.edu From guest Mon Apr 1 14:17:21 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA29080; Mon, 1 Apr 1996 14:15:38 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA29077; Mon, 1 Apr 1996 14:15:36 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29037; Mon, 1 Apr 96 14:15:35 -0800 Received: from firewall.cgsd.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA11815; Mon, 1 Apr 1996 14:15:32 -0800 Received: from [192.9.200.107] ([192.9.200.107]) by firewall.cgsd.com (8.6.12/8.6.12) with SMTP id OAA14806; Mon, 1 Apr 1996 14:16:20 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 1 Apr 1996 14:15:23 -0800 To: william_marinelli@ntsc.navy.mil, info-performer@sgi.sgi.com, nicolas@cae.ca (Nicolas Gauvin) From: mckenna@cgsd.com (Gene McKenna) Subject: Re: Tired of unsubscribe/subscribe request? Status: O >>An automatic message (via a cron) could be send >>to the mailing list on a weekly basis. >>It would be titled: How to subscribe/unsubscribe >>and would contain the info-performer-request@sgi.com >>adress that many people seem to forget ;) > > Good idea. > A better idea - since no one wants to remember two addresses make the list server (info-performer) filter out unsubscribe and subscribe requests and eliminate the need for a separate request address and the automail reminder. We have computers to make things easier, remember GENE +-----------------------------------------------------+ | Gene McKenna | | mckenna@cgsd.com CGSD Corporation | | voice 415.903.4928 Software Engineer | | fax 415.967.5252 Webmaster www.cgsd.com | +-----------------------------------------------------+ From guest Mon Apr 1 14:33:58 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA29248; Mon, 1 Apr 1996 14:31:34 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA29245; Mon, 1 Apr 1996 14:31:34 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00356; Mon, 1 Apr 96 14:31:32 -0800 Received: from mred.bgm.link.com by deliverator.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id OAA15796; Mon, 1 Apr 1996 14:31:30 -0800 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA07226; Mon, 1 Apr 96 16:30:24 -0600 Date: Mon, 1 Apr 96 16:30:24 -0600 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9604012230.AA07226@mred.bgm.link.com> To: info-performer@sgi.com Subject: High volume of mail on info-performer Status: O I agree that the volume of mail is too high on info-performer, but I disagree over both the cause, and the fix. I think that what is needed is to have the following sequence of events:- 1) Person A mails a question/problem. 2) Persons B->Z should mail their responses *directly* to A and *not* to info-performer. 3) When person A has a good fix for his/her problem, they write a summary of the best answers (ie the ones that worked) and post that to info-performer so that everyone gets the benefit of the answers without reading 20 copies of variations on the same answer and 20 more incorrect suggestions. This requires a little discipline and some consideration to others in the group - but no change in the way the group operates. Since the ratio of questions to answers is something like 1:5, we could reduce our mail flow by 80% at a stroke. The problem with a weekly digest is that if I ask a question, it could take a week for my question to make it into the digest, and another week for the reply to make the NEXT digest - maybe two weeks to get a reply - instead of a few hours as it does now. Also, I still need to read through exactly the same number of lines of email as I would with the present scheme. As for the large numbers of 'subscribe/unsubscribe' messages, I can skip over them without reading them - I don't find them too intrusive (although it would be more polite for people to send them to the correct mailing address)> Steve Steve Baker 817-323-1361 (Vox-Lab) Hughes Training Inc. 817-695-8776 (Vox-Office/vMail) 2200 Arlington Downs Road 817-695-4028 (Fax) Arlington, Texas. TX 76005-6171 steve@mred.bgm.link.com (eMail) From guest Mon Apr 1 15:19:46 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA29588; Mon, 1 Apr 1996 15:17:53 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA29585; Mon, 1 Apr 1996 15:17:53 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03375; Mon, 1 Apr 96 15:17:51 -0800 Received: from cordoba.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA21399; Mon, 1 Apr 1996 15:17:48 -0800 Received: by cordoba.reading.sgi.com (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id AAA16748; Tue, 2 Apr 1996 00:17:46 +0100 From: "Greg Edwards, SGI UK." Message-Id: <9604020017.ZM16746@cordoba.reading.sgi.com> Date: Tue, 2 Apr 1996 00:17:46 +0100 Reply-To: gedwards@reading.sgi.com X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Noise traffic on info-performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hey folks, Keep in mind this is a very unusual email alias. You have full access to the whole Performer engineering team, including Director- level people like Mike Jones. It's maintained by Alan Schaffer who has a zillion other things to do. It can't last forever, but you can make it last longer by keeping noise levels low. I'm sure Alan will streamline the alias if he has time. But you can help by keeping traffic to concise technical discussion. I'm sure the Pf team will rapidly disconnect from this alias if they have to wade through reams of flames and chit chat, well-meaning as they might be. Rgds, -- __________________________________________________________________________ Greg Edwards, Graphics Support/Consulting Group, Silicon Graphics UK Ltd. Forum 1, Theale, Reading, UK, RG7 4RA. tel +44 1734 257500, direct +44 1734 257740, fax +44 1734 257553 gedwards@reading.sgi.com, US vmail 59130, UK vmail 7740#, mailstop IUK-311 From guest Mon Apr 1 15:55:27 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA29834; Mon, 1 Apr 1996 15:53:41 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA29831; Mon, 1 Apr 1996 15:53:40 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05458; Mon, 1 Apr 96 15:53:39 -0800 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA26511; Mon, 1 Apr 1996 15:53:37 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA05454; Mon, 1 Apr 96 15:53:36 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id PAA19039; Mon, 1 Apr 1996 15:53:35 -0800 From: "Michael Jones" Message-Id: <9604011553.ZM19037@babar.asd.sgi.com> Date: Mon, 1 Apr 1996 15:53:34 -0800 In-Reply-To: "Greg Edwards, SGI UK." "Noise traffic on info-performer" (Apr 2, 12:17am) References: <9604020017.ZM16746@cordoba.reading.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: gedwards@reading.sgi.com, info-performer@sgi.sgi.com Subject: Re: Noise traffic on info-performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 2, 12:17am, Greg Edwards, SGI UK. wrote: > Subject: Noise traffic on info-performer :It's maintained by Alan Schaffer who :has a zillion other things to do. Actually, that's the issue recently -- he's on vacation (at a wedding in India) and unavailable to handle unsubscribe requests. :But you can help :by keeping traffic to concise technical discussion. I'm sure the :Pf team will rapidly disconnect from this alias if they have to :wade through reams of flames and chit chat, well-meaning as they :might be. Actually, the more personal and inflamed, the more fun it is! Fire away. Man-pages too long? function names too short? Speak up and we'll do our best to answer and to improve. Michael Jones IRIS Performer/Cosmo3D -- Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Mon Apr 1 17:09:37 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA00486; Mon, 1 Apr 1996 17:07:54 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA00483; Mon, 1 Apr 1996 17:07:53 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10525; Mon, 1 Apr 96 17:07:51 -0800 Received: from amelnx.advmar.com by deliverator.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id RAA05042; Mon, 1 Apr 1996 17:07:42 -0800 From: Hill_Brian@amelnx.advmar.com Received: from cc:Mail by amelnx.advmar.com id AA828418315; Mon, 01 Apr 96 20:05:30 EST Date: Mon, 01 Apr 96 20:05:30 EST Message-Id: <9603018284.AA828418315@amelnx.advmar.com> To: info-performer@sgi.com Subject: Re: High volume of mail on info-performer Status: O I think all answers to questions should be posted to the group. It helps us learn more about why things are wrong as well as why things are correct. I agree the subscribe and unsubscribe can be annoying so I have a filter that weeds them out before I have a chance to read them. Brian Hill From guest Mon Apr 1 17:35:11 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA00795; Mon, 1 Apr 1996 17:33:28 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA00792; Mon, 1 Apr 1996 17:33:27 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11987; Mon, 1 Apr 96 17:33:26 -0800 Received: from uucp-1.csn.net by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id RAA07769; Mon, 1 Apr 1996 17:33:23 -0800 Received: from evt.com (uucp@localhost) by uucp-1.csn.net (8.6.12/8.6.12) with UUCP id SAA25450 for csn!sgi.com!info-performer; Mon, 1 Apr 1996 18:33:22 -0700 Received: from snowmass by vail via ESMTP (940816.SGI.8.6.9/930416.SGI) for <@vail:info-performer@sgi.com> id SAA14787; Mon, 1 Apr 1996 18:20:46 -0800 Received: by snowmass (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id SAA23916; Mon, 1 Apr 1996 18:20:46 -0800 From: "Dewey Anderson" Message-Id: <9604011820.ZM23914@snowmass> Date: Mon, 1 Apr 1996 18:20:46 -0800 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.com Subject: DxfToIV Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Mike Jones, responding to Nuno wrote: >This is because the "DxfToIV" program has decided to do you a favor. It thinks >that the faceted geometry in the DXF-format files probably represents a smooth >surface and is doing the following: Just what I need! I can save 3D Studio objects in DXF format and if this will convert them to inventor and add the missing normals, I'll be a happy camper. Where would I get DxfToIV? We've got perf 2.0 and Inventor but I didn't notice them there. (Perhaps something got left out when we installed.) Dewey Anderson Evolving Video Technologies From guest Tue Apr 2 00:00:37 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA01694; Mon, 1 Apr 1996 23:59:01 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA01691; Mon, 1 Apr 1996 23:59:00 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23581; Mon, 1 Apr 96 23:58:59 -0800 Received: from barney.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id XAA24029; Mon, 1 Apr 1996 23:58:56 -0800 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id IAA20203; Tue, 2 Apr 1996 08:57:34 +0100 From: "Rob Jenkins" Message-Id: <9604020857.ZM20201@barney.reading.sgi.com> Date: Tue, 2 Apr 1996 08:57:34 +0100 In-Reply-To: "Dewey Anderson" "DxfToIV" (Apr 1, 6:20pm) References: <9604011820.ZM23914@snowmass> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Dewey Anderson" , info-performer@sgi.sgi.com Subject: Re: DxfToIV Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O There is a DxfToIv in the showcase.sw.showcase subsystem but you really should get hold of '3D File Translators 1.1' or xlators which has: DxfToIv, ObjToIv, SoftimageToIv, SlaToIv, IvToRib. It's on the Desktop Special Edition CD and I'm sure you can get it from the web, if I find a pointer I'll post it. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. Forum 1, Station Road, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Tue Apr 2 02:16:51 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA02449; Tue, 2 Apr 1996 02:04:46 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA02446; Tue, 2 Apr 1996 02:04:41 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA25941; Tue, 2 Apr 96 02:04:32 -0800 Received: from sun4nl.NL.net by deliverator.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id CAA14250; Tue, 2 Apr 1996 02:04:28 -0800 Received: from alley.fel.tno.nl by sun4nl.NL.net with SMTP id AA20004 (5.65b/CWI-3.3); Tue, 2 Apr 1996 12:04:20 +0200 Received: from s00sn1.fel.tno.nl (s00sn1 [134.203.8.207]) by alley.fel.tno.nl (8.6.12/8.6.12) with ESMTP id MAA06934 for ; Tue, 2 Apr 1996 12:01:58 +0200 Received: (from rioj7@localhost) by s00sn1.fel.tno.nl (8.7.3/8.7.3) id MAA28569 for info-performer@sgi.com; Tue, 2 Apr 1996 12:02:28 +0200 (MET DST) From: Veraart Message-Id: <199604021002.MAA28569@s00sn1.fel.tno.nl> Subject: Re: continuing 3ds saga To: info-performer@sgi.com (performer) Date: Tue, 2 Apr 1996 12:02:28 +0200 (MET DST) In-Reply-To: <9604010917.ZM18542@hell.asd.sgi.com> from "Don Hatch" at Apr 1, 96 09:17:53 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Status: O > Also do this: > setenv PFLD_LIBRARY_PATH . > (as described in a dark corner in the pfdLoadFile man page) > to see all the error messages from the run-time linker. > > Usually when this happens with the 3ds loader it means > you are missing libcil.so > (install it from the inst subsystem called "il_eoe.sw.c"). > Don > -- > Don Hatch hatch@sgi.com (415) 933-5150 Silicon Graphics, Inc. I look if this was the difference at the two Max Impacts that I tried. On the one where libcil.so was missing I tried the following setenv PFNFYLEVEL 5 setenv PFLD_LIBRARY_PATH . perfly crater.3ds and yes, dlopen() complained it couldn't find libcil.so. After copying it, the whole thing worked. I have a question about the installation. Why is this lib not installed when I tell performer not to install the Performer/friends? Mario From guest Tue Apr 2 15:37:32 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA03662; Tue, 2 Apr 1996 14:40:47 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA03659; Tue, 2 Apr 1996 14:40:37 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16706; Tue, 2 Apr 96 14:40:29 -0800 Received: from artemis.rus.uni-stuttgart.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA05128; Tue, 2 Apr 1996 14:40:02 -0800 Received: from visin1.rus.uni-stuttgart.de (visin1.rus.uni-stuttgart.de [129.69.29.188]) by artemis.rus.uni-stuttgart.de with ESMTP id PAA06445 (8.6.12/IDA-1.6 for ); Tue, 2 Apr 1996 15:16:16 +0200 Received: by visin1.rus.uni-stuttgart.de (940816.SGI.8.6.9/930416.SGI/BelWue-1.1) for info-performer@sgi.sgi.com id PAA29115; Tue, 2 Apr 1996 15:16:15 +0200 From: "Daniela Rainer" Message-Id: <9604021516.ZM29113@visin1.rus.uni-stuttgart.de> Date: Tue, 2 Apr 1996 15:16:15 +0000 Reply-To: rainer@RUS.Uni-Stuttgart.DE X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Why does XSGISetStereoBuffer not work with Performer? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, why does XSGISetStereoBuffer not work with Performer? I have a GLX (mixed model) program, that sets the STR_BOT-stereo mode, opens a GLX window (configured for stereo) and sets alternating the stereobuffer with XSGISetStereoBuffer(xdisplay, window, STEREO_BUFFER_LEFT), XSGISetStereoBuffer(xdisplay, window, STEREO_BUFFER_RIGHT) and it works. If I open a Performer window with pfPWinType(pw, PFPWIN_TYPE_X); pfOpenPWin(pw); pfChoosePWinFBConfig(pw, FBAttr ); xdisplay = pfGetCurWSConnection(); glWindow = pfGetPWinWSWindow(pw); and I link with the _igl libraries, the window should also be a GLX-window, but XSGISetStereoBuffer(xdisplay, glwindow, STEREO_BUFFER_...) has no effect. Thanks for any help, Daniela -- Daniela Rainer rainer@rus.uni-stuttgart.de From guest Tue Apr 2 15:36:58 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA03672; Tue, 2 Apr 1996 14:43:43 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA03669; Tue, 2 Apr 1996 14:43:37 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16890; Tue, 2 Apr 96 14:43:04 -0800 Received: from atc.boeing.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA05761; Tue, 2 Apr 1996 14:42:44 -0800 Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA12447; Tue, 2 Apr 1996 13:48:33 -0800 Received: from chlg1 by pgate with SMTP ; Tue, 2 Apr 96 15:27:55 EST Received: by chlg1 (931110.SGI/930416.SGI) for performerr@pgate id AA02811; Tue, 2 Apr 96 15:21:53 -0500 Date: Tue, 2 Apr 96 15:21:53 -0500 From: donnaa@chlg1.boeing.com (Donna Allen) Message-Id: <9604022021.AA02811@chlg1> To: performerr@pgate.he.boeing.com, donnaa@chlg1.boeing.com Subject: oil rig model? Reply-To: allend@pgate.he.boeing.com Status: O April 2, 1996 Hi performer friends, I just heard from a colleague that SGI has a demo tape of the "Infinite Reality" out. On this tape, there is a model of an ocean "oil rig". I am in need of a model of an oil rig, does anyone know where I could find this, or who I could talk to about it? Thanks in advance Donna *************************************************************************** Donna N. Allen Boeing Defense & Space Group Phone: (610) 591-7963 Helicopters Division FAX: (610) 591-5636 P.O. Box 16858 MS P38-61 allend@pgate.he.boeing.com Philadelphia, PA 19142-0858 *************************************************************************** From guest Tue Apr 2 15:37:24 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA03655; Tue, 2 Apr 1996 14:37:51 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA03652; Tue, 2 Apr 1996 14:37:51 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16523; Tue, 2 Apr 96 14:37:13 -0800 Received: from spiffy.paradigmsim.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA04329; Tue, 2 Apr 1996 14:36:47 -0800 Received: from stanzi by spiffy.paradigmsim.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA26999; Tue, 2 Apr 1996 11:50:18 -0600 Sender: jperser@paradigmsim.com Message-Id: <316168D9.794B@paradigmsim.com> Date: Tue, 02 Apr 1996 11:50:17 -0600 From: John Perser X-Mailer: Mozilla 2.0 (X11; I; IRIX 5.3 IP22) Mime-Version: 1.0 To: info-performer@sgi.sgi.com Subject: Audition Demo Software Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Paradigm Simulation Inc. Announces Audition Demo Availability Dallas - March 22, 1996 You may download a demo version of the Audition wave editor from the Paradigm Simulation Web Server at http://www.paradigmsim.com/products.html or via anonymous ftp ftp://ftp.paradigmsim.com/pub/outgoing This demo is a working version of the editor without the ability to save wave file modifications. Audition is a high performance real-time sound wave editor for Silicon Graphics workstations. It supports not only the standard features found in sound shaping tools but supplies a unique real-time playback capability for many functions. Unlike other tools that force you to wait to hear the changes you have made to your wave form, Audition allows you to hear the changes as you make them by using the same real- time technology used by the AudioWorks2 spatial audio system. Audition comes stand alone or bundled with the AudioWorks2 spatial audio development system. For more information on AudioWorks2 please visit our web site at: http://www.paradigmsim.com/products.html In addition to wave editing using SGI audio hardware, Audition supports Paradigm's Sound Engine II. A technical overview of the product is also available from our web site at http://www.paradigmsim.com/auditiontech.html Contatct: mailto://marketing@paradigmsim.com for more information about AudioWorks2 and other Paradigm Simulation products. Please visit our webpage at http://www.paradigmsim.com -- John Perser Manager/Audio Products mailto://jperser@paradigmsim.com Paradigm Simulation, Inc. PHONE: 214-960-2301 FAX: 214-960-2303 http://www.paradigmsim.com http://web2.airmail.net/jperser From guest Tue Apr 2 15:37:07 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA03667; Tue, 2 Apr 1996 14:43:27 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA03664; Tue, 2 Apr 1996 14:43:26 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16898; Tue, 2 Apr 96 14:43:10 -0800 Received: from begonia.lab3d.odont.ku.dk by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA05783; Tue, 2 Apr 1996 14:42:48 -0800 Received: from erantis.lab3d.odont.ku.dk by begonia.lab3d.odont.ku.dk via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for <@begonia.lab3d.odont.ku.dk:info-performer@sgi.sgi.com> id OAA04720; Tue, 2 Apr 1996 14:38:01 +0200 Received: by erantis.lab3d.odont.ku.dk (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.sgi.com id OAA15350; Tue, 2 Apr 1996 14:37:59 +0200 From: "Morten Bro-Nielsen" Message-Id: <9604021437.ZM15348@lab3d.odont.ku.dk> Date: Tue, 2 Apr 1996 14:37:56 -0600 In-Reply-To: sbrown@nestor.UCSD.EDU "Re: Tired of unsubscribe/subscribe request?" (Apr 1, 12:34pm) References: <9604011234.ZM15469@nestor.ucsd.edu> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Tired of unsubscribe/subscribe request? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I have been wondering for a LONG time, why this group is not on the regular newsgroup system. It would be both easier to handle and more convenient if it was a moderated newsgroup. Even with occasional noise from 'intruders' I would prefer that. --Morten -- ,,, (o o) ---------------------------oOO--(_)--OOo----------------------------------- Morten Bro-Nielsen Phone.: (Panum) +45 3532 6758 Technical University of Denmark Fax...: +45 3532 6505 Department of Mathematical Modelling E-mail: bro@imm.dtu.dk Building 321, DK-2800 Lyngby, DENMARK http://www.imm.dtu.dk/~bro .... Creator of the Mvox medical image visualization package .... http://www.imm.dtu.dk/~mvox --------------------------------------------------------------------------- From guest Tue Apr 2 15:37:26 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA03650; Tue, 2 Apr 1996 14:37:49 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA03647; Tue, 2 Apr 1996 14:37:44 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16530; Tue, 2 Apr 96 14:37:20 -0800 Received: from spiffy.paradigmsim.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA04393; Tue, 2 Apr 1996 14:37:05 -0800 Received: from stanzi by spiffy.paradigmsim.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA26989; Tue, 2 Apr 1996 11:49:28 -0600 Sender: jperser@paradigmsim.com Message-Id: <316168A7.446B@paradigmsim.com> Date: Tue, 02 Apr 1996 11:49:27 -0600 From: John Perser X-Mailer: Mozilla 2.0 (X11; I; IRIX 5.3 IP22) Mime-Version: 1.0 To: info-performer@sgi.sgi.com Subject: AudioWorks2 Demos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Paradigm Simulation Inc. Announces AudioWorks2 Demos Availability Dallas - March 21, 1996 You may download AudioWorks2 demo applications from the Paradigm Simulation Web Server at http://www.paradigmsim.com/products.html or via anonymous ftp ftp://ftp.paradigmsim.com/pub/outgoing Look for the links to AudioWorks2 as well as Audition downloads. These demos will quickly show the value of adding spatial audio to your visual simulation and will run on any SGI computer supporting internal audio capability. Both Stereo and Quad are supported on your SGI workstation through the audio outputs provided on your workstation. AudioWorks2 is the premier audio simulation development environment for Silicon Graphics workstations, providing the developer and end-user with high-level control of multiple sound emitters and listeners in a virtual space. As users move objects and listeners and modify environmental and object sounds, AudioWorks2 automatically calculates physical sound effects for each sound emitter and listener (such as Doppler shifts and propagation delays), prioritizes all simulation sounds and controls the sound generation hardware. AudioWorks2 also comes with Audition, the new real-time sound wave editor from Paradigm. AudioWorks2 can be used stand alone with any 3D real-time graphics system. AudioWorks2 is also fully integrated with Vega, Paradigm's Performer based 3D graphics development environment. For more information on Audition visit: http://www.paradigmsim.com/audition.html AudioWorks2 supports outboard rendering engines in addition to SGI audio hardware. Currently shipping is support for Paradigm's Sound Engine II and the Acoustetron II from Crystal River Engineering. A technical overview of the product is also available from our web site at http://www.paradigmsim.com/awtechov.html Contatct: mailto://marketing@paradigmsim.com for more information about AudioWorks2 and other Paradigm Simulation products. Please visit our webpage at http://www.paradigmsim.com -- John Perser Manager/Audio Products mailto://jperser@paradigmsim.com Paradigm Simulation, Inc. PHONE: 214-960-2301 FAX: 214-960-2303 http://www.paradigmsim.com http://web2.airmail.net/jperser From guest Tue Apr 2 19:10:46 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA04780; Tue, 2 Apr 1996 18:15:23 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA04777; Tue, 2 Apr 1996 18:15:17 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03613; Tue, 2 Apr 96 18:15:05 -0800 Received: from box_office.rit.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id SAA08387; Tue, 2 Apr 1996 18:15:00 -0800 Received: from [199.181.165.150] (stage_mgr.rit.com [199.181.165.150]) by box_office.rit.com (8.6.9/8.6.9) with SMTP id GAA13611; Tue, 2 Apr 1996 06:53:41 -0800 Date: Tue, 2 Apr 1996 06:53:41 -0800 Message-Id: <199604021453.GAA13611@box_office.rit.com> Subject: Cosmo3D = Java3D? From: Jayson Raymond To: "Michael Jones" , , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Status: O A question intended to liven up the conversation, Michael. The Java folks have started the Java3D mailing list... Cosmo3D is intended for Java... thus are they one and the same? --Jayson Jayson Raymond From guest Tue Apr 2 21:26:52 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id UAA05284; Tue, 2 Apr 1996 20:12:48 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id UAA05281; Tue, 2 Apr 1996 20:12:39 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08376; Tue, 2 Apr 96 20:12:20 -0800 Received: from binky.paradigmsim.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id UAA18105; Tue, 2 Apr 1996 20:12:14 -0800 Received: by binky.paradigmsim.com (940816.SGI.8.6.9/921111.SGI.AUTO) id WAA05598; Tue, 2 Apr 1996 22:10:56 -0600 From: "Craig Phillips" Message-Id: <9604022210.ZM5596@binky.paradigmsim.com> Date: Tue, 2 Apr 1996 22:10:53 -0600 In-Reply-To: "Angus Dorbie" "Re: Tired of unsubscribe/subscribe request?" (Apr 1, 10:53pm) References: <9604011234.ZM15469@nestor.ucsd.edu> <9604012253.ZM1685@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Angus Dorbie" , sbrown@nestor.ucsd.edu, info-performer@sgi.sgi.com Subject: Re: Tired of unsubscribe/subscribe request? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 1, 10:53pm, Angus Dorbie wrote: > Subject: Re: Tired of unsubscribe/subscribe request? > No pain, no gain. > damn right. -- __________________________________________________ Craig Phillips CTO, Paradigm Simulation Inc. 14900 Landmark, Suite 400, Dallas, Texas 75248 craig@paradigmsim.com 214-960-2301 __________________________________________________ From guest Wed Apr 3 00:50:18 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA05715; Tue, 2 Apr 1996 23:58:36 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA05712; Tue, 2 Apr 1996 23:58:32 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13388; Tue, 2 Apr 96 23:58:20 -0800 Received: from cambridge.cadcentre.co.uk by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id XAA29067; Tue, 2 Apr 1996 23:57:53 -0800 Received: from internet.cadcentre.co.uk by cambridge.cadcentre.co.uk with ESMTP id IAA21638; Wed, 3 Apr 1996 08:31:19 +0100 Received: from pc11 by internet.cadcentre.co.uk with SMTP id IAA16675; Wed, 3 Apr 1996 08:54:54 +0100 Received: by pc11 with Microsoft Mail id <3162AE56@pc11>; Wed, 03 Apr 96 08:59:02 PST From: "P.Elton" To: "'info-performer'" Subject: RE: oil rig model? Date: Wed, 03 Apr 96 07:56:00 PST Message-Id: <3162AE56@pc11> Encoding: 51 TEXT X-Mailer: Microsoft Mail V3.0 Status: O I think this is ours. We do CAD and Walkthrough s/w (PDMS & Review Reality) for oil rigs, power plants, refineries etc.. Unfortunately the datasets are generally owned by our customers and used only with specific permissions each time. Also we use our own geometry format although we have experimented with outputing Wavefront's OBJ format. Perhaps if you let me know what you would use the model for we might be able to help but with customer's data life can get complex getting permissions!! Regards Paul Paul T. Elton Chief Designer -Visual Systems Email p.elton@cadcentre.co.uk CADCentre Limited Tel (+44)-1223-556655 High Cross, Madingley Road, Fax (+44)-1223-556666 Cambridge, UK CB3 OHB ---------- From: guest To: performerr; donnaa Subject: oil rig model? Date: 02 April 1996 15:21 April 2, 1996 Hi performer friends, I just heard from a colleague that SGI has a demo tape of the "Infinite Reality" out. On this tape, there is a model of an ocean "oil rig". I am in need of a model of an oil rig, does anyone know where I could find this, or who I could talk to about it? Thanks in advance Donna *************************************************************************** Donna N. Allen Boeing Defense & Space Group Phone: (610) 591-7963 Helicopters Division FAX: (610) 591-5636 P.O. Box 16858 MS P38-61 allend@pgate.he.boeing.com Philadelphia, PA 19142-0858 *************************************************************************** From guest Wed Apr 3 02:09:36 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA06197; Wed, 3 Apr 1996 01:10:26 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA06194; Wed, 3 Apr 1996 01:10:21 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15775; Wed, 3 Apr 96 01:10:05 -0800 Received: from relay1.oleane.net by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id BAA14645; Wed, 3 Apr 1996 01:10:00 -0800 Received: from corysmailserv (mailhost.corys.fr [194.2.225.1]) by relay1.oleane.net (8.6.10/8.6.9) with SMTP id LAA06257 for ; Wed, 3 Apr 1996 11:09:54 +0200 Received: from lucassg1 by corysmailserv (5.x/SMI-SVR4) id AA09163; Wed, 3 Apr 1996 10:53:08 +0200 Received: by lucassg1 (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id KAA09584; Thu, 4 Apr 1996 10:53:54 +0200 From: "Lionel Maiaux" Message-Id: <9604041053.ZM9582@lucassg1> Date: Thu, 4 Apr 1996 10:53:41 -0600 In-Reply-To: "Morten Bro-Nielsen" "Re: Tired of unsubscribe/subscribe request?" (Apr 2, 2:37pm) References: <9604011234.ZM15469@nestor.ucsd.edu> <9604021437.ZM15348@lab3d.odont.ku.dk> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.com Subject: Re: Tired of unsubscribe/subscribe request? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > I have been wondering for a LONG time, why this group is not on the > regular newsgroup system. It would be both easier to handle and more > convenient if it was a moderated newsgroup. Maybe because some of us (like me) can't access news ... From guest Wed Apr 3 02:48:37 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA06496; Wed, 3 Apr 1996 01:47:12 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA06493; Wed, 3 Apr 1996 01:47:12 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16478; Wed, 3 Apr 96 01:47:07 -0800 Received: from holodeck.asd.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA03657; Wed, 3 Apr 1996 01:47:06 -0800 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer@sgi.sgi.com id BAA06489; Wed, 3 Apr 1996 01:47:05 -0800 From: aschaffe (Allan Schaffer) Message-Id: <9604030147.ZM6487@holodeck.asd.sgi.com> Date: Wed, 3 Apr 1996 01:47:05 -0800 In-Reply-To: "Michael Jones" "Re: Noise traffic on info-performer" (Apr 1, 3:53pm) References: <9604020017.ZM16746@cordoba.reading.sgi.com> <9604011553.ZM19037@babar.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Noise traffic on info-performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 1, 3:53pm, Michael Jones wrote: > On Apr 2, 12:17am, Greg Edwards, SGI UK. wrote: > > :It's maintained by Alan Schaffer who has a zillion other things to do. > > he's on vacation (at a wedding in India) and unavailable to > handle unsubscribe requests. I'm back, tanned, rested, and ready. Some unfocused thoughts about info-performer traffic: - I have a system in place for mail digests but as of yet, it doesn't play nicely with the info-performer setup. I'll add this to my to-do list for late-night extra-curricular projects. - The idea of moving info-performer to a newsgroup has floated around for a while. Considering our current readership (~815 people) and traffic (~10 messages/day) we could probably bring together the votes to pass. Personally, I'd prefer to try (optional, daily) digests before giving more thought to creating a newsgroup. Drop me a note if you'd like to be a digest guinea-pig. - This doesn't yet help the subscribe/unsubscribe problem. I've toyed with the idea of adding a "How-To" informational header or footer to each message, to the digest, or a periodic (weekly) administrivia message. I think this will work well enough that filters won't be necessary. Allan ps. No, it wasn't my wedding. Keep those proposals coming. ;-) -- Allan Schaffer aschaffe@sgi.com Silicon Graphics http://reality.sgi.com/aschaffe From guest Wed Apr 3 03:24:40 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA06637; Wed, 3 Apr 1996 02:33:44 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA06634; Wed, 3 Apr 1996 02:33:39 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17296; Wed, 3 Apr 96 02:33:20 -0800 Received: from atc.boeing.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA05152; Wed, 3 Apr 1996 02:33:18 -0800 Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA02515; Wed, 3 Apr 1996 02:37:35 -0800 Received: from splinter.boeing.com by pgate with SMTP ; Wed, 3 Apr 96 03:30:27 EST Received: from atc.boeing.com by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA132460371; Wed, 3 Apr 1996 00:32:51 -0800 Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA17777; Wed, 3 Apr 1996 00:36:59 -0800 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id AAA00569; Wed, 3 Apr 1996 00:32:35 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA03653; Wed, 3 Apr 1996 09:28:22 +0100 From: "Angus Dorbie" Message-Id: <9604030928.ZM3651@bitch.reading.sgi.com> Date: Wed, 3 Apr 1996 09:28:22 +0100 In-Reply-To: donnaa@chlg1.boeing.com (Donna Allen) "oil rig model?" (Apr 2, 3:21pm) References: <9604022021.AA02811@chlg1> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: allend@pgate.he.boeing.com, performerr@pgate.he.boeing.com, donnaa@chlg1.boeing.com Subject: Re: oil rig model? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I expect this was a demonstration of the Review Reality software by CAD Center, a Cambridge UK based company. It's not performer based & renders pdms data using the SMP to generate polygons from the parametric data as you fly through the scene. If you want an offshore platform model I expect it'd help if you are more specific about why you need this model. The databases which the CAD Centre use have nuts 'n bolts detail so may not be appropriate. Rgds, Angus. On Apr 2, 3:21pm, Donna Allen wrote: > Subject: oil rig model? > April 2, 1996 > > Hi performer friends, > > I just heard from a colleague that SGI has a demo > tape of the "Infinite Reality" out. On this tape, > there is a model of an ocean "oil rig". I am in > need of a model of an oil rig, does anyone know > where I could find this, or who I could talk to > about it? > > Thanks in advance > > Donna > *************************************************************************** > Donna N. Allen Boeing Defense & Space Group > Phone: (610) 591-7963 Helicopters Division > FAX: (610) 591-5636 P.O. Box 16858 MS P38-61 > allend@pgate.he.boeing.com Philadelphia, PA 19142-0858 > *************************************************************************** > > >-- End of excerpt from Donna Allen -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Wed Apr 3 04:24:03 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id DAA07076; Wed, 3 Apr 1996 03:27:20 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id DAA07073; Wed, 3 Apr 1996 03:27:14 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18101; Wed, 3 Apr 96 03:26:59 -0800 Received: from majestix.cmr.no by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id DAA06864; Wed, 3 Apr 1996 03:26:51 -0800 Received: from uranus.cmr.no (uranus.cmr.no [129.177.31.119]) by majestix.cmr.no (8.6.12/8.6.9) with ESMTP id NAA06142; Wed, 3 Apr 1996 13:28:37 +0200 Received: from uranus (localhost [127.0.0.1]) by uranus.cmr.no (8.6.9/8.6.9) with SMTP id HAA02583; Wed, 3 Apr 1996 07:26:46 -0400 Sender: Rune.Torkildsen@cmr.no Message-Id: <31626074.66CC@cmr.no> Date: Wed, 03 Apr 1996 13:26:46 +0200 From: Rune Torkildsen Organization: Christian Michelsen Research AS X-Mailer: Mozilla 2.0 (X11; I; HP-UX B.10.01 9000/715) Mime-Version: 1.0 To: allend@pgate.he.boeing.com Cc: info-performer@sgi.sgi.com Subject: Re: oil rig model? References: <9604022021.AA02811@chlg1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hi, Donna Allen wrote: > > April 2, 1996 > > Hi performer friends, > > I just heard from a colleague that SGI has a demo > tape of the "Infinite Reality" out. On this tape, > there is a model of an ocean "oil rig". I am in > need of a model of an oil rig, does anyone know > where I could find this, or who I could talk to > about it? > > Thanks in advance > > Donna > *************************************************************************** > Donna N. Allen Boeing Defense & Space Group > Phone: (610) 591-7963 Helicopters Division > FAX: (610) 591-5636 P.O. Box 16858 MS P38-61 > allend@pgate.he.boeing.com Philadelphia, PA 19142-0858 > *************************************************************************** We have models of all major oil rigs in the Norwegian sector of the North Sea modelled in Multigen Flight format (flt). If you have a look at an article about our Crisis Management Training System you will be able to see one of the models in action. The article is available via the following URL: http://www.cmr.no/english/articles/epti.html Unfortunately, the models are owned by our customer and if you want to obtain some of the models, some agreement have to be made. If you are interested, I will get in contact with the customer and see whether any agreements on this matter is possible. Regards --- Rune Torkildsen Christian Michelsen Research AS, Phone: +47 55 57 43 54, Fax: +47 55 57 40 41, email: Rune.Torkildsen@cmr.no , WWW: http://www.cmr.no From guest Wed Apr 3 07:15:30 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA07484; Wed, 3 Apr 1996 06:15:14 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA07481; Wed, 3 Apr 1996 06:15:14 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21343; Wed, 3 Apr 96 06:15:13 -0800 Received: from dub-img-5.compuserve.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA17954; Wed, 3 Apr 1996 06:15:11 -0800 Received: by dub-img-5.compuserve.com (8.6.10/5.950515) id JAA06249; Wed, 3 Apr 1996 09:15:09 -0500 Date: 03 Apr 96 09:13:33 EST From: Jean BENOIT <101372.3460@compuserve.com> To: Infos Performer Subject: Spherical projection on I.Reality Message-Id: <960403141332_101372.3460_JHP123-1@CompuServe.COM> Status: O I need to project a Performer visual on a dome.To do that i have to made a image distorsion . A SGI solution is to keep the image in the framebuffer, to use it like a texture to map on a spherical form. I think it' s possible to do that with a postDraw multipass callback. First, does Performer have functions to do that ( keep the image on Framebuffer) Second, my customer want to use only 3 channels to have a Fov of 180 by 80. Do you think if it's possible and what are the problems with this sort of large angles. Thank you for all to answer me . Yoel From guest Wed Apr 3 07:56:50 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA07529; Wed, 3 Apr 1996 06:56:08 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA07526; Wed, 3 Apr 1996 06:56:03 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22043; Wed, 3 Apr 96 06:55:47 -0800 Received: from inesc.inesc.pt by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA20549; Wed, 3 Apr 1996 06:55:30 -0800 Received: from minerva.inesc.pt (minerva-2.inesc.pt) by inesc.inesc.pt with SMTP; id AA13455 (/); Wed, 3 Apr 1996 15:55:22 +0100 Received: from minerva (localhost) by minerva.inesc.pt (4.1/Sun OS 4.1.1) id AA11833; Wed, 3 Apr 96 16:55:22 +0200 Sender: mgo@minerva.inesc.pt Message-Id: <31629159.41C67EA6@minerva.inesc.pt> Date: Wed, 03 Apr 1996 16:55:21 +0200 From: Nuno Godinho X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Performer Mailing List Subject: QUESTION: Clipping a submerged terrain? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O I am simulating a beach. Having already modeled the terrain I created a single mesh that defines both the beach and the submerged ground. I have two questions: -I then make use of the pfEarthSky clipping capacities to hide the underwater part of the terrain when I'm not under water. Is the underwater part of the mesh dealying the animation? Should I create two separate objects (underwater and overwater) and switch between them? -When moving underwater I have to simulate the water line above me (like a ceiling). Unlike overwater I cannot use pfEarthSky to do the clipping for me. I am planning on creating a biiig square that stands above my head hiding the overwater terrain. Is there a better solution? thanks Nuno From guest Wed Apr 3 11:25:14 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA08166; Wed, 3 Apr 1996 11:23:09 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA08163; Wed, 3 Apr 1996 11:23:08 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04299; Wed, 3 Apr 96 11:23:07 -0800 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA18096; Wed, 3 Apr 1996 11:22:57 -0800 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA04281; Wed, 3 Apr 96 11:22:51 -0800 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA02872; Wed, 3 Apr 1996 11:22:44 -0800 From: "Javier Castellar" Message-Id: <9604031122.ZM2870@sixty.asd.sgi.com> Date: Wed, 3 Apr 1996 11:22:44 -0800 In-Reply-To: Jean BENOIT <101372.3460@compuserve.com> "Spherical projection on I.Reality" (Apr 3, 9:13am) References: <960403141332_101372.3460_JHP123-1@CompuServe.COM> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: Infos Performer , Jean BENOIT <101372.3460@compuserve.com> Subject: Re: Spherical projection on I.Reality Cc: daly@sixty Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Regarding distortion correction we are going to release a pfu API that let you perform both static and dynamic distortion correction on iR (InfiniteReality) systems. The current API is looks like: pfuDistortion *pfuNewDistortion (pfChannel *, int mode, pfGeoSet *); void pfuDeleteDistortion (pfuDistortion *); void pfuCorrectDistortion (pfuDistortion *); and is going to be available right after the Performer 2.1 release [iR support for performer]. You should expect a posting on this mailing list soon. The main aproach is to render first a planar projection on a pbuffer and then perform a framebuffer to texture copy. After this copy we render again over a undistorted mesh (with the proper isoFOVs). This mesh have to be provided by the user and you can undistort the following effects in ones: a) Perspective distortion (from planar to spherical isoFOVs) b) Offset distortion c) Optical distortion. It is important to expose here the following restrictions: 1) The limits in resolution for the corrected channel will depend on: 1.1.- frame rate 1.2.- scene depth complexity 1.3.- number of RMs => you should expect resolutions less than 1088x810 at 60hz with four RM6 at a decent depth complexity. (single channel per pipe) 2) There is a minimum trade-off of mesh resolution vs. scene geometry, 1.1.- For an static mesh is neglectable 1.2.- For a dynamic mesh depends if you are fill or geometry limited. 3) There is a trade-off between corrected resolution vs. fill rate 4) There is NO ADDITIONAL LATENCY, all is done in the same frame time. 5) We make full use of the BEF FIFO in iR which in other words means that we save most of the fill on the last pass. You should expend one pipe per distorted channel if you are running at 60hz. The spirit of the main design of iR is to change the way in which visual simulation has been solving classic problems on a COT system and open new possibilities and markets for our integrators. We beleive that although this distortion correction system is very decent and generic the main battle is to use more pixels, this is why it is a pfu and not a pf. The aproach in which you have and Area Of Interest + a background channel is fine for us (a two pipe iR can solve the problem with one pipe for the dome and another for the AOI + instrumentation) but we think that now we have available much more pixels and fill rate than ever, which let us to go into more channels without distortion correction versus fewer channel with d.c. Off course you can find requeriments in which the number of channels will be too high to be implemented in the projection system and then i agree that you will need to go to a distortion corrected channel configuration. Anyway, the display system intergrators are becoming with nice solutions in multichannel domes (6 channel and 8 channel configurations) that provide us a nice arena to play. Anyway is up to you, intergrators and developers, to decide wisely if you should use or not the AOI+bakcground aproach or an multichannel dome, but keeping in mind the trade offs related with your choice (resolution, integration problems ... etc) Hope this helps. -Javier -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon From guest Wed Apr 3 11:50:48 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA08230; Wed, 3 Apr 1996 11:48:41 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA08227; Wed, 3 Apr 1996 11:48:41 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06173; Wed, 3 Apr 96 11:48:39 -0800 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA21424; Wed, 3 Apr 1996 11:48:36 -0800 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.com id AA06162; Wed, 3 Apr 96 11:48:35 -0800 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id LAA02926; Wed, 3 Apr 1996 11:48:34 -0800 From: "Javier Castellar" Message-Id: <9604031148.ZM2924@sixty.asd.sgi.com> Date: Wed, 3 Apr 1996 11:48:33 -0800 X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Spherical projection on I.Reality Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Regarding distortion correction we are going to release a pfu API that let you perform both static and dynamic distortion correction on iR (InfiniteReality) systems. The current API is looks like: pfuDistortion *pfuNewDistortion (pfChannel *, int mode, pfGeoSet *); void pfuDeleteDistortion (pfuDistortion *); void pfuCorrectDistortion (pfuDistortion *); and is going to be available right after the Performer 2.1 release [iR support for performer]. You should expect a posting on this mailing list soon. The main aproach is to render first a planar projection on a pbuffer and then perform a framebuffer to texture copy. After this copy we render again over a undistorted mesh (with the proper isoFOVs). This mesh have to be provided by the user and you can undistort the following effects in ones: a) Perspective distortion (from planar to spherical isoFOVs) b) Offset distortion c) Optical distortion. It is important to expose here the following restrictions: 1) The limits in resolution for the corrected channel will depend on: 1.1.- frame rate 1.2.- scene depth complexity 1.3.- number of RMs => you should expect resolutions less than 1088x810 at 60hz with four RM6 at a decent depth complexity. (single channel per pipe) 2) There is a minimum trade-off of mesh resolution vs. scene geometry, 1.1.- For an static mesh is neglectable 1.2.- For a dynamic mesh depends if you are fill or geometry limited. 3) There is a trade-off between corrected resolution vs. fill rate 4) There is NO ADDITIONAL LATENCY, all is done in the same frame time. 5) We make full use of the BEF FIFO in iR which in other words means that we save most of the fill on the last pass. You should expend one pipe per distorted channel if you are running at 60hz. The spirit of the main design of iR is to change the way in which visual simulation has been solving classic problems on a COT system and open new possibilities and markets for our integrators. We beleive that although this distortion correction system is very decent and generic the main battle is to use more pixels, this is why it is a pfu and not a pf. The aproach in which you have and Area Of Interest + a background channel is fine for us (a two pipe iR can solve the problem with one pipe for the dome and another for the AOI + instrumentation) but we think that now we have available much more pixels and fill rate than ever, which let us to go into more channels without distortion correction versus fewer channel with d.c. Off course you can find requeriments in which the number of channels will be too high to be implemented in the projection system and then i agree that you will need to go to a distortion corrected channel configuration. Anyway, the display system intergrators are becoming with nice solutions in multichannel domes (6 channel and 8 channel configurations) that provide us a nice arena to play. Anyway is up to you, intergrators and developers, to decide wisely if you should use or not the AOI+bakcground aproach or an multichannel dome, but keeping in mind the trade offs related with your choice (resolution, integration problems ... etc) Hope this helps. -Javier -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon From guest Wed Apr 3 20:07:56 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id UAA09955; Wed, 3 Apr 1996 20:05:52 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id UAA09952; Wed, 3 Apr 1996 20:05:52 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02432; Wed, 3 Apr 96 20:05:49 -0800 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA20962; Wed, 3 Apr 1996 20:05:50 -0800 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.com id AA02423; Wed, 3 Apr 96 20:05:45 -0800 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id UAA03398; Wed, 3 Apr 1996 20:05:44 -0800 From: "Javier Castellar" Message-Id: <9604032005.ZM3396@sixty.asd.sgi.com> Date: Wed, 3 Apr 1996 20:05:43 -0800 In-Reply-To: "Dennis Pierce" "Re: Spherical projection on I.Reality" (Apr 3, 10:30pm) References: <9604031148.ZM2924@sixty.asd.sgi.com> <9604032230.ZM19314@dolphin.orlando.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Dennis Pierce" Subject: Re: Spherical projection on I.Reality Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O In general we would like to relay for both disotortion correction and blending on the display system (i.e. we have here two SEOS Prodas with 3 channels and 155 degrees which perform the blending and the distortion correction). In case that the display system can not deal with distortion correction or blending (like some LCD light valve projectors) then you have to go in a trade off of distortion correction vs. resolution/n_RMs. In cases of blending for LCD projectors the developer/integrator could use a 2D polymesh frame with source alpha and HIGH quality alpha to make a digital blending. There is a small overhead of fill rate depending on the area being fade but ... this is again a developer choice. We are not planning any specific support for this blending since we prefer to relay on integrators. SGI is not an integrator and we will not compete with our own clients (integrators). Anyway the implementation of this aproach is easy using libpr or ogl in the draw callback. On Apr 3, 10:30pm, Dennis Pierce wrote: > Subject: Re: Spherical projection on I.Reality > > how are you going to handle the meshing of adjacent images? most high- > end projectors allow feathering, but this is only at the edge of the > "normal" horizontal edges - are you going to require planetary projectors, > or have you folks thought through other clever schemes? > > > -- > -- > Dennis Pierce > SGI / Ste 130 / 900 Winderley PL / Maitland FL 32751 > > work : 407.660.0073 > late : 407.660.2789 > cell : 407.256.8447 > vmail: 800.326.1020 x58548 >-- End of excerpt from Dennis Pierce -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon From guest Thu Apr 4 01:21:07 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA10455; Thu, 4 Apr 1996 01:19:17 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA10452; Thu, 4 Apr 1996 01:19:16 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09073; Thu, 4 Apr 96 01:19:14 -0800 Received: from beatrix.fss.fokker.nl by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id BAA10269; Thu, 4 Apr 1996 01:19:58 -0800 Received: from chopstix (chopstix.fss.fokker.nl) by beatrix.fss.fokker.nl with SMTP id AA17356 (5.67b/IDA-1.5 for ); Thu, 4 Apr 1996 11:15:42 +0200 Received: by chopstix (940816.SGI.8.6.9//ident-1.0) id LAA04941; Thu, 4 Apr 1996 11:15:40 +0200 From: Message-Id: <199604040915.LAA04941@chopstix> Subject: shadows in performer To: info-performer@sgi.sgi.com Date: Thu, 4 Apr 1996 11:15:40 +0200 (MDT) X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Content-Length: 627 Status: O Hello all, I want to generate a scene using performer with a light source casting shadows. I have been playing with the example fastshadows GL code of Paul Haeberli e.a. (shad.c). I was wondering if somebody has used this technique in combination with performer? Example code would be greatly appreciated. Thanks Marc. -- Marc J. Neefs Fokker Space BV email: neefs@fss.fokker.nl B.U Simulation & Robotics phone: 071-245269 Newtonweg 1 fax: 071-245499 Leiden home phone: 015-144599 The Netherlands From guest Thu Apr 4 03:05:08 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id DAA10663; Thu, 4 Apr 1996 03:02:41 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id DAA10660; Thu, 4 Apr 1996 03:02:40 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10595; Thu, 4 Apr 96 03:02:38 -0800 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id DAA14437; Thu, 4 Apr 1996 03:04:31 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id MAA06628; Thu, 4 Apr 1996 12:03:12 +0100 From: "Angus Dorbie" Message-Id: <9604041203.ZM6626@bitch.reading.sgi.com> Date: Thu, 4 Apr 1996 12:03:11 +0100 In-Reply-To: "Javier Castellar" "Re: Spherical projection on I.Reality" (Apr 3, 8:05pm) References: <9604031148.ZM2924@sixty.asd.sgi.com> <9604032230.ZM19314@dolphin.orlando.sgi.com> <9604032005.ZM3396@sixty.asd.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Javier Castellar" , "Dennis Pierce" Subject: Re: Spherical projection on I.Reality Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O For blending for ROI you could use the underlying vertex colour and use a texture modulation texture function & make your ROI mesh vertices black. This would mean you'd save the a screen clear and you wouldn't have to blend. You could also use the remaining vertec colours as a local brightness control on the dome. Rgds, Angus. On Apr 3, 8:05pm, Javier Castellar wrote: > Subject: Re: Spherical projection on I.Reality > > In general we would like to relay for both disotortion correction and blending > on the display system (i.e. we have here two SEOS Prodas with 3 channels and > 155 degrees which perform the blending and the distortion correction). > > In case that the display system can not deal with distortion correction or > blending (like some LCD light valve projectors) then you have to go in a trade > off of distortion correction vs. resolution/n_RMs. > > In cases of blending for LCD projectors the developer/integrator could use a > 2D polymesh frame with source alpha and HIGH quality alpha to make a digital > blending. There is a small overhead of fill rate depending on the area being > fade but ... this is again a developer choice. > > We are not planning any specific support for this blending since we prefer to > relay on integrators. SGI is not an integrator and we will not compete with our > own clients (integrators). Anyway the implementation of this aproach is easy > using libpr or ogl in the draw callback. > > > On Apr 3, 10:30pm, Dennis Pierce wrote: > > Subject: Re: Spherical projection on I.Reality > > > > how are you going to handle the meshing of adjacent images? most high- > > end projectors allow feathering, but this is only at the edge of the > > "normal" horizontal edges - are you going to require planetary projectors, > > or have you folks thought through other clever schemes? > > > > > > -- > > -- > > Dennis Pierce > > SGI / Ste 130 / 900 Winderley PL / Maitland FL 32751 > > > > work : 407.660.0073 > > late : 407.660.2789 > > cell : 407.256.8447 > > vmail: 800.326.1020 x58548 > >-- End of excerpt from Dennis Pierce > > > > -- > ************************************************************************* > * Javier Castellar Arribas * Email: javier@asd.sgi.com * > * * Vmail: 3-1589 * > * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * > * Applied Engineering * Fax: (415)-964-8671 * > * Advanced Systems Division * MailStop: 8L-800 * > ************************************************************************* > * Silicon Graphics Inc. * > * 2011 N. Shoreline Boulevard, * > * Mountain View, California 94043-1386, USA * > ************************************************************************* > "Violence is the last refuge of the incompetant" > Hari Seldon > > >-- End of excerpt from Javier Castellar -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Thu Apr 4 08:20:20 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA10982; Thu, 4 Apr 1996 07:15:10 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA10979; Thu, 4 Apr 1996 07:15:06 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14376; Thu, 4 Apr 96 07:14:57 -0800 Received: from artemis.rus.uni-stuttgart.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA00516; Thu, 4 Apr 1996 07:13:56 -0800 Received: from visin2.rus.uni-stuttgart.de (visin2.rus.uni-stuttgart.de [129.69.29.189]) by artemis.rus.uni-stuttgart.de with ESMTP id RAA13003 (8.6.12/IDA-1.6 for ); Thu, 4 Apr 1996 17:13:50 +0200 Received: by visin2.rus.uni-stuttgart.de (950911.SGI.8.6.12.PATCH825/930416.SGI/BelWue-1.1) for info-performer@sgi.sgi.com id RAA04747; Thu, 4 Apr 1996 17:13:49 +0200 From: "Daniela Rainer" Message-Id: <9604041713.ZM4745@visin2.rus.uni-stuttgart.de> Date: Thu, 4 Apr 1996 17:13:48 +0000 Reply-To: rainer@rus.uni-stuttgart.de X-Mailer: Z-Mail (3.2.1 6apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: PF Warning/SysErr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, please help! What means PF Warning/SysErr: _pfDirtCheck: bad pfObject index 9831109 It happens, if I create a part of the scene graph (dcs - text - string), add it to a group (group - dcs - text - string) later remove the dcs from this group, delete the dcs, and later create and add it again. Thanks for any information. Regards Daniela -- Daniela Rainer rainer@rus.uni-stuttgart.de From guest Thu Apr 4 09:28:54 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA11308; Thu, 4 Apr 1996 09:26:37 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA11305; Thu, 4 Apr 1996 09:26:37 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20762; Thu, 4 Apr 96 09:26:33 -0800 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA16140; Thu, 4 Apr 1996 09:26:29 -0800 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.com id AA20751; Thu, 4 Apr 96 09:26:26 -0800 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA15550; Thu, 4 Apr 1996 09:26:26 -0800 Date: Thu, 4 Apr 1996 09:26:26 -0800 From: mtj@babar (Michael Jones) Message-Id: <199604041726.JAA15550@babar.asd.sgi.com> To: info-performer@sgi.sgi.com, rainer@rus.uni-stuttgart.de Subject: PF Warning/SysErr Status: O Daniela writes: :PF Warning/SysErr: _pfDirtCheck: bad pfObject index 9831109 :It happens, if I create a part of the scene graph (dcs - text - string), add it :to a group (group - dcs - text - string) :later remove the dcs from this group, delete the dcs, and later create and add :it again. Is there any chance that you keep pointers to the text or string objects and try to use them after deleting the dcs? If so, then that's the problem since they will both be deleted by the deletion of the dcs. the answer is simple enough, either pfRef() the text or else detach it from the dcs before deleting the dcs. If this is not the problem, then we'll need more informatio to be able to help you solve your problem. Michael Jones Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Thu Apr 4 09:48:22 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA11390; Thu, 4 Apr 1996 09:45:49 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA11387; Thu, 4 Apr 1996 09:45:48 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21843; Thu, 4 Apr 96 09:45:47 -0800 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA18800; Thu, 4 Apr 1996 09:45:45 -0800 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.com id AA21837; Thu, 4 Apr 96 09:45:42 -0800 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA03896; Thu, 4 Apr 1996 09:45:41 -0800 From: "Javier Castellar" Message-Id: <9604040945.ZM3894@sixty.asd.sgi.com> Date: Thu, 4 Apr 1996 09:45:41 -0800 In-Reply-To: "shadows in performer" (Apr 4, 11:15am) References: <199604040915.LAA04941@chopstix> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: Subject: Re: shadows in performer Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O In performer 2.0 you have a NICE simple example using only the Performer API (no ogl/gl callbacks): /usr/share/Performer/src/pguide/libpf/C/shadows.c ./shadows cow.obj is the way to go -Javier -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon From guest Thu Apr 4 13:51:17 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA11994; Thu, 4 Apr 1996 13:49:07 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA11991; Thu, 4 Apr 1996 13:49:06 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06803; Thu, 4 Apr 96 13:49:05 -0800 Received: from aleve.media.mit.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA19247; Thu, 4 Apr 1996 13:49:04 -0800 Received: from gin.media.mit.edu by aleve.media.mit.edu; (5.65/1.1/06Jun95-8.2MPM) id AA07545; Thu, 4 Apr 1996 16:48:54 -0500 Received: from localhost by gin.media.mit.edu; (5.65v3.2/1.1.8.2/29Feb96-0246PM) id AA30988; Thu, 4 Apr 1996 16:48:52 -0500 Message-Id: <9604042148.AA30988@gin.media.mit.edu> To: rainer@rus.uni-stuttgart.de Cc: info-performer@sgi.sgi.com, dsmall@media.mit.edu Subject: Re: PF Warning/SysErr In-Reply-To: Your message of "Thu, 04 Apr 96 17:13:48 GMT." <9604041713.ZM4745@visin2.rus.uni-stuttgart.de> Date: Thu, 04 Apr 96 16:48:52 -0500 From: David Small X-Mts: smtp Status: O I've had a very similar problem on a very simple program. It simply creates a series of rectangles (dcs -> geode -> gset), each with its own pfMaterial and pfTexEnv. After it makes about 130 of them, it gives me this error: PF Warning/SysErr: _pfDirtCheck: bad pfObject index 2304 PF Warning/SysErr: _pfDirtCheck: bad pfObject index 2304 PF Warning/SysErr: _pfDirtCheck: bad pfObject index 2304 PF Warning/SysErr: _pfDirtCheck: bad pfObject index 2304 over and over again. This problem only occurs on our Onyx/RE2, not on our Indigo^2. Anyone else experience this problem? -David Small MIT Media Lab From guest Thu Apr 4 22:26:33 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id WAA13847; Thu, 4 Apr 1996 22:24:15 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id WAA13844; Thu, 4 Apr 1996 22:24:14 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28375; Thu, 4 Apr 96 22:24:13 -0800 Received: from mcenroe.cs.unc.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA27538; Thu, 4 Apr 1996 22:24:12 -0800 Received: from hatchet.cs.unc.edu by mcenroe.cs.unc.edu (8.6.10/UNC_06_21_94) id BAA09043; Fri, 5 Apr 1996 01:24:10 -0500 Received: from localhost by hatchet.cs.unc.edu (8.6.10/UNC_06_21_94) id CAA02717; Fri, 5 Apr 1996 02:24:09 -0400 Message-Id: <199604050624.CAA02717@hatchet.cs.unc.edu> X-Mailer: exmh version 1.6.5 12/11/95 To: info-performer@sgi.sgi.com Subject: Re: shadows in performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Apr 1996 01:24:08 -0500 From: Gentaro Hirota Status: O Does the InfiniteReality support shadow maps? Are there any features RE supports but iR doesn't? e.g. image processing calls? -- #%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#% Gentaro Hirota UNC Computer Science Department #%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#% From guest Fri Apr 5 06:56:14 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA14644; Fri, 5 Apr 1996 06:32:28 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA14641; Fri, 5 Apr 1996 06:32:20 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07063; Fri, 5 Apr 96 06:32:19 -0800 Received: from alpha.luc.ac.be by deliverator.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id GAA17219; Fri, 5 Apr 1996 06:32:00 -0800 Received: from [193.190.10.11] by alpha.luc.ac.be; (5.65/1.1.8.2/28Jul95-1212AM) id AA18176; Fri, 5 Apr 1996 16:32:09 +0200 Sender: dnouls@luc.ac.be Message-Id: <31652EB0.167E@luc.ac.be> Date: Fri, 05 Apr 1996 16:31:12 +0200 From: David Nouls Organization: L.T.I. - E.D.M. X-Mailer: Mozilla 3.0b2 (X11; I; IRIX 5.3 IP22) Mime-Version: 1.0 To: info-performer@sgi.com Subject: LookAt in Performer ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hello, How can I simulate gluLookAt with Performer calls ? /)avid -- Expertisecentrum Digitale Media - Wetenschapspark 2 - B-3590 Diepenbeek Tel: +32-(0)11-268412 - Fax: +32-(0)11-268400 e-mail: dnouls@luc.ac.be dnouls@cbit.rma.ac.be we39833@vub.ac.be From guest Fri Apr 5 08:31:49 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA14894; Fri, 5 Apr 1996 08:29:37 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA14891; Fri, 5 Apr 1996 08:29:36 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10643; Fri, 5 Apr 96 08:29:35 -0800 Received: from jamaica by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA20709; Fri, 5 Apr 1996 08:29:34 -0800 Received: by jamaica (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.sgi.com id LAA18539; Fri, 5 Apr 1996 11:29:12 -0500 Date: Fri, 5 Apr 1996 11:29:12 -0500 From: murtland@jamaica.mti.sgi.com (Jeff Murtland) Message-Id: <199604051629.LAA18539@jamaica> To: info-performer@sgi.sgi.com Subject: PfiPick path access? Reply-To: murtland@martinique.ndhm.gtegsc.com Status: O Hi, I'm using the PfiPick functions from a C app. I wanted to get the path associated with the pick, so added a C binding for the getPath C++ method. However, the path in the structure is not being used, a local path variable is loaded in _doPick instead. My Questions:::: Is this a known problem? Is it safe for me to change pfiPick.C to load the path in the structure, or are there side effects that I don't see? Thanks, Jeff Murtland -------------------------------------------------------------------- Jeff Murtland Email: murtland@martinique.ndhm.gtegsc.com GTE Government Systems Voice: (617) 455-4806 77 "A" street FAX: (617) 455-5887 Needham MA, 02194 Product Team: Collaborative-3D (C-3D) From guest Fri Apr 5 08:42:00 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA14941; Fri, 5 Apr 1996 08:40:17 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA14938; Fri, 5 Apr 1996 08:40:16 -0800 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11000; Fri, 5 Apr 96 08:40:15 -0800 Received: from sun4nl.NL.net by deliverator.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id IAA27270; Fri, 5 Apr 1996 08:40:14 -0800 Received: from alley.fel.tno.nl by sun4nl.NL.net with SMTP id AA25501 (5.65b/CWI-3.3); Fri, 5 Apr 1996 18:40:12 +0200 Received: from s00sn1.fel.tno.nl (s00sn1 [134.203.8.207]) by alley.fel.tno.nl (8.6.12/8.6.12) with ESMTP id SAA28004 for ; Fri, 5 Apr 1996 18:37:48 +0200 Received: (from rioj7@localhost) by s00sn1.fel.tno.nl (8.7.3/8.7.3) id SAA29502 for info-performer@sgi.com; Fri, 5 Apr 1996 18:38:14 +0200 (MET DST) From: Veraart Message-Id: <199604051638.SAA29502@s00sn1.fel.tno.nl> Subject: Transparency on MaxImpact To: info-performer@sgi.com (performer) Date: Fri, 5 Apr 1996 18:38:14 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Status: O Hello, I have a Performer 2.0 application that visualises a database. The applications runs on a Onyx RE2 and a MaxImpact. On the MaxImpact there is an error visible when there are 2 textured polygons that have a texture with transparency and they both share a region of the screen. The error is when the calculated transparency value of the pixel is between 0.0 and 1.0. Then the Z-buffer value is changed to the value of the polygon that is first drawn. The effect you get is an edge of the background color drawn over an opague part of the polygon that is further away. I have the same effect if I load the database in perfly.ogl. On the RE2 it looks the way it should be. The graphics info of the MaxImpact is: Graphics board 0 is "IMPACT" graphics. Managed (":0.0") 1280x1024 2 GEs, 2 REs, 4 TRAMs, HQ rev A, GE11 rev B, RE4 rev A, PP1 rev A, TE1 rev A MGRAS revision 3, RA revision 5, RB revision 4 VC3 rev A, Cmap rev D, MC rev C Can anybody tell me if this because of the graphics hardware in the MaxImpact or due to Performer 2.0? Mario From guest Fri Apr 5 14:05:54 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA16883; Fri, 5 Apr 1996 14:03:38 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA16880; Fri, 5 Apr 1996 14:03:37 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28666; Fri, 5 Apr 96 14:03:36 -0800 Received: from jeeves.icemt.iastate.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA20470; Fri, 5 Apr 1996 14:03:35 -0800 Received: from helser75.res.iastate.edu (helser75.res.iastate.edu [129.186.76.75]) by jeeves.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) with SMTP id PAA21469 for ; Fri, 5 Apr 1996 15:59:51 -0600 Received: by helser75.res.iastate.edu with Microsoft Mail id <01BB2308.EA6022A0@helser75.res.iastate.edu>; Fri, 5 Apr 1996 15:59:48 -0600 Message-Id: <01BB2308.EA6022A0@helser75.res.iastate.edu> From: Allen Bierbaum To: "'Performer List'" Subject: Findin global vertex coordinates Date: Fri, 5 Apr 1996 15:59:40 -0600 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Status: O Here is my problem, =09 I have a triangle in a geoset. I want to shoot rays out of the center = of the triangle in a hemispherical pattern, in order to see what = polygons the triangle can "see". To do this I find the center of the = triangle and the triangle's normal, and then construct a set of segments = form this information. The problem is that I am intersecting the = segments with the whole scene graph, so since my triangle is below some = DCS's, the center point in the global coordinate system (at the root = node) is different than my value. Because of this, the intersection is = being passed the wrong values. I believe that I need to transform the = segments into the global coordinate system before the intersection. 1. Am I correct in my assessment of the problem??? =20 2. How do I solve this problem??? (I know that I have to find the = transform matrix up to the triangle, but then do I multiply my segments = by that matrix, or it's inverse) =20 3. How do I find this matrix knowing only the geoset the triangle is = in??? (I can guarantee that geosets are not shared) Thanks in advance for any help -Allen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Allen Bierbaum ISU Vislab - ISU CAVE allenb@iastate.edu RA - Carolina Cruz =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From guest Fri Apr 5 16:24:56 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id QAA18033; Fri, 5 Apr 1996 16:22:31 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id QAA18030; Fri, 5 Apr 1996 16:22:30 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08054; Fri, 5 Apr 96 16:22:29 -0800 Received: from voyager1.las.lockheed.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id QAA02559; Fri, 5 Apr 1996 16:22:27 -0800 Received: from esun1.las.lockheed.com by voyager1.las.lockheed.com with SMTP (1.38.193.4/16.2) id AA00533; Fri, 5 Apr 1996 16:30:13 -0800 Received: by esun1.las.lockheed.com (4.1/SMI-4.1) id AA01907; Fri, 5 Apr 96 16:22:00 PST Date: Fri, 5 Apr 96 16:22:00 PST From: meza@esun1.las.lockheed.com (John Meza) Message-Id: <9604060022.AA01907@esun1.las.lockheed.com> To: info-performer@sgi.sgi.com, performer_mail@esun1.las.lockheed.com Subject: Need info Status: O From guest Sat Apr 6 09:20:38 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA19913; Sat, 6 Apr 1996 09:11:21 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA19910; Sat, 6 Apr 1996 09:11:21 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA25943; Sat, 6 Apr 96 09:11:20 -0800 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA12747; Sat, 6 Apr 1996 09:11:18 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA08900; Sat, 6 Apr 1996 18:09:33 +0100 From: "Angus Dorbie" Message-Id: <9604061809.ZM8898@bitch.reading.sgi.com> Date: Sat, 6 Apr 1996 18:09:33 +0100 In-Reply-To: Allen Bierbaum "Findin global vertex coordinates" (Apr 5, 3:59pm) References: <01BB2308.EA6022A0@helser75.res.iastate.edu> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Allen Bierbaum , "'Performer List'" Subject: Re: Findin global vertex coordinates Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 5, 3:59pm, Allen Bierbaum wrote: > Subject: Findin global vertex coordinates > > [ plain text > Encoded with "quoted-printable" ] : Here is my problem, > > I have a triangle in a geoset. I want to shoot rays out of the center of the triangle in a hemispherical pattern, in order to see what polygons the triangle can "see". To do this I find the center of the triangle and the triangle's normal, and then construct a set of segments form this information. The problem is that I am intersecting the segments with the whole scene graph, so since my triangle is below some DCS's, the center point in the global coordinate system (at the root node) is different than my value. Because of this, the intersection is being passed the wrong values. I believe that I need to transform the segments into the global coordinate system before the intersection. > > 1. Am I correct in my assessment of the problem??? I seems so. > 2. How do I solve this problem??? (I know that I have to find the transform matrix up to the triangle, but then do I multiply my segments by that matrix, or it's inverse) Construct the matrix (not the inverse) and call pfXformVec3() to transform the vector to global coordinates. > 3. How do I find this matrix knowing only the geoset the triangle is in??? (I can guarantee that geosets are not shared) pfGetParent() for everything above the geode, but I don't see an easy way of getting a geode from a geoset. How did you get tour hands on the geoset in the first place? Can't you get the Geode? > > Thanks in advance for any help > > -Allen > > ============================== > Allen Bierbaum ISU Vislab - ISU CAVE > allenb@iastate.edu > RA - Carolina Cruz > ============================== > > > >-- End of excerpt from Allen Bierbaum From guest Sat Apr 6 08:39:32 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA19810; Sat, 6 Apr 1996 08:27:48 -0800 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA19807; Sat, 6 Apr 1996 08:27:47 -0800 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA25400; Sat, 6 Apr 96 08:27:46 -0800 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id IAA02660; Sat, 6 Apr 1996 08:27:43 -0800 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id RAA08871; Sat, 6 Apr 1996 17:26:05 +0100 From: "Angus Dorbie" Message-Id: <9604061726.ZM8869@bitch.reading.sgi.com> Date: Sat, 6 Apr 1996 17:26:04 +0100 In-Reply-To: Veraart "Transparency on MaxImpact" (Apr 5, 6:38pm) References: <199604051638.SAA29502@s00sn1.fel.tno.nl> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Veraart , info-performer@sgi.sgi.com (performer) Subject: Re: Transparency on MaxImpact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 5, 6:38pm, Veraart wrote: > Subject: Transparency on MaxImpact > Hello, > > I have a Performer 2.0 application that visualises a database. > The applications runs on a Onyx RE2 and a MaxImpact. > On the MaxImpact there is an error visible when there are 2 textured > polygons that have a texture with transparency and they > both share a region of the screen. The error is when the calculated transparency > value of the pixel is between 0.0 and 1.0. Then the Z-buffer value > is changed to the value of the polygon that is first drawn. > The effect you get is an edge of the background color drawn > over an opague part of the polygon that is further away. This old favourite again :). Well you've just explained what the problem is, this isn't a bug. As you say the first polygon drawn writes to the zbuffer & hides more distant polygons even where the first polygon is transparent. The easiest fix is to use pfAlphaFunc() and pfAlphaRef() calls (or modify the geostates) to cull most of the transparent pixels. The best quality solution is to depth sort all transparent objects in the scene, unless they overlap. > > I have the same effect if I load the database in perfly.ogl. > On the RE2 it looks the way it should be. This is because the RE2 will be using multisample transparency which stores multiple values for z and colour at a blended pixel rather than a single value (like the IMPACT) which cannot hold enough information to resolve a subsequent non-depth-ordered pixel write. > > The graphics info of the MaxImpact is: > Graphics board 0 is "IMPACT" graphics. > Managed (":0.0") 1280x1024 > 2 GEs, 2 REs, 4 TRAMs, > HQ rev A, GE11 rev B, RE4 rev A, PP1 rev A, TE1 rev A > MGRAS revision 3, RA revision 5, RB revision 4 > VC3 rev A, Cmap rev D, MC rev C > > Can anybody tell me if this because of the graphics hardware in the MaxImpact > or due to Performer 2.0? This effect will happen on everything except ONYX & IR when multisampling, it's due to zbuffered rendering with blended transparency. > > Mario > >-- End of excerpt from Veraart Rgds, Angus. -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Sun Apr 7 19:33:55 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id TAA22116; Sun, 7 Apr 1996 19:19:46 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id TAA22113; Sun, 7 Apr 1996 19:19:45 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21595; Sun, 7 Apr 96 19:19:44 -0700 Received: from public.bta.net.cn by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA07741; Sun, 7 Apr 1996 19:19:35 -0700 From: flysiml@public.bta.net.cn Received: (from flysiml@localhost) by public.bta.net.cn (8.6.8.1/8.6.9) id KAA04698; Mon, 8 Apr 1996 10:19:30 +0800 Date: Mon, 8 Apr 1996 10:19:30 +0800 Message-Id: <199604080219.KAA04698@public.bta.net.cn> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Where are these Unresolved? To: info-performer@sgi.sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Hi, I'm making a application with source code of perfly and the MAKE tell me : Warning: Unresolved : glGenTexturesEXT glDeleteTexturesEXT glBindTextureEXT glCopyTexSubImage2DEXT glCopyTexSubImage3DEXT glCopyTexSubImage1DEXT glCopyTexImage1DEXT glCopyTexImage2DEXT glAreTexturesResidentEXT what & where are these ? flysiml@public.bta.net.cn From guest Sun Apr 7 21:27:41 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id VAA22324; Sun, 7 Apr 1996 21:16:14 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id VAA22321; Sun, 7 Apr 1996 21:16:13 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23312; Sun, 7 Apr 96 21:16:12 -0700 Received: from mred.bgm.link.com by deliverator.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id VAA17545; Sun, 7 Apr 1996 21:16:10 -0700 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA12150; Sun, 7 Apr 96 23:15:05 -0500 Date: Sun, 7 Apr 96 23:15:05 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9604080415.AA12150@mred.bgm.link.com> To: info-performer@sgi.com Subject: Magazine Articles. Status: O I noticed an article in the February edition of SunExpert Magazine, page 9/10, it says:- "InfiniteReality can concurrently process geometry, imaging and video data 100 times faster than its prede- cessor, Onyx RealityEngine2, also from SGI." ...well, I know the new box is *FAST* but 100 times as fast?!? So, I put it down to the fact that a "SunExpert" might not also be an SGI Expert - or maybe it was a misprint. Well, imagine my surprise when today someone showed me an article in FLIGHT INTERNATIONAL 3-9th April, page 24 in which it says:- "SGI says that InfiniteReality sys- tems are up to 100 times faster than the Onyx RealityEngine2 machines which they supersede." This seems like too much of a coincidence. The remainder of each article contains information that is not mentioned in the other - so it's unlikely that one journalist copied it from the other. Exactly which operations are 100 times faster? I can think of some that might be 10 times faster... Well, if this is a misprint in some SGI press release, it ought to be corrected *soon*. I have customers out there who read FLIGHT magazine and are going to be wondering why we are charging them so much money for their InfiniteReality-based simulators! Steve Baker 817-323-1361 (Vox-Lab) Hughes Training Inc. 817-695-8776 (Vox-Office/vMail) 2200 Arlington Downs Road 817-695-4028 (Fax) Arlington, Texas. TX 76005-6171 steve@mred.bgm.link.com (eMail) From guest Sun Apr 7 23:07:14 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id WAA22585; Sun, 7 Apr 1996 22:57:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id WAA22582; Sun, 7 Apr 1996 22:57:19 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24727; Sun, 7 Apr 96 22:57:18 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id WAA13540; Sun, 7 Apr 1996 22:57:17 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.com id AA24723; Sun, 7 Apr 96 22:57:14 -0700 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA24131; Sun, 7 Apr 1996 22:57:13 -0700 Date: Sun, 7 Apr 1996 22:57:13 -0700 From: mtj@babar (Michael Jones) Message-Id: <199604080557.WAA24131@babar.asd.sgi.com> To: info-performer@sgi.sgi.com, steve@mred.bgm.link.com Subject: RE: Magazine Articles Status: O The fabled 100x number is a misprint in one of the first-day's press releases. It was corrected that day and was communicated to everyone who the first one was sent to. It has been made as clear as possible since then, and does not appear in any other literature/releases/sales guides/etc. (perhaps we should find some case where it's 100x faster just to answer this question, one obvious case would be drawing >16MB of texture where lack of paging could make such a difference if texture thrashing was avoided). It's clearly 10x at most things, faster than that in a few cases and less than 10x in others. We generally say 4x to 5x the polys for vis sim apps, and 3x to 4x the pixel fill per RM, just to be sure. We see more than 5 million triangles per second in perfly, in IRIS Performer 2.1, so I know that it's fast, but just how much faster would depend on many subtle factors. Also, there is always the possibility of host limitation: if cpu's and busses can't keep up with the faster graphics then the application speedup will not be as much as the potential of the machine. None of this is new news, and the customers we've had into the InifiniteReality porting palace have seen excellent performance in their applications. The biggest caveat is when a huge multi- pipe application is crammed into a single-pipe iR -- you really need to make sure that host limitation does not become a problem for your application. This is how it always is: graphics get faster, then CPUs, then graphics, then CPUs, etc. Michael Jones Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Mon Apr 8 09:17:08 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA23475; Mon, 8 Apr 1996 09:07:29 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA23472; Mon, 8 Apr 1996 09:07:23 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08579; Mon, 8 Apr 96 09:07:22 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id JAA08156; Mon, 8 Apr 1996 09:07:20 -0700 Received: from poster.cae.ca (poster.cae.ca [142.39.22.1]) by bhole with SMTP (DuhMail/2.0) id MAA10460; Mon, 8 Apr 1996 12:04:30 -0400 Received: from osprey.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA10960; Mon, 8 Apr 1996 12:01:37 -0400 Received: by osprey.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id LAA01520; Mon, 8 Apr 1996 11:57:29 -0400 From: "Nicolas Gauvin" Message-Id: <9604081157.ZM1518@osprey.cae.ca> Date: Mon, 8 Apr 1996 11:57:11 -0400 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: dnouls@luc.ac.be Subject: Re: LookAt in Performer Cc: hatch@sgi.sgi.com, info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O David Nouls was saying: > How can I simulate gluLookAt with Performer calls ? You need to compute a pfMatrix containing the correct rotations and translations. Then you set this matrix as the viewing matrix of your pfChannel via the C pfChanSetViewMat or C++ pfChannel::setViewMat call. Here is an implementation of a function that will create this matrix for you: Note that the restriction that the up vector must not be parallel to the viewing direction still holds. /* C version */ void pfMakeLookAtMat( pfMatrix mat, pfVec3 eye, pfVec3 center, pfVec3 up ) { /* row unit vectors representing axis rotations */ pfVec3 x,y,z; /* Y vector points from eye to center */ y[PF_X] = center[PF_X] - eye[PF_X]; y[PF_Y] = center[PF_Y] - eye[PF_Y]; y[PF_Z] = center[PF_Z] - eye[PF_Z]; pfNormalizeVec3(y); /* Z vector is UP */ z[PF_X] = up[PF_X]; z[PF_Y] = up[PF_Y]; z[PF_Z] = up[PF_Z]; /* X vector = Y cross Z */ pfCrossVec3(x, y, z); pfNormalizeVec3(x); /* Recompute Z = X cross Y to make it perpendicular to the others */ pfCrossVec3(z, x, y); pfNormalizeVec3(z); /* create final matrix */ /* first set translation */ pfMakeTransMat(mat,eye[PF_X],eye[PF_Y],eye[PF_Z]); /* then set normalized axis rotation row vectors */ pfSetMatRowVec3(mat,0,x); pfSetMatRowVec3(mat,1,y); pfSetMatRowVec3(mat,2,z); } /* C++ version */ void pfMakeLookAtMat( pfMatrix& mat, pfVec3& eye, pfVec3& center, pfVec3& up ) { // row unit vectors representing axis rotations pfVec3 x,y,z; // Y vector points from eye to center y = center - eye; y.normalize(); // Z vector is UP z = up; // X vector = Y cross Z x.cross(y,z); x.normalize(); // Recompute Z vector = X cross Y to make it perpendicular to the others z.cross(x,y); z.normalize(); // create final matrix // first set translation mat.makeTrans(eye[PF_X],eye[PF_Y],eye[PF_Z]); // then set normalized axis rotation row vectors mat.setRow(0,x); mat.setRow(1,y); mat.setRow(2,z); } For the Performer team: How about adding a similar pfMatrix function in a future Performer release? Something like pfMatrix::makeLookAt would be nice. -- ___/ | ___/ Nicolas Gauvin e-mail: nicolas@cae.ca / / | / Software Developper voice: (514) 341-2000 x2275 / / | __/ CAE Electronics Ltd. fax: (514) 340-5496 / ___ | / 8585 Cote De Liesse, P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Mon Apr 8 09:04:49 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA23394; Mon, 8 Apr 1996 08:54:43 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA23391; Mon, 8 Apr 1996 08:54:43 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03163; Mon, 8 Apr 96 06:24:17 -0700 Received: from public.bta.net.cn by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA27348; Mon, 8 Apr 1996 06:24:11 -0700 From: flysiml@public.bta.net.cn Received: from 202.96.61.108 (ts3-12.bta.net.cn [202.96.61.108]) by public.bta.net.cn (8.6.8.1/8.6.9) with SMTP id VAA06068 for ; Mon, 8 Apr 1996 21:24:06 +0800 Date: Mon, 8 Apr 1996 21:24:06 +0800 Message-Id: <199604081324.VAA06068@public.bta.net.cn> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: How to Inst images? To: info-performer@sgi.sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O I'm a novice on Performer and even poor on GL. Please tell me more details such as what & where are gl_dev , gl_dev.man.gldev. By the way , my system has installed Irix5.3, IDO5.3 and Performer2.0. flysiml@public.bta.net.cn From guest Mon Apr 8 10:27:09 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA23926; Mon, 8 Apr 1996 10:17:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA23923; Mon, 8 Apr 1996 10:17:47 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12757; Mon, 8 Apr 96 10:17:42 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA15999; Mon, 8 Apr 1996 10:17:41 -0700 Received: from popsie.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA16153; Mon, 8 Apr 1996 13:11:46 -0400 Received: by popsie.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.sgi.com id NAA01932; Mon, 8 Apr 1996 13:07:43 -0400 Date: Mon, 8 Apr 1996 13:07:43 -0400 From: madhu@cae.ca (Madhu Sethi) Message-Id: <199604081707.NAA01932@popsie.cae.ca> To: info-performer@sgi.sgi.com Subject: frustum Status: O Hi, I'm having some troubles with generating shadows - I was just wondering if there is a quick way/built in function, to get the outlines, or wire-frame drawing, of the frustum I've created for the shadows. Thanks, Madhu Sethi From guest Mon Apr 8 13:19:43 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA24890; Mon, 8 Apr 1996 13:06:56 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA24887; Mon, 8 Apr 1996 13:06:55 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23446; Mon, 8 Apr 96 13:06:53 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA05517; Mon, 8 Apr 1996 13:06:52 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA13967; Mon, 8 Apr 1996 16:00:29 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id PAA02172; Mon, 8 Apr 1996 15:56:14 -0400 From: "Bernard Leclerc" Message-Id: <9604081556.ZM2170@eagle.cae.ca> Date: Mon, 8 Apr 1996 15:56:09 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Gentaro Hirota Subject: Re: shadows in performer Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Gentaro, John Rolf from SGI sent me the following concerning shadows on Infinite Reality. One question remains: Is this comment still valid considering the soon-to-come release of Irix 6.2 and Performer 2.1? --- Forwarded mail from jrohlf@tubes.asd.sgi.com (John Rohlf) From: jrohlf@tubes.asd.sgi.com (John Rohlf) Subject: Re: Performer 2.0 on InfiniteReality To: guest@holodeck.asd.sgi.com (Bernard Leclerc) Date: Thu, 15 Feb 96 10:03:18 PST Cc: info-performer@sgi.sgi.com > > Question for the pfDeveloppers: > > Has Performer 2.0 been modified to take full advantage of the new > InfiniteReality OpenGL-based Hardware? > > We're looking into replacing 2 RealityEngine2 with 2 InfiniteReality since we > need the increased performance of the new graphics card right now. However, > that kind of change has a side effect since the RE2 is IrisGL-based while the > InfiniteReality is OpenGL-based. > > Specifically, Performer 2.0 comes with a sample program (shadows.C) that > compiles and works only with IrisGL. Does it mean that shadows are not > available with OpenGL and the InfiniteReality? I can't believe that. There must > be a fix. Performer 2.0 does not yet take full advantage of the new InfiniteReality OpenGL-based Hardware since some OpenGL extensions which access the hardware have not yet been implemented. The shadow extension has not been implemented yet and even if it makes it for the InfiniteReality release, 2.0 will not be able to use it. ---End of forwarded mail from jrohlf@tubes.asd.sgi.com (John Rohlf) -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Mon Apr 8 15:59:55 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA25999; Mon, 8 Apr 1996 15:50:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA25996; Mon, 8 Apr 1996 15:50:43 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03400; Mon, 8 Apr 96 15:50:42 -0700 Received: from westside.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA22872; Mon, 8 Apr 1996 15:50:41 -0700 Received: by westside.corp.sgi.com (940816.SGI.8.6.9/930416.SGI) for info-performer@sgi.sgi.com id PAA21601; Mon, 8 Apr 1996 15:50:04 -0700 From: "Julia Kossack" Message-Id: <9604081550.ZM21599@westside.corp.sgi.com> Date: Mon, 8 Apr 1996 15:50:04 -0700 X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: terrain paging Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hello Performer team, Larry McDonough referred me to you regarding this question we received on the Fastline: "Does performer 2.0 support Terrain Paging? Do you have a pointer for a website that talks about Color Imaging?" I don't have any further details of what the rep is looking for; I assume he is referring to Color Imaging in Performer, but if that doesn't make sense, please let me know. Meantime, thanks in advance for your help with the terrain paging issue. -Julia -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Julia Kossack Telephone: (415) 933-5899 Sales Development Fax: (415) 965-1395 Silicon Graphics, Inc. E-mail: jkossack@corp.sgi.com 2011 N. Shoreline Blvd. MS 24U-913 SEE THE SILICON GRAPHICS HOME PAGE: Mountain View, CA 94043-1389 http://www.sgi.com From guest Mon Apr 8 16:39:40 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id QAA26286; Mon, 8 Apr 1996 16:31:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id QAA26283; Mon, 8 Apr 1996 16:31:09 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05536; Mon, 8 Apr 96 16:31:08 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id QAA27197; Mon, 8 Apr 1996 16:31:07 -0700 Received: from kid.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA05532; Mon, 8 Apr 96 16:31:04 -0700 Received: from localhost by kid.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) id QAA06042; Mon, 8 Apr 1996 16:31:03 -0700 Message-Id: <199604082331.QAA06042@kid.asd.sgi.com> To: flysiml@public.bta.net.cn Cc: info-performer@sgi.sgi.com Subject: Re: Where are these Unresolved? In-Reply-To: Your message of "Mon, 08 Apr 96 10:19:30 +0800." <199604080219.KAA04698@public.bta.net.cn> Date: Mon, 08 Apr 96 16:31:03 -0700 From: Simon Hui Status: O Those are defined in the opengl library, /usr/lib/libGL.so. However, they are part of extensions to opengl; you need IRIX 5.3 with either patch 154 or 918, or IRIX 6.2 in order to have these extensions. > From: flysiml@public.bta.net.cn > Subject: Where are these Unresolved? > > I'm making a application with source code of perfly > and the MAKE tell me : > > Warning: Unresolved : > glGenTexturesEXT > glDeleteTexturesEXT > glBindTextureEXT > glCopyTexSubImage2DEXT > glCopyTexSubImage3DEXT > glCopyTexSubImage1DEXT > glCopyTexImage1DEXT > glCopyTexImage2DEXT > glAreTexturesResidentEXT From guest Mon Apr 8 17:13:05 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id QAA26504; Mon, 8 Apr 1996 16:59:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id QAA26501; Mon, 8 Apr 1996 16:59:24 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06967; Mon, 8 Apr 96 16:59:23 -0700 Received: from electrogig.com by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id QAA17056; Mon, 8 Apr 1996 16:59:19 -0700 Received: from tracey.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id QAA23064; Mon, 8 Apr 1996 16:59:06 -0700 Received: by tracey.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id RAA27542; Mon, 8 Apr 1996 17:00:28 -0700 From: "Anita Kishore" Message-Id: <9604081700.ZM27540@tracey.electrogig.com> Date: Mon, 8 Apr 1996 17:00:27 -0700 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com Subject: image memory for pfTexture Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I want to change a texture's image during run time. I do this by using pfLoadTexFile(tex, fileName). But I don't know if I need to first free the memeory of the previous image, or if this is being done by pfLoadTexFile. Does anyone know about it? Thanks a lot -anita -------------------------------------------------------------------- Anita Kishore kishore@electrogig.com -------------------------------------------------------------------- From guest Mon Apr 8 20:12:19 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id TAA27432; Mon, 8 Apr 1996 19:59:29 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id TAA27429; Mon, 8 Apr 1996 19:59:29 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15896; Mon, 8 Apr 96 19:59:27 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA13494; Mon, 8 Apr 1996 19:59:26 -0700 Received: from sol.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA10347; Mon, 8 Apr 1996 22:52:00 -0400 Received: by sol.cae.ca (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.sgi.com id WAA01057; Mon, 8 Apr 1996 22:52:29 -0400 From: "Richar Pitre" Message-Id: <9604082252.ZM1053@sol.cae.ca> Date: Mon, 8 Apr 1996 22:52:27 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: perfly behavior Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19604082252.ZM1053.cae.ca" Status: O -- --PART-BOUNDARY=.19604082252.ZM1053.cae.ca Content-Type: text/plain; charset=us-ascii I have been trying to display colored quad using the material associated with the graphic state (Onyx RealityEngine 2, Performer 2.0, openGL). I have created this simple example which is loaded and displayed by perfly pfMaterial *m1 = new pfMaterial; pfMaterial *m2 = new pfMaterial; pfGeoSet *p1 = new pfGeoSet; pfGeoSet *p2 = new pfGeoSet; pfGeoState *gs1 = new pfGeoState; pfGeoState *gs2 = new pfGeoState; pfVec3 *coord1 = new pfVec3[4]; pfVec3 *coord2 = new pfVec3[4]; pfGeode *node = new pfGeode; // First quad coord1[0].set(0.0f,0.0f,0.0f); coord1[1].set(1.0f,0.0f,0.0f); coord1[2].set(1.0f,0.0f,1.0f); coord1[3].set(0.0f,0.0f,1.0f); p1->setPrimType(PFGS_QUADS); p1 ->setNumPrims(1); p1->setAttr(PFGS_COORD3,PFGS_PER_VERTEX,coord1,0); p1->setGState(gs1); // Second quad coord2[0].set(2.0f,0.0f,0.0f); coord2[1].set(3.0f,0.0f,0.0f); coord2[2].set(3.0f,0.0f,1.0f); coord2[3].set(2.0f,0.0f,1.0f); p2->setPrimType(PFGS_QUADS); p2 ->setNumPrims(1); p2->setAttr(PFGS_COORD3,PFGS_PER_VERTEX,coord2,0); p2->setGState(gs2); // First quad color: red m1->setColor(PFMTL_DIFFUSE, 1.0f, 0.0f, 0.0f); // Second quad colour: green m2->setColor(PFMTL_DIFFUSE, 0.0f, 1.0f, 0.0f); // Use material colour m1->setColorMode(PFMTL_FRONT,PFMTL_CMODE_OFF); m2->setColorMode(PFMTL_FRONT,PFMTL_CMODE_OFF); gs1->setAttr(PFSTATE_FRONTMTL,m1); gs2->setAttr(PFSTATE_FRONTMTL,m2); node->addGSet(p1); node->addGSet(p2); return node; Both quad come out white colored. The manual specifies that by setting the color mode to PFMTL_CMODE_OFF the colour as specifyed by the material will be used. If I don't use this setting then both quads are red( the first colour encountered). Is there something specific that perfly do to disable this option ? Light points (using pfLPointState) do not work properly in Filled style mode, it looks like the geometry is not recognize as being light points. It work ok in all other style( except scribbed). How to fix ?? Thanks -- Richard Pitre CAE Electonics Ltd. C.P. 1800, Saint-Laurent Quebec, Canada H4L 4X4 Tel: (514) 341-6780 ext 3603 Fax: (514) 340-5496 Email: pitre@cae.ca --PART-BOUNDARY=.19604082252.ZM1053.cae.ca Content-Description: Transferred from mail from ("Richar Pitre"): Text Content-Type: text/plain ; charset=iso-8859-1 ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u Bonjour, Je travaille =E0 la conversion des bases de donn=E9es MAXVUE =E0 Perform= er. J'ai pu faire toute la g=E9ometrie, la texture, les LOD, etc ... Mais il = y un petit probl=E8me que je n'arrive pas =E0 r=E9soudre. Comment afficher diff=E9rentes couleurs sur diff=E9rents polygon= en utilisant la couleur du mat=E9riel associ=E9 au geoset.Voici un petit exe= mple que j'ai essay=E9 pfMaterial *m1 =3D new pfMaterial; pfMaterial *m2 =3D new pfMaterial; pfGeoSet *p1 =3D new pfGeoSet; pfGeoSet *p2 =3D new pfGeoSet; pfGeoState *gs1 =3D new pfGeoState; pfGeoState *gs2 =3D new pfGeoState; pfVec3 *coord1 =3D new pfVec3[4]; pfVec3 *coord2 =3D new pfVec3[4]; pfGeode *node =3D new pfGeode; // First quad coord1[0].set(0.0f,0.0f,0.0f); coord1[1].set(1.0f,0.0f,0.0f); coord1[2].set(1.0f,0.0f,1.0f); coord1[3].set(0.0f,0.0f,1.0f); p1->setPrimType(PFGS_QUADS); p1 ->setNumPrims(1); p1->setAttr(PFGS_COORD3,PFGS_PER_VERTEX,coord1,0); p1->setGState(gs1); // Second quad coord2[0].set(2.0f,0.0f,0.0f); coord2[1].set(3.0f,0.0f,0.0f); coord2[2].set(3.0f,0.0f,1.0f); coord2[3].set(2.0f,0.0f,1.0f); p2->setPrimType(PFGS_QUADS); p2 ->setNumPrims(1); p2->setAttr(PFGS_COORD3,PFGS_PER_VERTEX,coord2,0); p2->setGState(gs2); // First quad color: red m1->setColor(PFMTL_DIFFUSE, 1.0f, 0.0f, 0.0f); // Second quad colour: green m2->setColor(PFMTL_DIFFUSE, 0.0f, 1.0f, 0.0f); // Use material colour m1->setColorMode(PFMTL_FRONT,PFMTL_CMODE_OFF); m2->setColorMode(PFMTL_FRONT,PFMTL_CMODE_OFF); gs1->setAttr(PFSTATE_FRONTMTL,m1); gs2->setAttr(PFSTATE_FRONTMTL,m2); node->addGSet(p1); node->addGSet(p2); return node; D'apr=E8s le manuel, m2->setColorMode(PFMTL_FRONT,PFMTL_CMODE_OFF) devrait forcer l'utilisation de la couleur tel que d=E9crite dans le mat=E9riel m= ais j'obtiens deux polygons de m=EAme couleur blanche. Si j'enl=E8ve cette co= mmande j'obtiens deux polygons de couleurs rouges( le premier mat=E9riel rencont= r=E9). Salut -- = Richard Pitre CAE Electonics Ltd. C.P. 1800, Saint-Laurent Quebec, Canada H4L 4X4 Tel: (514) 341-6780 ext 3603 Fax: (514) 340-5496 Email: pitre@cae.ca --PART-BOUNDARY=.19604082252.ZM1053.cae.ca-- From guest Mon Apr 8 20:12:21 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id UAA27442; Mon, 8 Apr 1996 20:00:39 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id UAA27439; Mon, 8 Apr 1996 20:00:39 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15972; Mon, 8 Apr 96 20:00:36 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA13578; Mon, 8 Apr 1996 20:00:35 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.com id AA15967; Mon, 8 Apr 96 20:00:33 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id UAA04986; Mon, 8 Apr 1996 20:00:32 -0700 From: "Sharon Clay" Message-Id: <9604082000.ZM4984@rose.asd.sgi.com> Date: Mon, 8 Apr 1996 20:00:32 -0700 In-Reply-To: "Anita Kishore" "image memory for pfTexture" (Apr 8, 5:00pm) References: <9604081700.ZM27540@tracey.electrogig.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Anita Kishore" , info-performer@sgi.sgi.com Subject: Re: image memory for pfTexture Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 8, 5:00pm, Anita Kishore wrote: > Subject: image memory for pfTexture ->I want to change a texture's image during run time. I do this by using ->pfLoadTexFile(tex, fileName). But I don't know if I need to first free ->the memeory of the previous image, or if this is being done by pfLoadTexFile. -> ->Does anyone know about it? We only free the texture image data if you have called pfFreeTexImage() _before_ the texture was formatted for the GL. In this case, the image pointer gets a pfUnrefDelete() after the texture is formatted and the GL copy has been created. The texture image pointer will then be changed to NULL. If this was not done and and a new texture image is assigned, we simply pfUnref() the old texture image pointer before replacing it with the new one. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Mon Apr 8 22:14:17 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id WAA28408; Mon, 8 Apr 1996 22:01:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id WAA28405; Mon, 8 Apr 1996 22:01:34 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19138; Mon, 8 Apr 96 22:01:33 -0700 Received: from scctn01.sp.ac.sg by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA19252; Mon, 8 Apr 1996 22:01:23 -0700 Received: from sspws500.sp.ac.sg (sspws500.sp.ac.sg [164.78.252.5]) by scctn01.sp.ac.sg (8.6.12/8.6.9) with SMTP id NAA14798 for <@scctn01:info-performer@sgi.sgi.com>; Tue, 9 Apr 1996 13:02:34 +0730 Received: by sspws500.sp.ac.sg (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA6995; Tue, 09 Apr 96 13:04:03 -0700 Message-Id: <9604092004.AA6995@sspws500.sp.ac.sg> Received: from SP_SD with "Lotus Notes Mail Gateway for SMTP" id 85F3E54158679E3D48256307001B037E; Tue, 9 Apr 96 13:04:02 To: info-performer From: Tan Ai Lian/JS/SP_SF Date: 9 Apr 96 12:55:47 WAT Subject: Unsubscribe Mime-Version: 1.0 Content-Type: Text/Plain Status: O Unsubscribe me please. Thanks. From guest Tue Apr 9 03:05:24 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA28928; Tue, 9 Apr 1996 02:53:55 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA28925; Tue, 9 Apr 1996 02:53:55 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26640; Tue, 9 Apr 96 02:53:53 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA00912; Tue, 9 Apr 1996 02:53:52 -0700 Received: from bitch.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for id BAA21296; Tue, 9 Apr 1996 01:39:27 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA14497; Tue, 9 Apr 1996 09:34:29 +0100 From: "Angus Dorbie" Message-Id: <9604090934.ZM14495@bitch.reading.sgi.com> Date: Tue, 9 Apr 1996 09:34:28 +0100 In-Reply-To: "Julia Kossack" "terrain paging" (Apr 8, 3:50pm) References: <9604081550.ZM21599@westside.corp.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Julia Kossack" , info-performer@sgi.sgi.com Subject: Re: terrain paging Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O It sounds like you are asking about Clip Mapping rather than database paging but either or both may be required depending on the "Terrain Paging" application. Performer 2.0 supports database paging, you can use another process to load portions of scene graph and merge them with your application later. There's also a fast file format & loader which is not in the release. Performer 2.1 supports Clip Mapping, the texture paging for large area geospecific terrain images on Infinite Reality. Rgds, Angus. On Apr 8, 3:50pm, Julia Kossack wrote: > Subject: terrain paging > Hello Performer team, > > Larry McDonough referred me to you regarding this question we received on the > Fastline: > > "Does performer 2.0 support Terrain Paging? > Do you have a pointer for a website that talks about Color Imaging?" > > I don't have any further details of what the rep is looking for; I assume he is > referring to Color Imaging in Performer, but if that doesn't make sense, please > let me know. > > Meantime, thanks in advance for your help with the terrain paging issue. > > -Julia > > > > -- > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Julia Kossack Telephone: (415) 933-5899 > Sales Development Fax: (415) 965-1395 > Silicon Graphics, Inc. E-mail: jkossack@corp.sgi.com > 2011 N. Shoreline Blvd. > MS 24U-913 SEE THE SILICON GRAPHICS HOME PAGE: > Mountain View, CA 94043-1389 http://www.sgi.com > > >-- End of excerpt from Julia Kossack -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Tue Apr 9 11:04:40 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA29536; Tue, 9 Apr 1996 10:46:29 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA29533; Tue, 9 Apr 1996 10:46:28 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09388; Tue, 9 Apr 96 10:46:26 -0700 Received: from Styx.deneb.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA03698; Tue, 9 Apr 1996 10:46:09 -0700 Received: from deneb.com (uucp@localhost) by Styx.deneb.com (8.6.12/Merit) with UUCP id NAA08208 for info-performer@sgi.sgi.com; Tue, 9 Apr 1996 13:12:56 -0400 Received: from bizzaro by Stones (16.6/3.2.083191-Deneb Robotics) id AA11654; Tue, 9 Apr 96 12:11:34 -0400 Sender: kuehne@deneb.com Message-Id: <316A8C46.41C6@deneb.com> Date: Tue, 09 Apr 1996 12:11:50 -0400 From: Robert Kuehne Organization: Deneb Robotics, Inc. X-Mailer: Mozilla 2.0 (X11; I; IRIX 5.3 IP22) Mime-Version: 1.0 To: info-performer@sgi.sgi.com Subject: Problems sproc-ing a pf process... Content-Type: multipart/mixed; boundary="------------167E2781446B" Status: O This is a multi-part message in MIME format. --------------167E2781446B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm having difficulties attempting to repeatedly launch Performer on a sproc. My basic goal is this: o have the parent application have the ability to launch/destroy a performer process at will. Only one pf process will be active at any given time. The problem I'm running into is that although the first sproc works great, subsequent sprocs do not, complaining that: PF Warning/Usage(2): pfInit() Already initialized. Must call pfExit() before reinitialization. PF Warning/Usage: pfMultiprocess() Must call before pfConfig. PF Warning/Usage: pfConfig() Cannot config more than once. and later, when attempting to launch a window: X Error of failed request: BadAccess I have attached a small (1k) chunk of sample code which illustrates this problem. If anyone has any clues/ideas, I would be very appreciative of any help... Thanks! Bob -- Robert P. Kuehne | | _ o kuehne@deneb.com | There was coffee. Life would go on. | _ \<,_ Ph: 810.377.6900 | - William Gibson, The Winter Market - | (_)/ (_) --------------167E2781446B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="main.c++" /* Compile with: /usr/bin/CC -o go main.c++ -nostdlib -L/lib -L/usr/lib \ -L/usr/lib/Performer/Debug -lpf_ogl -lpfdu_ogl -lpfui \ -lpfutil_ogl -lmpc -limage -lGLw -lGLU -lGL -lXext -lfpe \ -lXmu -lX11 -lm -lmalloc -lC */ #include #include #include #include #include #include void pfdemo( void * ) { cerr << "- beginning pf process" << endl; pfNotifyLevel( 7 ); pfInit(); pfMultiprocess( PFMP_DEFAULT ); pfConfig(); pfPipe *pipe = pfGetPipe(0); pfPipeWindow *pw = new pfPipeWindow( pipe ); pw->setName("Test"); pw->setWinType(PFWIN_TYPE_X); pw->setMode( PFWIN_NOBORDER, PF_ON ); pw->setOriginSize(0, 0, 100, 60); pw->open(); for ( int ii=0; ii<5; ii++ ) { pfSync(); pfFrame(); } pw->close(); cerr << "- ending pf process" << endl; pfExit(); } void main() { _uerror = _utrace = 1; for ( int ii=0; ii<3; ii++ ) { cerr << "o--" << endl; cerr << "Process #: " << sproc ( pfdemo, PR_SALL, (void*)NULL ) << endl; sleep( 1 ); cerr << "--o" << endl; } } --------------167E2781446B-- From guest Tue Apr 9 13:41:54 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA00488; Tue, 9 Apr 1996 13:31:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA00485; Tue, 9 Apr 1996 13:31:50 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18862; Tue, 9 Apr 96 13:31:49 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA21330; Tue, 9 Apr 1996 13:31:47 -0700 Received: from poster.cae.ca (poster.cae.ca [142.39.22.1]) by bhole with SMTP (DuhMail/2.0) id QAA10645; Tue, 9 Apr 1996 16:26:26 -0400 Received: from osprey.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA07947; Tue, 9 Apr 1996 16:23:47 -0400 Received: by osprey.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id QAA04571; Tue, 9 Apr 1996 16:17:58 -0400 Date: Tue, 9 Apr 1996 16:17:58 -0400 From: nicolas@cae.ca (Nicolas Gauvin) Message-Id: <199604092017.QAA04571@osprey.cae.ca> To: info-performer@sgi.sgi.com Subject: Re: Problems sproc-ing a pf process Status: O Trying to sproc many Performer processes will never work. Try forking them instead so they do not share the same virtual address space. ___/ | ___/ Nicolas Gauvin e-mail: nicolas@cae.ca / / | / Software Developper voice: (514) 341-2000 x2275 / / | __/ CAE Electronics Ltd. fax: (514) 340-5496 / ___ | / 8585 Cote De Liesse, P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Tue Apr 9 13:49:45 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA00526; Tue, 9 Apr 1996 13:41:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA00523; Tue, 9 Apr 1996 13:41:49 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19211; Tue, 9 Apr 96 13:41:48 -0700 Received: from huey.ntsc.navy.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA22077; Tue, 9 Apr 1996 13:41:25 -0700 From: william_marinelli@ntsc.navy.mil Received: from CCMAIL.NTSC.NAVY.MIL ([192.44.253.30]) by huey.ntsc.navy.mil (4.1/SMI-4.1) id AA23753; Tue, 9 Apr 96 16:13:41 EDT Received: from ccMail by CCMAIL.NTSC.NAVY.MIL (SMTPLINK V2.11) id AA829092115; Tue, 09 Apr 96 16:18:39 EST Date: Tue, 09 Apr 96 16:18:39 EST Message-Id: <9603098290.AA829092115@CCMAIL.NTSC.NAVY.MIL> To: info-performer@sgi.sgi.com Subject: Re[2]: terrain paging Status: O Be interesting if we could page in individual levels of detail of terrain. Example: If the terrain is represnted with three lods, and we page it in because the ownship is sufficiently close to that tile. When that terrain first comes into view, only the lowest lod is visible. If the ownship continues, then the higher lods will be blended in. But what if the ownship does a hard right when it's far enough away that only the lowest lod could have possibly been visible? All that bandwidth would have ben wasted on the higher lods which would now have to be discarded. Any thoughts about the ability of paging in individual terrain lods when appropriate? I apologize for the ignorance if this is already included in performer and I'm simply clueless. From guest Tue Apr 9 14:21:09 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA00893; Tue, 9 Apr 1996 14:12:14 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA00890; Tue, 9 Apr 1996 14:12:13 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21284; Tue, 9 Apr 96 14:12:09 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA27256; Tue, 9 Apr 1996 14:12:07 -0700 Received: from pxp.stlaurent.sgi.com by sgihub.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for id MAA29602; Tue, 9 Apr 1996 12:35:12 -0700 Received: by pxp.stlaurent.sgi.com (950413.SGI.8.6.12/911001.SGI) for info-performer@sgi.sgi.com id PAA19824; Tue, 9 Apr 1996 15:33:52 -0400 From: "parviz" Message-Id: <9604091533.ZM19822@pxp.stlaurent.sgi.com> Date: Tue, 9 Apr 1996 15:33:51 -0400 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.sgi.com Subject: (Fwd) Problems with OpenGL conversion of distortion correction program Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O One of our Customer has the following problem with converting distortion correction program to OpenGl, any ideas?? "I modified the distortion correction demo program "hemisphere.c" that I found on sgigate.sgi.com in the distribution file /pub/Performer/RealityCentre/distort.tar.Z. The modification works fine under IrisGL. I then attempted to convert the modified program to OpenGL without much success; none of the OpenGL commands seem to draw anything. Could you ask one of your Performer/OpenGL gurus to have a look at the program please? I've attached copies of both the IrisGL and OpenGL versions of the program. Running the programs requires the .flt-format models and textures found in the distributon file. Thanks PS - can I copy the frame buffer into a 1024x1280 texture map? I'm not sure what the restrictions on texture map size are. ----- IrisGL version (hemisphere.c) ----- #include #include #include #include #include /* for cmdline handler */ #include #include #include #include "pfutil.h" #include "pfflt.h" #include "gl.h" static void CullChannel(pfChannel *, void *); static void DrawChannel(pfChannel *, void *); static void OpenPipeline(int, uint); static void UpdateView(void); static void GetGLInput(void); static void drawDistort(void); /* * structure that resides in shared memory so that the * application, cull, and draw processes can access it. */ typedef struct { long exitFlag; pfCoord view; float sceneSize; int drawStats; pfChannel *chan; } SharedData; static SharedData *Shared; /* light source created and updated in draw-process */ static pfLight *Sun; /* for configuring multi-process */ static long ProcSplit = PFMP_APPCULLDRAW; /* write out scene upon read-in - uses pfDebugPrint */ static long WriteScene = 0; /* * docmdline() -- use getopt to get command-line arguments, * executed at the start of the application process. */ static long docmdline(int argc, char *argv[]) { long opt; /* process command-line arguments */ while ((opt = getopt(argc, argv, "wp:?")) != -1) { switch (opt) { case 'w': WriteScene = 1; break; case 'p': ProcSplit = atoi(optarg); break; } } return optind; } /* * main() -- program entry point. this procedure * is executed in the application process. */ int main (int argc, char *argv[]) { int arg; int found; int i; pfNode *root; pfScene *scene; pfPipe *p; pfEarthSky *eSky; pfBox bbox; float far = 40000.0f; pfVec3 xyz, hpr; pfPipeWindow* pw; arg = docmdline(argc, argv); pfInit(); /* configure multi-process selection */ pfMultiprocess(ProcSplit); /* allocate shared before fork()'ing parallel processes */ Shared = (SharedData*)pfMalloc(sizeof(SharedData), pfGetSharedArena()); Shared->exitFlag = 0; Shared->drawStats = 0; /* initiate multi-processing mode set in pfMultiprocess call */ pfConfig(); scene = pfNewScene(); /* specify directories where geometry and textures exist */ if (!(getenv("PFPATH"))) pfFilePath("."); /* load files named by command line arguments */ for (found = 0; arg < argc; arg++) { if ((root = pfdLoadFile(argv[arg])) != NULL) { pfAddChild(scene, root); found++; } } /* if no files successfully loaded, terminate program */ if (!found) exit(0); p = pfGetPipe(0); pfPhase(PFPHASE_FREE_RUN); /* Open and configure full screen GL window. */ pw = pfNewPWin(pfGetPipe(0)); /* pfPWinOriginSize(pw,0,0,511,511); */ pfPWinOriginSize(pw,0,0,1024,1024); pfPWinName(pw,"IRIS Performer"); pfOpenPWin(pw); pfStageConfigFunc( -1, PFPROC_DRAW, OpenPipeline ); pfConfigStage( -1, PFPROC_DRAW ); pfFrame(); pfFrameRate(30.0f); Shared->chan = pfNewChan(p); pfChanTravFunc(Shared->chan, PFTRAV_CULL, CullChannel ); pfChanTravFunc(Shared->chan, PFTRAV_DRAW, DrawChannel ); pfChanScene(Shared->chan, scene); pfChanNearFar(Shared->chan, 0.1f, far); /* window(-2.5, 2.5, -1.05, 1.05, 1.0, 100.0);*/ pfChanFOV(Shared->chan, 136.0f, 92.5f); /* 512 x 512 */ pfChanViewport( Shared->chan, 0.0, 1.0, 0.000, 1.0 ); /* 256 x 256 pfChanViewport( Shared->chan, 0.0, .5, 0.000, 0.5 ); */ pfSetVec3(xyz, 0.0f, 0.0f, 0.0f); pfSetVec3(hpr, 0.0f, 45.0f, 0.0f); pfChanViewOffsets(Shared->chan, xyz, hpr); /* Create an earth/sky model that draws sky/ground/horizon */ eSky = pfNewESky(); pfESkyMode(eSky, PFES_BUFFER_CLEAR, PFES_FAST); pfChanESky(Shared->chan, eSky); pfChanLODAttr( Shared->chan, PFLOD_SCALE, 0.125 ); /* main simulation loop */ while (!Shared->exitFlag) { /* wait until next frame boundary */ pfSync(); /* Set view parameters. */ UpdateView(); pfChanView(Shared->chan, Shared->view.xyz, Shared->view.hpr); /* initiate traversal using current state */ pfFrame(); } /* terminate cull and draw processes (if they exist) */ pfExit(); /* exit to operating system */ exit(0); } /* * UpdateView() updates the eyepoint based on the information * placed in shared memory by GetGLInput(). */ static void UpdateView(void) { static float speed = 0.0f; pfCoord *view = &Shared->view; /* update view direction */ view->hpr[PF_H] = 0.0; view->hpr[PF_P] ++; /*= 0.0;*/ view->hpr[PF_R] = 0.0; /* update view position */ view->xyz[PF_X] = 0.0; view->xyz[PF_Y] = 0.0; view->xyz[PF_Z] = 50.0; /* view->xyz[PF_X] = 15023; view->xyz[PF_Y] = -7199.4; view->xyz[PF_Z] = -204.7 + 1000; */ } /* * OpenPipeline() -- create a pipeline: setup the window system, * the IRIS GL, and IRIS Performer. this procedure is executed in * the draw process (when there is a separate draw process). */ static void OpenPipeline(int pipe, uint stage ) { float xSize = 800; float ySize = 500; /* register events of note with event-queue manager */ qdevice(ESCKEY); qdevice(F1KEY); /* negotiate with GL */ gconfig(); /* create a light source in the "south-west" (QIII) */ Sun = pfNewLight(NULL); pfLightPos(Sun, -0.3f, -0.3f, 1.0f, 0.0f); /* create a default texture environment */ pfApplyTEnv(pfNewTEnv(NULL)); /* create a default lighting model */ pfApplyLModel(pfNewLModel(NULL)); pfApplyMtl(pfNewMtl(NULL)); /* enable culling of back-facing polygons */ pfCullFace(PFCF_BACK); /* * These enables should be set to reflect the majority of the * database. If most geometry is not textured, then texture * should be disabled. However, you then need to change the * FLIGHT-format file reader. (pfflt.c) */ pfEnable(PFEN_TEXTURE); pfDisable(PFEN_WIREFRAME); pfDisable(PFEN_LIGHTING); pfDisable(PFEN_FOG); } /* * CullChannel() -- traverse the scene graph and generate a * display list for the draw process. This procedure is * executed in the cull process. */ static void CullChannel(pfChannel *channel, void *data) { pfCull(); } static void DrawChannel (pfChannel *channel, void *data) { /* rebind light so it stays fixed in position */ pfLightOn(Sun); /* erase framebuffer and draw Earth-Sky model */ pfClearChan(channel); /* invoke Performer draw-processing for this frame */ pfDraw(); /* draw Performer throughput statistics */ if (Shared->drawStats) pfDrawChanStats(channel); GetGLInput(); drawDistort(); } static void GetGLInput(void) { while (qtest()) { short value; long device = qread(&value); /* only act on key-down transitions */ if (value) { switch (device) { /* ESC-key signals end of simulation */ case ESCKEY: Shared->exitFlag = 1; break; /* F1-key toggles channel-stats display */ case F1KEY: Shared->drawStats = !Shared->drawStats; break; } } } } #include "newuvarray.h" float texprops[] = { TX_MAGFILTER, TX_BILINEAR, TX_MINFILTER, TX_BILINEAR, TX_WRAP, TX_REPEAT, TX_INTERNAL_FORMAT, TX_RGB_5, TX_FAST_DEFINE, TX_NULL}; Matrix ident = { 1.,0.,0.,0., 0.,1.,0.,0., 0.,0.,1.,0., 0.,0.,0.,1.}; static void drawDistort(void) { static unsigned long map[1024 * 1024], flags; static int first = 1; int i, j; float vert[2]; float tvert[2]; if(first) { texdef2d(1024, 3, 1024, 1024, map, 10, texprops); first = 0; } viewport( 0, 1023, 0 , 1023); texbind(TX_TEXTURE_0, 1024); fbsubtexload(0, 0, TX_TEXTURE_0, 1024, 0.0, 1.0, 0.0, 1.0, flags); ortho2(0.0, 16.0, 0.0, 16.0); loadmatrix(ident); zbuffer(0); backface(0); cpack(0xffffffff); for( i = 0; i < 16; i++) /* sixteen tmesh strips */ { float yup, ydown; int tindexup, tindexdown; ydown = (float) (i); yup = (float) (i + 1); tindexdown = i * 17; tindexup = (i + 1) * 17; bgntmesh(); tvert[0] = uvarray[tindexdown][0]; tvert[1] = uvarray[tindexdown][1]; t2f (tvert); vert[0] = 0.0; vert[1] = ydown; v2f (vert); tvert[0] = uvarray[tindexup][0]; tvert[1] = uvarray[tindexup][1]; t2f (tvert); vert[1] = yup; v2f (vert); for (j = 1; j < 17; j ++) { tvert[0] = uvarray[tindexdown + j][0]; tvert[1] = uvarray[tindexdown + j][1]; t2f (tvert); vert[0] = (float) (j); vert[1] = ydown; v2f (vert); tvert[0] = uvarray[tindexup + j][0]; tvert[1] = uvarray[tindexup + j][1]; t2f (tvert); vert[1] = yup; v2f (vert); } endtmesh(); } zbuffer(1); } ----- Makefile for hemisphere.c ----- OPT = -g LFLAGS = \ -lpfdu_igl \ -lpfutil_igl \ -lpf_igl \ -lmpc -limage -lgl -lX11 -lm -lfpe -lC CFLAGS = -c \ -DIRISGL \ -I/home/camus2/Performer/include/Performer/pfdb \ -I/home/camus2/Performer/include/Performer OBJS = hemisphere.o ALL = hemisphere $(ALL): $(OBJS) $(CC) $(OPT) $(OBJS) -o $(ALL) $(LFLAGS) @echo "DONE" .c.o: $(CC) $(OPT) $(CFLAGS) $< ----- OpenGL version (hemiGL.c) ----- #include #include #include #include #include /* for cmdline handler */ #include #include #include "pfutil.h" #include "pfflt.h" #include "gl.h" static void CullChannel(pfChannel *, void *); static void DrawChannel(pfChannel *, void *); static void OpenPipeline(int, uint); static void UpdateView(void); static void drawDistort(void); /* * structure that resides in shared memory so that the * application, cull, and draw processes can access it. */ typedef struct { long exitFlag; pfCoord view; float sceneSize; int drawStats; pfChannel *chan; } SharedData; static SharedData *Shared; /* light source created and updated in draw-process */ static pfLight *Sun; /* for configuring multi-process */ static long ProcSplit = PFMP_APPCULLDRAW; /* write out scene upon read-in - uses pfDebugPrint */ static long WriteScene = 0; /* * docmdline() -- use getopt to get command-line arguments, * executed at the start of the application process. */ static long docmdline(int argc, char *argv[]) { long opt; /* process command-line arguments */ while ((opt = getopt(argc, argv, "wps:?")) != -1) { switch (opt) { case 'w': WriteScene = 1; break; case 'p': ProcSplit = atoi(optarg); break; case 's': Shared->drawStats = 1; break; } } return optind; } /* * main() -- program entry point. this procedure * is executed in the application process. */ int main (int argc, char *argv[]) { int arg; int found; int i; pfNode *root; pfScene *scene; pfPipe *p; pfEarthSky *eSky; pfBox bbox; float far = 40000.0f; pfVec3 xyz, hpr; pfPipeWindow* pw; pfInit(); /* allocate shared before fork()'ing parallel processes */ Shared = (SharedData*)pfMalloc(sizeof(SharedData), pfGetSharedArena()); Shared->exitFlag = 0; Shared->drawStats = 0; arg = docmdline(argc, argv); /* configure multi-process selection */ pfMultiprocess(ProcSplit); /* initiate multi-processing mode set in pfMultiprocess call */ pfConfig(); scene = pfNewScene(); /* specify directories where geometry and textures exist */ if (!(getenv("PFPATH"))) pfFilePath("."); /* load files named by command line arguments */ for (found = 0; arg < argc; arg++) { if ((root = pfdLoadFile(argv[arg])) != NULL) { pfAddChild(scene, root); found++; } } /* if no files successfully loaded, terminate program */ if (!found) exit(0); p = pfGetPipe(0); pfPhase(PFPHASE_FREE_RUN); /* Open and configure full screen GL window. */ pw = pfNewPWin(pfGetPipe(0)); pfPWinOriginSize(pw,0,0,1024,1024); pfPWinName(pw,"IRIS Performer"); pfOpenPWin(pw); pfStageConfigFunc( -1, PFPROC_DRAW, OpenPipeline ); pfConfigStage( -1, PFPROC_DRAW ); pfFrame(); pfFrameRate(30.0f); Shared->chan = pfNewChan(p); pfChanTravFunc(Shared->chan, PFTRAV_CULL, CullChannel ); pfChanTravFunc(Shared->chan, PFTRAV_DRAW, DrawChannel ); pfChanScene(Shared->chan, scene); pfChanNearFar(Shared->chan, 0.1f, far); pfChanFOV(Shared->chan, 136.0f, 92.5f); pfChanViewport( Shared->chan, 0.0, 1.0, 0.000, 1.0 ); pfSetVec3(xyz, 0.0f, 0.0f, 0.0f); pfSetVec3(hpr, 0.0f, 45.0f, 0.0f); pfChanViewOffsets(Shared->chan, xyz, hpr); /* Create an earth/sky model that draws sky/ground/horizon */ eSky = pfNewESky(); pfESkyMode(eSky, PFES_BUFFER_CLEAR, PFES_FAST); pfChanESky(Shared->chan, eSky); pfChanLODAttr( Shared->chan, PFLOD_SCALE, 0.125 ); /* main simulation loop */ while (!Shared->exitFlag) { /* wait until next frame boundary */ pfSync(); /* Set view parameters. */ UpdateView(); pfChanView(Shared->chan, Shared->view.xyz, Shared->view.hpr); /* initiate traversal using current state */ pfFrame(); } /* terminate cull and draw processes (if they exist) */ pfExit(); /* exit to operating system */ exit(0); } /* * UpdateView() updates the eyepoint based on the information * placed in shared memory by GetGLInput(). */ static void UpdateView(void) { static float speed = 0.0f; pfCoord *view = &Shared->view; /* update view direction */ view->hpr[PF_H] = 0.0; view->hpr[PF_P] ++; /*= 0.0;*/ view->hpr[PF_R] = 0.0; /* update view position */ view->xyz[PF_X] = 0.0; view->xyz[PF_Y] = 0.0; view->xyz[PF_Z] = 50.0; /* view->xyz[PF_X] = 15023; view->xyz[PF_Y] = -7199.4; view->xyz[PF_Z] = -204.7 + 1000; */ } /* * OpenPipeline() -- create a pipeline: setup the window system, * the IRIS GL, and IRIS Performer. this procedure is executed in * the draw process (when there is a separate draw process). */ static void OpenPipeline(int pipe, uint stage ) { float xSize = 800; float ySize = 500; /* negotiate with GL */ /* gconfig(); */ /* create a light source in the "south-west" (QIII) */ Sun = pfNewLight(NULL); pfLightPos(Sun, -0.3f, -0.3f, 1.0f, 0.0f); /* create a default texture environment */ pfApplyTEnv(pfNewTEnv(NULL)); /* create a default lighting model */ pfApplyLModel(pfNewLModel(NULL)); pfApplyMtl(pfNewMtl(NULL)); /* enable culling of back-facing polygons */ pfCullFace(PFCF_BACK); /* * These enables should be set to reflect the majority of the * database. If most geometry is not textured, then texture * should be disabled. However, you then need to change the * FLIGHT-format file reader. (pfflt.c) */ pfEnable(PFEN_TEXTURE); pfDisable(PFEN_WIREFRAME); pfDisable(PFEN_LIGHTING); pfDisable(PFEN_FOG); } /* * CullChannel() -- traverse the scene graph and generate a * display list for the draw process. This procedure is * executed in the cull process. */ static void CullChannel(pfChannel *channel, void *data) { pfCull(); } static void DrawChannel (pfChannel *channel, void *data) { /* rebind light so it stays fixed in position */ pfLightOn(Sun); /* erase framebuffer and draw Earth-Sky model */ pfClearChan(channel); /* invoke Performer draw-processing for this frame */ pfDraw(); /* draw Performer throughput statistics */ if (Shared->drawStats) pfDrawChanStats(channel); drawDistort(channel); } #include "newuvarray.h" /* float texprops[] = { TX_MAGFILTER, TX_BILINEAR, TX_MINFILTER, TX_BILINEAR, TX_WRAP, TX_REPEAT, TX_INTERNAL_FORMAT, TX_RGB_5, TX_FAST_DEFINE, TX_NULL}; */ static void drawDistort(void) { static unsigned long map[1024 * 1024], flags; static int first = 1; int i, j; float vert[2]; float tvert[2]; if(first) { glEnable (GL_TEXTURE_2D); first = 0; } /* texdef2d(1024, 3, 1024, 1024, map, 10, texprops); */ glTexImage2D ( GL_TEXTURE_2D, 0, 3, 512, 512, 0, GL_RGB, GL_UNSIGNED_INT, map ); glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); glViewport( 0, 0, 1024, 1024); /* texbind(TX_TEXTURE_0, 1024); fbsubtexload(0, 0, TX_TEXTURE_0, 1024, 0.0, 1.0, 0.0, 1.0, flags); */ /* glCopyTexImage2DEXT (...); */ /* Don't know arguments yet */ gluOrtho2D(0.0, 16.0, 0.0, 16.0); glLoadIdentity(); glDisable(GL_DEPTH_TEST); /* turn off z-buffer */ glDisable(GL_CULL_FACE); /* turn off culling */ glColor4f (1.0, 1.0, 1.0, 1.0); for( i = 0; i < 16; i++) /* sixteen tmesh strips */ { float yup, ydown; int tindexup, tindexdown; ydown = (float) (i); yup = (float) (i + 1); tindexdown = i * 17; tindexup = (i + 1) * 17; glBegin(GL_TRIANGLE_STRIP); tvert[0] = uvarray[tindexdown][0]; tvert[1] = uvarray[tindexdown][1]; glTexCoord2fv (tvert); vert[0] = 0.0; vert[1] = ydown; glVertex2fv (vert); tvert[0] = uvarray[tindexup][0]; tvert[1] = uvarray[tindexup][1]; glTexCoord2fv (tvert); vert[1] = yup; glVertex2fv (vert); for (j = 1; j < 17; j ++) { tvert[0] = uvarray[tindexdown + j][0]; tvert[1] = uvarray[tindexdown + j][1]; glTexCoord2fv (tvert); vert[0] = (float) (j); vert[1] = ydown; glVertex2fv (vert); tvert[0] = uvarray[tindexup + j][0]; tvert[1] = uvarray[tindexup + j][1]; glTexCoord2fv (tvert); vert[1] = yup; glVertex2fv (vert); } glEnd(); } glEnable (GL_DEPTH_TEST); /* turn the z-buffer back on */ } ----- Makefile for hemiGL.c ----- OPT = -g LFLAGS = \ -lpfdu_ogl \ -lpfutil_ogl \ -lpf_ogl \ -lmpc -limage -lGL -lX11 -lm -lfpe -lC CFLAGS = -c \ -I/home/camus2/Performer/include/Performer/pfdb \ -I/home/camus2/Performer/include/Performer OBJS = hemiGL.o ALL = hemiGL $(ALL): $(OBJS) $(CC) $(OPT) $(OBJS) -o $(ALL) $(LFLAGS) @echo "DONE" .c.o: $(CC) $(OPT) $(CFLAGS) $< ----- newuvarray.h (for both versions) ----- float uvarray[289][2] = { 0.067185, 0.080706, 0.174310, 0.155577, 0.250074, 0.203457, 0.308217, 0.235680, 0.355695, 0.257851, 0.396468, 0.273009, 0.433026, 0.282886, 0.467093, 0.288472, 0.500000, 0.290281, 0.532907, 0.288472, 0.566974, 0.282886, 0.603532, 0.273009, 0.644305, 0.257851, 0.691783, 0.235680, 0.749926, 0.203457, 0.825690, 0.155577, 0.932815, 0.080706, 0.067185, 0.150102, 0.174310, 0.212581, 0.250074, 0.252537, 0.308217, 0.279427, 0.355695, 0.297929, 0.396468, 0.310577, 0.433026, 0.318820, 0.467093, 0.323481, 0.500000, 0.324991, 0.532907, 0.323481, 0.566974, 0.318820, 0.603532, 0.310577, 0.644305, 0.297929, 0.691783, 0.279427, 0.749926, 0.252537, 0.825690, 0.212581, 0.932815, 0.150102, 0.067185, 0.211489, 0.174310, 0.263007, 0.250074, 0.295953, 0.308217, 0.318125, 0.355695, 0.333381, 0.396468, 0.343811, 0.433026, 0.350607, 0.467093, 0.354451, 0.500000, 0.355695, 0.532907, 0.354451, 0.566974, 0.350607, 0.603532, 0.343811, 0.644305, 0.333381, 0.691783, 0.318125, 0.749926, 0.295953, 0.825690, 0.263007, 0.932815, 0.211489, 0.067185, 0.266976, 0.174310, 0.308586, 0.250074, 0.335195, 0.308217, 0.353104, 0.355695, 0.365425, 0.396468, 0.373849, 0.433026, 0.379338, 0.467093, 0.382443, 0.500000, 0.383448, 0.532907, 0.382443, 0.566974, 0.379338, 0.603532, 0.373849, 0.644305, 0.365425, 0.691783, 0.353104, 0.749926, 0.335195, 0.825690, 0.308586, 0.932815, 0.266976, 0.067185, 0.318114, 0.174310, 0.350593, 0.250074, 0.371363, 0.308217, 0.385341, 0.355695, 0.394958, 0.396468, 0.401534, 0.433026, 0.405818, 0.467093, 0.408241, 0.500000, 0.409026, 0.532907, 0.408241, 0.566974, 0.405818, 0.603532, 0.401534, 0.644305, 0.394958, 0.691783, 0.385341, 0.749926, 0.371363, 0.825690, 0.350593, 0.932815, 0.318114, 0.067185, 0.366098, 0.174310, 0.390008, 0.250074, 0.405298, 0.308217, 0.415589, 0.355695, 0.422669, 0.396468, 0.427510, 0.433026, 0.430664, 0.467093, 0.432448, 0.500000, 0.433026, 0.532907, 0.432448, 0.566974, 0.430664, 0.603532, 0.427510, 0.644305, 0.422669, 0.691783, 0.415589, 0.749926, 0.405298, 0.825690, 0.390008, 0.932815, 0.366098, 0.067185, 0.411884, 0.174310, 0.427618, 0.250074, 0.437680, 0.308217, 0.444452, 0.355695, 0.449111, 0.396468, 0.452297, 0.433026, 0.454373, 0.467093, 0.455547, 0.500000, 0.455927, 0.532907, 0.455547, 0.566974, 0.454373, 0.603532, 0.452297, 0.644305, 0.449111, 0.691783, 0.444452, 0.749926, 0.437680, 0.825690, 0.427618, 0.932815, 0.411884, 0.067185, 0.456279, 0.174310, 0.464086, 0.250074, 0.469079, 0.308217, 0.472439, 0.355695, 0.474750, 0.396468, 0.476331, 0.433026, 0.477361, 0.467093, 0.477943, 0.500000, 0.478132, 0.532907, 0.477943, 0.566974, 0.477361, 0.603532, 0.476331, 0.644305, 0.474750, 0.691783, 0.472439, 0.749926, 0.469079, 0.825690, 0.464086, 0.932815, 0.456279, 0.067185, 0.500000, 0.174310, 0.500000, 0.250074, 0.500000, 0.308217, 0.500000, 0.355695, 0.500000, 0.396468, 0.500000, 0.433026, 0.500000, 0.467093, 0.500000, 0.500000, 0.500000, 0.532907, 0.500000, 0.566974, 0.500000, 0.603532, 0.500000, 0.644305, 0.500000, 0.691783, 0.500000, 0.749926, 0.500000, 0.825690, 0.500000, 0.932815, 0.500000, 0.067185, 0.543721, 0.174310, 0.535914, 0.250074, 0.530921, 0.308217, 0.527561, 0.355695, 0.525250, 0.396468, 0.523669, 0.433026, 0.522639, 0.467093, 0.522057, 0.500000, 0.521868, 0.532907, 0.522057, 0.566974, 0.522639, 0.603532, 0.523669, 0.644305, 0.525250, 0.691783, 0.527561, 0.749926, 0.530921, 0.825690, 0.535914, 0.932815, 0.543721, 0.067185, 0.588116, 0.174310, 0.572382, 0.250074, 0.562320, 0.308217, 0.555548, 0.355695, 0.550889, 0.396468, 0.547703, 0.433026, 0.545627, 0.467093, 0.544453, 0.500000, 0.544073, 0.532907, 0.544453, 0.566974, 0.545627, 0.603532, 0.547703, 0.644305, 0.550889, 0.691783, 0.555548, 0.749926, 0.562320, 0.825690, 0.572382, 0.932815, 0.588116, 0.067185, 0.633902, 0.174310, 0.609992, 0.250074, 0.594702, 0.308217, 0.584411, 0.355695, 0.577331, 0.396468, 0.572490, 0.433026, 0.569336, 0.467093, 0.567552, 0.500000, 0.566974, 0.532907, 0.567552, 0.566974, 0.569336, 0.603532, 0.572490, 0.644305, 0.577331, 0.691783, 0.584411, 0.749926, 0.594702, 0.825690, 0.609992, 0.932815, 0.633902, 0.067185, 0.681886, 0.174310, 0.649407, 0.250074, 0.628637, 0.308217, 0.614659, 0.355695, 0.605042, 0.396468, 0.598466, 0.433026, 0.594182, 0.467093, 0.591759, 0.500000, 0.590974, 0.532907, 0.591759, 0.566974, 0.594182, 0.603532, 0.598466, 0.644305, 0.605042, 0.691783, 0.614659, 0.749926, 0.628637, 0.825690, 0.649407, 0.932815, 0.681886, 0.067185, 0.733024, 0.174310, 0.691414, 0.250074, 0.664805, 0.308217, 0.646896, 0.355695, 0.634575, 0.396468, 0.626151, 0.433026, 0.620662, 0.467093, 0.617557, 0.500000, 0.616552, 0.532907, 0.617557, 0.566974, 0.620662, 0.603532, 0.626151, 0.644305, 0.634575, 0.691783, 0.646896, 0.749926, 0.664805, 0.825690, 0.691414, 0.932815, 0.733024, 0.067185, 0.788511, 0.174310, 0.736993, 0.250074, 0.704047, 0.308217, 0.681875, 0.355695, 0.666619, 0.396468, 0.656189, 0.433026, 0.649393, 0.467093, 0.645549, 0.500000, 0.644305, 0.532907, 0.645549, 0.566974, 0.649393, 0.603532, 0.656189, 0.644305, 0.666619, 0.691783, 0.681875, 0.749926, 0.704047, 0.825690, 0.736993, 0.932815, 0.788511, 0.067185, 0.849898, 0.174310, 0.787419, 0.250074, 0.747463, 0.308217, 0.720573, 0.355695, 0.702071, 0.396468, 0.689423, 0.433026, 0.681180, 0.467093, 0.676519, 0.500000, 0.675009, 0.532907, 0.676519, 0.566974, 0.681180, 0.603532, 0.689423, 0.644305, 0.702071, 0.691783, 0.720573, 0.749926, 0.747463, 0.825690, 0.787419, 0.932815, 0.849898, 0.067185, 0.919294, 0.174310, 0.844423, 0.250074, 0.796543, 0.308217, 0.764320, 0.355695, 0.742149, 0.396468, 0.726991, 0.433026, 0.717114, 0.467093, 0.711528, 0.500000, 0.709719, 0.532907, 0.711528, 0.566974, 0.717114, 0.603532, 0.726991, 0.644305, 0.742149, 0.691783, 0.764320, 0.749926, 0.796543, 0.825690, 0.844423, 0.932815, 0.919294 }; " -- Regards Parviz Parandeh SE , Montreal Canada parviz@stlaurent.sgi.com Voice mail: 58479 Tel: 514-745-2440 Fax: 514-745-2660 From guest Tue Apr 9 15:56:56 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA01453; Tue, 9 Apr 1996 15:47:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA01450; Tue, 9 Apr 1996 15:47:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26951; Tue, 9 Apr 96 15:46:58 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA06456; Tue, 9 Apr 1996 15:46:53 -0700 Received: from bitch.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for id PAA27575; Tue, 9 Apr 1996 15:46:50 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id XAA02733; Tue, 9 Apr 1996 23:41:24 +0100 From: "Angus Dorbie" Message-Id: <9604092341.ZM2731@bitch.reading.sgi.com> Date: Tue, 9 Apr 1996 23:41:24 +0100 In-Reply-To: "parviz" "(Fwd) Problems with OpenGL conversion of distortion correction program" (Apr 9, 3:33pm) References: <9604091533.ZM19822@pxp.stlaurent.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "parviz" , info-performer@sgi.sgi.com Subject: Re: Problems with OpenGL conversion of distortion correction program Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O This isn't _too_ surprising. You don't say what machine you are trying this on. I expect that it'd probably only work in OpenGL on an IMPACT (or IR). Angus Henderson has now ported this demo to use Performer2.0 API & no IrisGL which works on an RE2 with Performer 2.0 & an IrisGL compile. It does not work with an OpenGL compile even with Patch 918 installed. This could be OGL (likely) or Performer 2.0 (haven't tried the latest) but the pure Performer code is probably where you want to be. If you want a copy I can email it to you, I'll get around to putting this code on sgigate sometime. It's value will greatly diminish with the official distortion correction in Performer 2.1 which hemisphere.c isn't. It's important to realise that you'd have to restructure the operation of hemisphere to obtain reasonable performance on an Infinite Reality, and similar tweaks could also buy some time on other platforms. Rgds, Angus. On Apr 9, 3:33pm, parviz wrote: > Subject: (Fwd) Problems with OpenGL conversion of distortion correction pr > One of our Customer has the following problem with converting distortion > correction program to OpenGl, > any ideas?? > > > "I modified the distortion correction demo program "hemisphere.c" that > I found on sgigate.sgi.com in the distribution file > /pub/Performer/RealityCentre/distort.tar.Z. The modification works fine > under IrisGL. I then attempted to convert the modified program to > OpenGL without much success; none of the OpenGL commands seem to draw > anything. Could you ask one of your Performer/OpenGL gurus to have a look > at the program please? I've attached copies of both the IrisGL and OpenGL > versions of the program. Running the programs requires the .flt-format > models and textures found in the distributon file. Thanks > > PS - can I copy the frame buffer into a 1024x1280 texture map? I'm not > sure what the restrictions on texture map size are. > >-- End of excerpt from parviz -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Tue Apr 9 16:47:48 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id QAA01908; Tue, 9 Apr 1996 16:37:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id QAA01905; Tue, 9 Apr 1996 16:37:06 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00348; Tue, 9 Apr 96 16:37:05 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id QAA10388; Tue, 9 Apr 1996 16:37:03 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA00270; Tue, 9 Apr 96 16:36:13 -0700 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA06707; Tue, 9 Apr 1996 16:36:12 -0700 From: "Michael Jones" Message-Id: <9604091636.ZM6705@babar.asd.sgi.com> Date: Tue, 9 Apr 1996 16:36:12 -0700 In-Reply-To: william_marinelli@ntsc.navy.mil "Re[2]: terrain paging" (Apr 9, 4:18pm) References: <9603098290.AA829092115@CCMAIL.NTSC.NAVY.MIL> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: william_marinelli@ntsc.navy.mil, info-performer@sgi.sgi.com Subject: Re: Re[2]: terrain paging Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 9, 4:18pm, william_marinelli@ntsc.navy.mil wrote: > Subject: Re[2]: terrain paging : Be interesting if we could page in individual levels of detail of : terrain. Example: If the terrain is represnted with three lods, and we : page it in because the ownship is sufficiently close to that tile. : When that terrain first comes into view, only the lowest lod is : visible. If the ownship continues, then the higher lods will be : blended in. But what if the ownship does a hard right when it's far : enough away that only the lowest lod could have possibly been visible? : All that bandwidth would have ben wasted on the higher lods which : would now have to be discarded. : : Any thoughts about the ability of paging in individual terrain lods : when appropriate? I apologize for the ignorance if this is already : included in performer and I'm simply clueless. : >-- End of excerpt from william_marinelli@ntsc.navy.mil You can do this just fine. Simply save out the children of the LOD node in separate files and then load them as desired. -- Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Tue Apr 9 17:18:40 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA02237; Tue, 9 Apr 1996 17:05:37 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA02234; Tue, 9 Apr 1996 17:05:36 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02642; Tue, 9 Apr 96 17:05:34 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA12136; Tue, 9 Apr 1996 17:05:33 -0700 Received: from euphoria.corp.sgi.com by sgihub.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for id QAA05544; Tue, 9 Apr 1996 16:39:57 -0700 Received: by euphoria.corp.sgi.com (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi id QAA14030; Tue, 9 Apr 1996 16:38:43 -0700 From: "Gene Koh" Message-Id: <9604091638.ZM14028@euphoria.corp.sgi.com> Date: Tue, 9 Apr 1996 16:38:43 -0700 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: pfBuffer question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Suppose that I have a DCS node with 2 children, and that I want to continually replace child 0 in a DBASE func. Initially, everything's created in the APP process. In the DBASE func, I use pfBufferInsert(shared->parentDCS, 0, newModel). It works, but my question is, is this the right way to do it? In the pfBuffer man page, it states: "pfBufferAddChild and pfBufferRemoveChild provide access to nodes that do not exist in the current pfBuffer." Which means that pfBufferInsert doesn't provide such access. From what I know about buffers, shared->parentDCS doesn't really exist in the local DBASE buffer (which I've created and selected). So pfBufferInsert shouldn't work. Am I just totally confused? Thanks for any insight. -- gene koh gene@corp.sgi.com 415.933.4230 simplicity patience compassion From guest Tue Apr 9 17:18:35 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA02242; Tue, 9 Apr 1996 17:05:39 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA02239; Tue, 9 Apr 1996 17:05:38 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02658; Tue, 9 Apr 96 17:05:37 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA12142; Tue, 9 Apr 1996 17:05:35 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for id QAA04767; Tue, 9 Apr 1996 16:34:58 -0700 Received: from proxima.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA00059; Tue, 9 Apr 96 16:33:40 -0700 Received: by proxima.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id QAA18726; Tue, 9 Apr 1996 16:33:40 -0700 From: "Tom McReynolds" Message-Id: <9604091633.ZM18724@proxima.asd.sgi.com> Date: Tue, 9 Apr 1996 16:33:40 -0700 In-Reply-To: "parviz" "(Fwd) Problems with OpenGL conversion of distortion correction program" (Apr 9, 3:33pm) References: <9604091533.ZM19822@pxp.stlaurent.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "parviz" , info-performer@sgi.sgi.com Subject: Re: Problems with OpenGL conversion of distortion correction program Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I don't know what's wrong with your program, but here's a few comments... On Apr 9, 3:33pm, parviz wrote: > Subject: (Fwd) Problems with OpenGL conversion of distortion correction pr > One of our Customer has the following problem with converting distortion > correction program to OpenGl, > any ideas?? > > > "I modified the distortion correction demo program "hemisphere.c" that > I found on sgigate.sgi.com in the distribution file > /pub/Performer/RealityCentre/distort.tar.Z. The modification works fine > under IrisGL. I then attempted to convert the modified program to > OpenGL without much success; none of the OpenGL commands seem to draw > anything. Could you ask one of your Performer/OpenGL gurus to have a look > at the program please? I've attached copies of both the IrisGL and OpenGL > versions of the program. Running the programs requires the .flt-format > models and textures found in the distributon file. Thanks > > PS - can I copy the frame buffer into a 1024x1280 texture map? I'm not > sure what the restrictions on texture map size are. You need to use proxy calls to figure this out. You make a glTexImage2D call, using GL_PROXY_TEXTURE_2D_EXT instead of GL_TEXTURE_2D, and then make the glGetTexLevelParameter{i,f}v() call, again using the proxy texture as an argument. If the texture would have been too big, the parameters will be zero. Be sure to set the format, type, size, etc the same as you would want for the real texture. > > ----- IrisGL version (hemisphere.c) ----- > > #include > #include > #include ... > static void > drawDistort(void) > { > > static unsigned long map[1024 * 1024], flags; > static int first = 1; > int i, j; > float vert[2]; > float tvert[2]; > > if(first) > { > glEnable (GL_TEXTURE_2D); > first = 0; > } > /* texdef2d(1024, 3, 1024, 1024, map, 10, texprops); */ > > glTexImage2D ( > GL_TEXTURE_2D, 0, 3, 512, 512, 0, GL_RGB, GL_UNSIGNED_INT, map > ); > glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); > glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); > glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); > glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); > > glViewport( 0, 0, 1024, 1024); > /* texbind(TX_TEXTURE_0, 1024); > fbsubtexload(0, 0, TX_TEXTURE_0, 1024, 0.0, 1.0, 0.0, 1.0, flags); */ > /* glCopyTexImage2DEXT (...); */ /* Don't know arguments yet */ > > gluOrtho2D(0.0, 16.0, 0.0, 16.0); > glLoadIdentity(); You probably want to reverse the order of these two. The second is undoing the first... -Tom > > -- > Regards > > Parviz Parandeh > SE , Montreal Canada > parviz@stlaurent.sgi.com > Voice mail: 58479 > Tel: 514-745-2440 > Fax: 514-745-2660 > > >-- End of excerpt from parviz From guest Tue Apr 9 17:59:04 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA02473; Tue, 9 Apr 1996 17:48:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA02470; Tue, 9 Apr 1996 17:48:32 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05639; Tue, 9 Apr 96 17:48:31 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA15960; Tue, 9 Apr 1996 17:48:29 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id BAA02847; Wed, 10 Apr 1996 01:44:25 +0100 From: "Angus Dorbie" Message-Id: <9604100144.ZM2845@bitch.reading.sgi.com> Date: Wed, 10 Apr 1996 01:44:24 +0100 In-Reply-To: "Angus Dorbie" "Re: Problems with OpenGL conversion of distortion correction program" (Apr 9, 11:41pm) References: <9604091533.ZM19822@pxp.stlaurent.sgi.com> <9604092341.ZM2731@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com, "parviz" Subject: Re: Problems with OpenGL conversion of distortion correction program Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > PS - can I copy the frame buffer into a 1024x1280 texture map? I'm not > sure what the restrictions on texture map size are. I forgot to answer this bit, the summary is that you can split the download & use multiple textures and there are big performance gains from this on IR, it also ties in very nicely with the hemisphere requirement for at least 3 OTW channels. For more speculative rambling detail read on. Images must be a exponent of 2 in an edge so the closest texture size would by 1024x1024 on a single download, although you could load 1024x1280 into a subregion of a 1kx2K image on the right platform. One thing it makes sense to do is download the image sections and draw portions of the mesh which you have the image data for, while always having an outstanding download requirement unrelated to any mesh image you may currently be using. This is easy with the dome example because the OTW scene is rendered in three parts so you'd draw the first OTW & download it, then draw the second & download then the third & download then draw the dome mesh using the portions of the image data 1 then 2 then 3, hopefully most of the third image will be downloaded by the time you use it in the mesh. So how does this affect your texture size? Well you could easily download the images into multiple textures which may cause edge problems which would mean you'd have to split the mesh or use the equivalent of a TX_SELECT texture clamp. Or you could load the image in sections into a larger image. If youre worried about blowing all that texture memory you could draw OTW 1 & download then draw OTW 2 & download then dram mesh 1/3 1 then download OTW 2 over the used texture, etc. This is only possible because you have multiple OTW channels & you may loose some performance on the block after the mesh download. Rgds, Angus. -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Tue Apr 9 18:13:19 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA02484; Tue, 9 Apr 1996 18:01:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA02481; Tue, 9 Apr 1996 18:01:34 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06159; Tue, 9 Apr 96 18:01:33 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id SAA16703; Tue, 9 Apr 1996 18:01:31 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA06136; Tue, 9 Apr 96 18:00:43 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id SAA13942; Tue, 9 Apr 1996 18:00:42 -0700 From: "Sharon Clay" Message-Id: <9604091800.ZM13940@rose.asd.sgi.com> Date: Tue, 9 Apr 1996 18:00:42 -0700 In-Reply-To: "Tom McReynolds" "Re: Problems with OpenGL conversion of distortion correction program" (Apr 9, 4:33pm) References: <9604091533.ZM19822@pxp.stlaurent.sgi.com> <9604091633.ZM18724@proxima.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Tom McReynolds" , "parviz" , info-performer@sgi.sgi.com Subject: Re: Problems with OpenGL conversion of distortion correction program Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 9, 4:33pm, Tom McReynolds wrote: > Subject: Re: Problems with OpenGL conversion of distortion correction prog ->> ->> glViewport( 0, 0, 1024, 1024); ->> /* texbind(TX_TEXTURE_0, 1024); ->> fbsubtexload(0, 0, TX_TEXTURE_0, 1024, 0.0, 1.0, 0.0, 1.0, flags); */ ->> /* glCopyTexImage2DEXT (...); */ /* Don't know arguments yet */ ->> ->> gluOrtho2D(0.0, 16.0, 0.0, 16.0); ->> glLoadIdentity(); -> ->You probably want to reverse the order of these two. The second is undoing the ->first... I think what Tom is hinting at here is that gluOrtho2D and glOrtho both operate multiplicitivly on the current matrix. So, you proably want: glMatrixMode(GL_PROJECTION); glLoadIdentity() gluOrtho2D() glMatrixMode(GL_MODELVIEW); glLoadIdentity(); src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue Apr 9 19:33:15 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id TAA02764; Tue, 9 Apr 1996 19:21:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id TAA02761; Tue, 9 Apr 1996 19:21:20 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09764; Tue, 9 Apr 96 19:21:19 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA22655; Tue, 9 Apr 1996 19:21:17 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id TAA27130; Tue, 9 Apr 1996 19:20:51 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id TAA25651; Tue, 9 Apr 1996 19:20:06 -0700 From: "AnitaKishore" Message-Id: <9604091920.ZM25649@lee.electrogig.com> Date: Tue, 9 Apr 1996 19:20:05 -0700 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: changing texture image Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I am trying to change a pfTexture's image during run time and facing the following problem: Since the new image file (.rgb) may not match in format to the already loaded image, I do the following in APP: uint *image = NULL; int comp, ns, nt, nr; // assume I have the proper "originalTex" pfTexture *tempTex = pfNewTex(pfGetSharedArena()); pfLoadTexFile(tempTex, newImageFile); pfGetTexImage(tempTex, &image, &comp, &ns, &nt, &nr); pfFreeTexImage(originalTex); pfTexImage(originalTex, image, comp, ns, nt, nr); pfTexName(originalTex, newImageFile); pfFree(tempTex); The texture attributes are set to the new ones properly. I have checked this by getting tex image after each change. But the render area doesn't show the proper change. I can see the new image, but without any color - I guess the formatting is wrong. How can I correctly set the new image to the pfTexture type "originaltex"? Do I need to do something in DRAW process? BTW: the old image and the new image don't have the same format. The old one is RGBA (which gets loaded in through the iv loader). The new image is RGB which I am trying to set as above. Any help would be greately appreciated. thanks -anita ----------------------------------------------------------------- Anita Kishore kishore@electrogig.com ----------------------------------------------------------------- From guest Tue Apr 9 19:43:23 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id TAA02777; Tue, 9 Apr 1996 19:35:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id TAA02774; Tue, 9 Apr 1996 19:35:16 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10268; Tue, 9 Apr 96 19:35:15 -0700 Received: from hntp2.hinet.net by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id TAA08717; Tue, 9 Apr 1996 19:35:10 -0700 Received: from systech.hinet.net (systech.hinet.net [168.95.200.3]) by hntp2.hinet.net (8.6.11/8.6.11) with SMTP id KAA03030 for <@hntp2.hinet.net:info-performer@sgi.com>; Wed, 10 Apr 1996 10:34:18 +0800 Received: by systech.hinet.net (931110.SGI/930416.SGI) for @hntp2.hinet.net:info-performer@sgi.com id AA07628; Wed, 10 Apr 96 11:36:17 -0700 Date: Wed, 10 Apr 96 11:36:17 -0700 From: terence@systech.hinet.net (Terence Ker) Message-Id: <9604101836.AA07628@systech.hinet.net> To: info-performer@sgi.com Subject: Details of graphics pipeline Status: O Hi, Performers; Could anyone direct me to some documents or books explaining about how CPU, Geometry engine, Raster Manager are cooperating to do the rendering on a display, in a way with a little bit more details than what's in the SGI RealityEngine technical report. I always have the impression that CPU is doing nothing other than sending data down the pipleline. Also, a little bit more details on multisampling, texture paging, and how the frame buffer is partitioned..etc. I get into SGI graphics stuff starting from reading OpenGL programmers guide and RealityEngine Technical Report. Then I work on Performer 1.2. which made me feel that I have do some readings on IrisGL. I have been reading all you Performer experts discussions in this mail group. Could someone fill me in with a little more SGI graphics technical background so that I can read your questions/answers with more understanding. Very appreciative of any kind of help.. -= Terence Ke =- Systems & Technology Taipei, Taiwan e-mail: terence@systech.hinet.net From guest Wed Apr 10 00:27:07 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id AAA03509; Wed, 10 Apr 1996 00:16:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA03506; Wed, 10 Apr 1996 00:16:37 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18067; Wed, 10 Apr 96 00:16:36 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id AAA06119; Wed, 10 Apr 1996 00:16:35 -0700 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA18064; Wed, 10 Apr 96 00:16:32 -0700 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id AAA09527; Wed, 10 Apr 1996 00:14:11 -0700 From: "Javier Castellar" Message-Id: <9604100014.ZM9525@sixty.asd.sgi.com> Date: Wed, 10 Apr 1996 00:14:10 -0700 In-Reply-To: "Sharon Clay" "Re: Problems with OpenGL conversion of distortion correction program" (Apr 9, 6:00pm) References: <9604091533.ZM19822@pxp.stlaurent.sgi.com> <9604091633.ZM18724@proxima.asd.sgi.com> <9604091800.ZM13940@rose.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Sharon Clay" , "Tom McReynolds" , "parviz" , info-performer@sgi.sgi.com Subject: Re: Problems with OpenGL conversion of distortion correction program Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O >I think what Tom is hinting at here is that gluOrtho2D and glOrtho >both operate multiplicitivly on the current matrix. >So, you proably want: We have included pfuSet2D and pfuUnSet2D on the distortion correction utility which deal with all this nasty issues. The pfu utility is not a super "manbo-bambo" pfu star but has some very convenient complementary routines. -Javier -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon From guest Wed Apr 10 00:23:27 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id AAA03385; Wed, 10 Apr 1996 00:12:55 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA03382; Wed, 10 Apr 1996 00:12:54 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17898; Wed, 10 Apr 96 00:12:53 -0700 Received: from buitre.madrid.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id AAA05966; Wed, 10 Apr 1996 00:12:50 -0700 Received: by buitre.madrid.sgi.com (940816.SGI.8.6.9/930416.SGI) id JAA13635; Wed, 10 Apr 1996 09:59:12 GMT From: "Luis Ignacio Miranda" Message-Id: <9604100959.ZM13633@buitre.madrid.sgi.com> Date: Wed, 10 Apr 1996 09:59:12 -0600 In-Reply-To: terence@systech.hinet.net (Terence Ker) "Details of graphics pipeline" (Apr 10, 11:36am) References: <9604101836.AA07628@systech.hinet.net> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: terence@systech.hinet.net (Terence Ker) Subject: Re: Details of graphics pipeline Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Terence, I suggest you to consult the bibliography about Computer Graphics specified in the Programmer's guide of Performer 2.0, specially the SIGGRAPH paper and course. In this course there are some paper reprints that can help you. Hope this helps, Nacho On Apr 10, 11:36am, Terence Ker wrote: > Subject: Details of graphics pipeline > > Hi, Performers; > > Could anyone direct me to some documents or books explaining about > how CPU, Geometry engine, Raster Manager are cooperating to do the rendering > on a display, in a way with a little bit more details than what's in the > SGI RealityEngine technical report. I always have the impression that CPU > is doing nothing other than sending data down the pipleline. > > Also, a little bit more details on multisampling, texture paging, > and how the frame buffer is partitioned..etc. > > I get into SGI graphics stuff starting from reading OpenGL programmers > guide and RealityEngine Technical Report. Then I work on Performer 1.2. which > made me feel that I have do some readings on IrisGL. I have been reading all > you Performer experts discussions in this mail group. > > Could someone fill me in with a little more SGI graphics technical > background so that I can read your questions/answers with more understanding. > > Very appreciative of any kind of help.. > > > > > -= Terence Ke =- > > Systems & Technology > Taipei, Taiwan > e-mail: terence@systech.hinet.net > > > >-- End of excerpt from Terence Ker -- ******************************************************************************* * Luis Ignacio Miranda Edificio "Santa Engracia 120" * * Silicon Graphics, S.A. Plaza del Descubridor Diego de Ordas,3 * * Systems Engineering Division 28003 MADRID SPAIN * * e-mail : lmiranda@madrid.sgi.com Telephone ++ 34 1 4429077 * * v-mail : x57598 Fax ++ 34 1 4420150 * ******************************************************************************* From guest Wed Apr 10 00:20:42 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id AAA03264; Wed, 10 Apr 1996 00:09:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA03261; Wed, 10 Apr 1996 00:09:56 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17762; Wed, 10 Apr 96 00:09:55 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id AAA05857; Wed, 10 Apr 1996 00:09:54 -0700 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA17759; Wed, 10 Apr 96 00:09:52 -0700 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id AAA09517; Wed, 10 Apr 1996 00:07:31 -0700 From: "Javier Castellar" Message-Id: <9604100007.ZM9515@sixty.asd.sgi.com> Date: Wed, 10 Apr 1996 00:07:31 -0700 In-Reply-To: "parviz" "(Fwd) Problems with OpenGL conversion of distortion correction program" (Apr 9, 3:33pm) References: <9604091533.ZM19822@pxp.stlaurent.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "parviz" , info-performer@sgi.sgi.com Subject: Re: Problems with OpenGL conversion of distortion correction program Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Parviz, I think that i have what you need regarding distortion correction. We have developed a clean pfu lib for distortion correction on iR (also works in RE2). This pfu is planned to be posted on info-performer after the 2.1 release since i need to add some additional tuning in order to interlace geometry and texture on the BEF FIFO on iR. It has been made in Performer+OpenGL and it is just a postDraw callback. The speed on iR is very good (please refer to a previous email about this pfulib for more details) but you can use it a low perfomance on RE2. Since your request seems to be urgent please send me the location of your machine to copy the a beta library on the path of your convenience. It should work on pf2.0 as well. -Javier > One of our Customer has the following problem with converting distortion >correction program to OpenGl, >any ideas?? -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon From guest Wed Apr 10 02:22:35 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA04379; Wed, 10 Apr 1996 02:12:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA04376; Wed, 10 Apr 1996 02:12:50 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20606; Wed, 10 Apr 96 02:12:49 -0700 Received: from mails.HHI.DE by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA10824; Wed, 10 Apr 1996 02:12:27 -0700 Received: from mailsam.HHI.DE (mailsam-isdn.HHI.DE) by mails.HHI.DE (5.65c/HHI-MX) for id AA09401; Wed, 10 Apr 1996 11:08:31 +0200 Received: from bssun93.hhi.de (bssun93 [193.174.65.93]) by mailsam.HHI.DE (8.6.12/8.5) with ESMTP id LAA03797; Wed, 10 Apr 1996 11:12:00 +0200 Received: from bssun91. (bssun91 [193.174.65.91]) by bssun93.hhi.de (8.7.2/8.7.2) with SMTP id LAA19957 for ; Wed, 10 Apr 1996 11:11:57 +0200 (MET DST) Received: by bssun91. (SMI-8.6/SMI-SVR4) id LAA12289; Wed, 10 Apr 1996 11:11:55 +0200 Date: Wed, 10 Apr 1996 11:11:55 +0200 From: bardo@HHI.DE (Kai Schaffors) Message-Id: <199604100911.LAA12289@bssun91.> To: info-performer@sgi.sgi.com Subject: unsubscribe X-Sun-Charset: US-ASCII Status: O unsubscribe bardo@hhi.de From guest Wed Apr 10 05:27:05 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA04619; Wed, 10 Apr 1996 05:16:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA04616; Wed, 10 Apr 1996 05:16:20 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23734; Wed, 10 Apr 96 05:16:19 -0700 Received: from hni.uni-paderborn.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA17489; Wed, 10 Apr 1996 05:16:04 -0700 Received: from faxe.uni-paderborn.de (faxe [131.234.198.2]) by hni.uni-paderborn.de (8.6.10/hni-mailhub) with ESMTP id OAA03940; Wed, 10 Apr 1996 14:14:18 +0200 Received: (pe@localhost) by faxe.uni-paderborn.de (8.6.10/client-irix-hni) id MAA12183; Wed, 10 Apr 1996 12:14:16 GMT From: "Peter Ebbesmeyer" Message-Id: <9604101414.ZM12181@faxe> Date: Wed, 10 Apr 1996 14:14:13 -0600 In-Reply-To: terence@systech.hinet.net (Terence Ker) "Details of graphics pipeline" (Apr 10, 11:36am) References: <9604101836.AA07628@systech.hinet.net> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com, terence@systech.hinet.net (Terence Ker) Subject: Re: Details of graphics pipeline Cc: pe@hni.uni-paderborn.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Terence, I would recommend to read the following references: Akeley, K.: RealityEngine Graphics Proceedings of SIGGRAPH'93 pp. 109 - 116 Rohlf, J.; Helman, J.: IRIS-Performer: A High Performance Multiprocessing Toolkit for Real-Time 3D Graphics Proceedings of SIGGRAPH'94 pp. 381 - 394 Interactive Walkthrough of Large Geometric Databases Course Notes for SIGGRAPH'95 As far as I know these papers are availabe at SGIs FTP-server. Check ftp://sgigate.sgi.com/pub/Performer/docs/ Hope this helps, Peter -- From guest Wed Apr 10 05:35:04 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA04630; Wed, 10 Apr 1996 05:25:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA04627; Wed, 10 Apr 1996 05:25:57 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23940; Wed, 10 Apr 96 05:25:56 -0700 Received: from cathy.rennes.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA17841; Wed, 10 Apr 1996 05:25:37 -0700 Received: by cathy.rennes.sgi.com (950511.SGI.8.6.12.PATCH526/911001.SGI) for info-performer@sgi.sgi.com id OAA04325; Wed, 10 Apr 1996 14:32:21 +0200 From: "Pierre Vercruysse" Message-Id: <9604101432.ZM4323@cathy.rennes.sgi.com> Date: Wed, 10 Apr 1996 14:32:21 -0600 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: test Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O -- -- -- Pierre Vercruysse pierre@rennes.sgi.com vmail : 58781 Software Engineer Tel (33) 99-23-12-80 Fax (33) 99-23-18-95 -- . _ _ _ _ Silicon Graphics France | | | | | | | | | office RENNES -- | |- |- |- |- Espace Performance | | |_ |\ |\ |_ 35769 Saint Gregoire From guest Wed Apr 10 06:17:59 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA04846; Wed, 10 Apr 1996 06:07:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA04843; Wed, 10 Apr 1996 06:07:47 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24831; Wed, 10 Apr 96 06:07:45 -0700 Received: from sun01.cdc.polimi.it by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA20124; Wed, 10 Apr 1996 06:07:19 -0700 From: tgin0490@sun01.cdc.polimi.it Received: (from tgin0490@localhost) by sun01.cdc.polimi.it (8.6.10/8.6.10) id PAA00888 for info-performer@sgi.sgi.com; Wed, 10 Apr 1996 15:14:02 +0200 Date: Wed, 10 Apr 1996 15:14:02 +0200 Message-Id: <199604101314.PAA00888@sun01.cdc.polimi.it> To: info-performer@sgi.sgi.com Subject: unsubscribe X-Sun-Charset: US-ASCII Status: O Unsubscribe me, please...... .......it's been a pleasure!!! (Sigh!!) From guest Wed Apr 10 08:28:10 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA05060; Wed, 10 Apr 1996 08:16:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA05057; Wed, 10 Apr 1996 08:16:49 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27838; Wed, 10 Apr 96 08:16:44 -0700 Received: from bhole.cae.ca by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id IAA27228; Wed, 10 Apr 1996 08:16:39 -0700 Received: from popsie.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA06787; Wed, 10 Apr 1996 10:49:31 -0400 Received: by popsie.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id KAA10847; Wed, 10 Apr 1996 10:50:13 -0400 From: "Madhu Sethi" Message-Id: <9604101049.ZM10845@popsie.cae.ca> Date: Wed, 10 Apr 1996 10:49:57 -0400 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com Subject: Shadows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, I am trying to create shadows using a pfLightSource. Could someone explain the values: PF_SHADOW_DISPLACE_SCALE PF_SHADOW_DISPLACE_OFFSET Whate *exactly* do they do, and what units are they in? Thanks. -- Madhu Sethi CAE Electronics Ltd. Saint-Laurent, Quebec, Canada From guest Wed Apr 10 08:32:27 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA05069; Wed, 10 Apr 1996 08:23:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA05066; Wed, 10 Apr 1996 08:23:27 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28112; Wed, 10 Apr 96 08:23:21 -0700 Received: from bhole.cae.ca by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) id IAA27971; Wed, 10 Apr 1996 08:23:20 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA12739; Wed, 10 Apr 1996 10:52:19 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id KAA07262; Wed, 10 Apr 1996 10:51:06 -0400 From: "Bernard Leclerc" Message-Id: <9604101050.ZM7260@eagle.cae.ca> Date: Wed, 10 Apr 1996 10:50:45 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: gilroy@stlaurent.sgi.com (Gilles Roy - SGI Account Manager), parviz@stlaurent.sgi.com (Parviz Parandeh - SGI System Engineer) Subject: Indigo2 Impact Channel Option (ICO) Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O First question: How many SVGA channels are generated by the ICO? I have 2 brochures describing the Impact product line. One says the ICO can generate 4 SVGA channels, the other says 2 -- on the Maximum Impact only. Which one is correct? Second question: Is full-screen anti-aliasing available when using SVGA on the ICO? Thanks... -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Wed Apr 10 12:58:10 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA05632; Wed, 10 Apr 1996 12:46:52 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA05629; Wed, 10 Apr 1996 12:46:51 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07402; Wed, 10 Apr 96 12:46:49 -0700 Received: from inesc.inesc.pt by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA08632; Wed, 10 Apr 1996 12:46:33 -0700 Received: from minerva.inesc.pt (minerva-2.inesc.pt) by inesc.inesc.pt with SMTP; id AA25848 (/); Wed, 10 Apr 1996 20:46:19 +0100 Received: from minerva (localhost) by minerva.inesc.pt (4.1/Sun OS 4.1.1) id AA13504; Wed, 10 Apr 96 20:46:18 +0100 Sender: mgo@minerva.inesc.pt Message-Id: <316C100A.41C67EA6@minerva.inesc.pt> Date: Wed, 10 Apr 1996 20:46:18 +0100 From: Nuno Godinho X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Performer Mailing List Subject: Don't know how to use keyboard in Perf 2.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Somehow I can't understand how to use the keyboard in my Perf 2.0 application. I tried to follow the complex.C example, used qdevice() to choose the keys I want queued and then copied the qtest() routine in GetGlInput() function. This didn't work: nothing happens qhen I press them. Qtest() always retuns 0. Can anyone teach a simple way to use the keyboard? Thanks Nuno From guest Wed Apr 10 13:04:29 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA05637; Wed, 10 Apr 1996 12:53:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA05634; Wed, 10 Apr 1996 12:53:11 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07880; Wed, 10 Apr 96 12:53:09 -0700 Received: from profs1.prosolvia.se by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA09504; Wed, 10 Apr 1996 12:52:48 -0700 Received: from pc24.prosolvia.se (pc01.prosolvia.se [193.13.244.33]) by profs1.prosolvia.se (950413.SGI.8.6.12/8.6.11) with SMTP id VAA24707 for ; Wed, 10 Apr 1996 21:52:24 +0200 Date: Wed, 10 Apr 1996 21:52:24 +0200 Message-Id: <199604101952.VAA24707@profs1.prosolvia.se> X-Sender: stefan@mailhub 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@clarus.se (Stefan Hallin) Subject: Resolution Status: O What is the resolution that you use on the Infinite Reality with 1,2 and 4= RMs. What is the maximum addressable pixel space if you want to have MEDIUM pixel depth. Of special interest is: 1024x768_120s Can you drive 4 channels with this resolution with 4RMs in one pipe and still have multisampling etc (or even more channels).=20 best regards and hopeful for a QUICK ANSWER Stefan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Notice: New address= since April 1 1996 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D ----------------------------------------------------------------------------= - Stefan Hallin Prosolvia Clarus AB - Sixth Sense Technology President G=E5rdav=E4gen 1 Phone: +46 31 703 51 01 S-412 50 Goteborg Fax: +46 31 703 51 20 Sweden Email: stefan@clarus.se=20 http://www.clarus.se =20 ---------------------------------------------------------------------- From guest Wed Apr 10 13:33:48 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA06064; Wed, 10 Apr 1996 13:25:24 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA06061; Wed, 10 Apr 1996 13:25:23 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09846; Wed, 10 Apr 96 13:25:22 -0700 Received: from walt.tsc.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA13789; Wed, 10 Apr 1996 13:25:19 -0700 From: cstanek@smtpgate.sm.tsc.com Received: from smtpgate.sm.tsc.com by walt.tsc.com with SMTP (1.37.109.16/16.2) id AA111678102; Wed, 10 Apr 1996 15:28:22 -0500 Received: from ccMail by smtpgate.sm.tsc.com (SMTPLINK V2.10.03) id AA829164291; Wed, 10 Apr 96 13:25:38 PST Date: Wed, 10 Apr 96 13:25:38 PST Message-Id: <9603108291.AA829164291@smtpgate.sm.tsc.com> To: info-performer@sgi.sgi.com, Nuno Godinho Subject: Re: Don't know how to use keyboard in Perf 2.0 Status: O if you want to render IRIS GL into a pure IRIS GL window, I would make sure that a call to pfPWintype with a token of PFPWIN_TYPE_X isn't lurking somewhere in your code by accident. Under IRIS GL you should get a GL window by default. clay ______________________________ Reply Separator _________________________________ Subject: Don't know how to use keyboard in Perf 2.0 Author: Nuno Godinho at AAINTERNET Date: 4/10/96 12:05 PM Somehow I can't understand how to use the keyboard in my Perf 2.0 application. I tried to follow the complex.C example, used qdevice() to choose the keys I want queued and then copied the qtest() routine in GetGlInput() function. This didn't work: nothing happens qhen I press them. Qtest() always retuns 0. Can anyone teach a simple way to use the keyboard? Thanks Nuno From guest Wed Apr 10 14:40:57 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA06759; Wed, 10 Apr 1996 14:33:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA06756; Wed, 10 Apr 1996 14:33:35 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14070; Wed, 10 Apr 96 14:33:34 -0700 Received: from ht.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA24254; Wed, 10 Apr 1996 14:33:26 -0700 From: scott@ht.com (Scott McMillan) Received: by ht.com (940816.SGI.8.6.9/3.1.090690-High Techsplanations) id RAA03452; Wed, 10 Apr 1996 17:15:54 -0400 Message-Id: <199604102115.RAA03452@ht.com> Subject: Lighting stationary wrt to view -- how? To: info-performer@sgi.sgi.com Date: Wed, 10 Apr 1996 17:15:54 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2676 Status: O I am having a problem with a headlight attached to the viewing position, looking in the same direction as the view. Essentially, my app is flying inside a piece of geometry according to a constrained path. The viewpoint changes every frame. What i would like is a lightsource that lights whatever the camera is looking at with the ability to define falloffs - a miner's headlight if you will. I am using the C++ api and performer 2.0. My basic code fragment is: // set up the headlight - this is the only real light in the scene ViewState->headlight = new pfLightSource(); // make it a local light source - set at orgin for now ViewState->headlight->setPos(0.0f,0.0f,0.0f,1.0f); scene->addChild(ViewState->headlight); to initialize the light. The code that updates the view gets an eye point (eye) a lookat point (lookat) and an up point. After computing the new view matrix from these, I tried this approach: ViewState->headlight->setPos(eye[PF_X],eye[PF_Y],eye[PF_Z],1.0f); ViewState->headlight->setSpotDir(lookat[PF_X],lookat[PF_Y],lookat[PF_Z]); ViewState->headlight->setSpotCone(5.0f,55.0f); to move the light to the new pose. This did not work. The view pose works flawlessly, but the light remained at the origin (I saw it as I flew past). I then tried this idea for the move: ViewState->headlight->setPos(eye[PF_X],eye[PF_Y],eye[PF_Z],1.0f); pfPushIdentMatrix(); ViewState->headlight->setSpotDir(lookat[PF_X],lookat[PF_Y],lookat[PF_Z]); ViewState->headlight->setSpotCone(5.0f,90.0f); ViewState->headlight->on(); pfPopMatrix(); which also had no effect on the position or orientation. So I attempted to ensure that the light was not being culled by doing the following in the initialization stage: /* set a large empty sphere for the bounding sphere of the light, keeping it from being culled */ pfSphere * sph = new pfSphere(); sph->makeEmpty(); sph->radius = (float)PF_HUGEVAL; ViewState->headlight->setBound(sph,PFBOUND_STATIC); which again had no effect. My question is has anyone done this who would be willing to share code? Am I on the right track (and just have some small error), am I on a totally wrong track or is it a case of "this should work" and therefore there must be something else in my application which is causing the problem? Any help would be greatly appreciated. Thanks in advance, -- Paul Sherman Please CC responses to paul@ht.com as well...thanks. -- Scott McMillan / scott@ht.com / (301)984-3706 x250 / FAX (301)984-2104 High Techsplanations Inc. 6001 Montrose Road, Suite 902 / Rockville, MD 20852-4874 From guest Wed Apr 10 20:41:45 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id UAA12786; Wed, 10 Apr 1996 20:35:43 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id UAA12783; Wed, 10 Apr 1996 20:35:42 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03424; Wed, 10 Apr 96 20:35:40 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id UAA06137; Wed, 10 Apr 1996 20:35:33 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id NAA09774 (8.7.4/IDA-1.6); Thu, 11 Apr 1996 13:35:02 +1000 (EST) Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA28967 (5.65c/IDA-1.5); Thu, 11 Apr 1996 13:15:57 +1000 Received: from murad (murad [8.0.0.108]) by aggro with SMTP id NAA12275 (8.6.12/IDA-1.6); Thu, 11 Apr 1996 13:17:54 +1000 From: Simon Bennett Received: by murad (5.65) id AA12248; Thu, 11 Apr 1996 13:17:54 +1000 Message-Id: <9604110317.AA12248@murad> Subject: Re: Indigo2 Impact Channel Option (ICO) To: bleclerc@cae.ca (Bernard Leclerc) Date: Thu, 11 Apr 1996 13:17:54 +1000 (EST) Cc: gilroy@stlaurent.sgi.com, parviz@stlaurent.sgi.com, info-performer@sgi.sgi.com In-Reply-To: <9604101050.ZM7260@eagle.cae.ca> from "Bernard Leclerc" at Apr 10, 96 10:50:45 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Status: O > > First question: > > How many SVGA channels are generated by the ICO? > > I have 2 brochures describing the Impact product line. > One says the ICO can generate 4 SVGA channels, the other > says 2 -- on the Maximum Impact only. Which one is correct? No idea. But I bet somebody out there knows! > > Second question: > > Is full-screen anti-aliasing available when using SVGA on the ICO? >From a previous posting Sharon Clay answered...(wrt to can you multi-sample on an ICO) What you get is not multisampling but minification. Your display area (and thus your GL viewport) is twice the size of the video output and the full-channel image is filtered down as part of scan-out. This is all done independently of the GL which means that you do also have to change the sizes of things that have a pixel-specific size, such as lines, points, bitmaps, and pixel writes. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ +----------------------------------------------------------------------------+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 9981 0611 (x512) Common Sense doesn't seem to be From guest Thu Apr 11 02:42:55 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA13425; Thu, 11 Apr 1996 02:32:05 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA13422; Thu, 11 Apr 1996 02:32:03 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12530; Thu, 11 Apr 96 02:32:01 -0700 Received: from inesc.inesc.pt by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA29660; Thu, 11 Apr 1996 02:31:48 -0700 Received: from minerva.inesc.pt (minerva-2.inesc.pt) by inesc.inesc.pt with SMTP; id AA25887 (/); Thu, 11 Apr 1996 10:31:40 +0100 Received: from minerva (localhost) by minerva.inesc.pt (4.1/Sun OS 4.1.1) id AA14730; Thu, 11 Apr 96 10:31:40 +0100 Sender: mgo@minerva.inesc.pt Message-Id: <316CD17C.41C67EA6@minerva.inesc.pt> Date: Thu, 11 Apr 1996 10:31:40 +0100 From: Nuno Godinho X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: cstanek@smtpgate.sm.tsc.com Cc: info-performer@sgi.sgi.com Subject: Re: Don't know how to use keyboard in Perf 2.0 References: <9603108291.AA829164291@smtpgate.sm.tsc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O cstanek@smtpgate.sm.tsc.com wrote: > > if you want to render IRIS GL into a pure IRIS GL window, > I would make sure that a call to pfPWintype with a token of > PFPWIN_TYPE_X isn't lurking somewhere in your code by accident. > > Under IRIS GL you should get a GL window by default. > > clay THANKS!!! THERE WAS A PFPWIN_TYPE_X IN OUR CODE! YOU SOLVED OUR PROBLEM. Thank you From guest Thu Apr 11 10:57:55 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA14019; Thu, 11 Apr 1996 10:51:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA14016; Thu, 11 Apr 1996 10:51:31 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28459; Thu, 11 Apr 96 10:51:30 -0700 Received: from hope.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA21641; Thu, 11 Apr 1996 10:51:21 -0700 Received: by hope.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA05061; Thu, 11 Apr 1996 18:51:02 +0100 From: "David Hughes" Message-Id: <9604111851.ZM5059@hope.reading.sgi.com> Date: Thu, 11 Apr 1996 18:51:01 +0100 X-Face: 'o;%}vA_#p4#r[TsK@>S)pLuCNJ1W5`N\ANCBkVV^'PN,]cg?6M#mY0:MBUd%#:]N@q:mFn _S9?f3'#fyE4@.?9E.L0a@IT=prR\3$M}.Alj0UQ%X5Ne^pa,Id,5{.Rb\Ga's?|}A@9Oo*DY}/DPk Da@1o#u7JqrEoD;J|b?DHTw/seG9EK4-vsX'Y6iG|/[zvlux)Z{@ZNp2Aq4.i/w X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com, intl_vis_sim@cadillac Subject: Performer Users Group Meeting at ITEC Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O This is to announce that there will be a PERFORMER USERS GROUP MEETING ----------------------------- at ITEC 96 in The Hague, The Netherlands A users group meeting will be held for all parties and users interested in the development and status of IRIS Performer. This will be held in Committee Room 1 at 4:30pm on Tuesday 16th April. The meeeting is expected to last no longer than 90 min. It will be hosted by one of our key Perfmormer software engineers - Chris Tanner. This will present an opportunity to cover the following topics: ~ New features in 2.1 ~ Infinite Reality and Performer ~ Impact and Performer ~ Current software status ~ Product road map ~ Questions and issues Please contact reception at our booth #316 to register for this event -- ===================================================== | | | David Hughes - Reality Centre Manager | | Tel: [+44] 1 734 306222 (office) | | [+44] 1 734 257602 (direct) | | Vmail: 59413 | | email: davidh@reading.sgi.com | | | | http://www-europe.sgi.com/International/UK/centre | | | ===================================================== _______________ \ _______________________________ \_\__ / / _______________ / From guest Thu Apr 11 13:18:04 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA14734; Thu, 11 Apr 1996 13:09:28 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA14731; Thu, 11 Apr 1996 13:09:27 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06325; Thu, 11 Apr 96 13:09:26 -0700 Received: from buitre.madrid.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA12790; Thu, 11 Apr 1996 13:09:21 -0700 Received: by buitre.madrid.sgi.com (940816.SGI.8.6.9/930416.SGI) for info-performer@sgi.com id WAA29991; Thu, 11 Apr 1996 22:10:15 GMT From: "Luis Ignacio Miranda" Message-Id: <9604112210.ZM29987@buitre.madrid.sgi.com> Date: Thu, 11 Apr 1996 22:10:15 -0600 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Inventor loader problem Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19604112210.ZM29987.madrid.sgi.com" Status: O -- --PART-BOUNDARY=.19604112210.ZM29987.madrid.sgi.com Content-Type: text/plain; charset=us-ascii Hi all, I have a problem with the Inventor loader in Performer 2.0. When I try to load a model with a environment-reflecting texture, it loads the texture, but it is not applied to the model, or, it is not applied in the right way because the model does not show the texture. I attach a very simple inventor with a environment-reflecting texture model as an example. Any ideas? Thanks Nacho -- ******************************************************************************* * Luis Ignacio Miranda Edificio "Santa Engracia 120" * * Silicon Graphics, S.A. Plaza del Descubridor Diego de Ordas,3 * * Systems Engineering Division 28003 MADRID SPAIN * * e-mail : lmiranda@madrid.sgi.com Telephone ++ 34 1 4429077 * * v-mail : x57598 Fax ++ 34 1 4420150 * ******************************************************************************* --PART-BOUNDARY=.19604112210.ZM29987.madrid.sgi.com X-Zm-Content-Name: example.iv Content-Description: Inventor Content-Type: application/x-inventor ; name="example.iv" Content-Transfer-Encoding: base64 X-Zm-Decoding-Hint: mimencode -b -u I0ludmVudG9yIFYxLjAgYXNjaWkKCkdyb3VwIHsKICAgIExhYmVsIHsKICAgIH0KICAgIFNl cGFyYXRvciB7CglUcmFuc2Zvcm0gewoJICAgIHRyYW5zbGF0aW9uCS0wLjA0OTIzMjggMC4w ODUyODE0IDAuMDA4ODI2NjQKCSAgICByb3RhdGlvbgkwIDAgMSAgMAoJICAgIHNjYWxlRmFj dG9yCTEgMSAxCgkgICAgc2NhbGVPcmllbnRhdGlvbgkwIDAgMSAgMAoJICAgIGNlbnRlcgkw IDAgMAoJfQoJU2VwYXJhdG9yIHsKCSAgICBHcm91cCB7CgkJTGFiZWwgewoJCSAgICBsYWJl bAkic29saWQiCgkJfQoJCU1hdGVyaWFsIHsKCQkgICAgYW1iaWVudENvbG9yCTAuMTExNTg2 IDAuMTExNTg2IDAuMTExNTg2CgkJICAgIGRpZmZ1c2VDb2xvcgkwLjQ0NjM0NCAwLjQ0NjM0 NCAwLjQ0NjM0NAoJCSAgICBzcGVjdWxhckNvbG9yCTAuNDM1MDM1IDAuNDM1MDM1IDAuNDM1 MDM1CgkJICAgIGVtaXNzaXZlQ29sb3IJMCAwIDAKCQkgICAgc2hpbmluZXNzCTAuNDg4MDE3 CgkJICAgIHRyYW5zcGFyZW5jeQkwCgkJfQoJCVRleHR1cmUyIHsKCQkgICAgZmlsZW5hbWUJ Ii91c3Ivc2hhcmUvZGF0YS90ZXh0dXJlcy9zdXJmYWNlcy9icmljay4yLnJnYiIKCQkgICAg d3JhcFQJUkVQRUFUCgkJICAgIG1vZGVsCU1PRFVMQVRFCgkJICAgIHRyYW5zbGF0aW9uCTAg MAoJCSAgICBzY2FsZUZhY3RvcgkxIDEKCQkgICAgcm90YXRpb24JMAoJCSAgICBjZW50ZXIJ MC41IDAuNQoJCX0KCQlUZXh0dXJlQ29vcmRpbmF0ZUVudmlyb25tZW50IHsKCQl9CgkgICAg fQoJICAgIFNwaGVyZSB7CgkJcmFkaXVzCTAuMjU0NjY4CgkgICAgfQoJICAgIFNlcGFyYXRv ciB7CgkgICAgfQoJfQogICAgfQp9Cg== --PART-BOUNDARY=.19604112210.ZM29987.madrid.sgi.com-- From guest Thu Apr 11 14:06:47 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA15029; Thu, 11 Apr 1996 13:58:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA15026; Thu, 11 Apr 1996 13:58:50 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08792; Thu, 11 Apr 96 13:58:47 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA20418; Thu, 11 Apr 1996 13:58:41 -0700 Received: from poster.cae.ca (poster.cae.ca [142.39.22.1]) by bhole with SMTP (DuhMail/2.0) id QAA12598; Thu, 11 Apr 1996 16:55:27 -0400 Received: from zorglub.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA08739; Thu, 11 Apr 1996 16:53:42 -0400 Received: by zorglub.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA17222; Thu, 11 Apr 1996 16:53:20 -0400 Date: Thu, 11 Apr 1996 16:53:20 -0400 From: gagnonf@cae.ca (Francois Gagnon) Message-Id: <9604112053.AA17222@zorglub.cae.ca> To: info-performer@sgi.sgi.com Subject: Fonts in Performer 2.0 Status: O Hello everyone. I'm new to this mailing list and I have a question for all the Performer experts out there. I didn't find any mention of this topic in the FAQ and I hope that this subject has not been covered recently. I'm using Performer 2.0 and would like to display 3D text. The pfText, pfString and pfFont classes seem to be one way of creating the proper data structures in memory. However, short of creating my own font, the only available way to load a font is to use the pfdLoadFont_type1 routine for which there are only two provided fonts in the data directory of Performer. Are there public loaders available on the net ? Are there public fonts available on the net ? Thanks all. Francois Gagnon gagnonf@cae.ca From guest Thu Apr 11 15:01:24 1996 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA15576; Thu, 11 Apr 1996 14:52:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA15573; Thu, 11 Apr 1996 14:52:25 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12590; Thu, 11 Apr 96 14:52:24 -0700 Received: from amelnx.advmar.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA29158; Thu, 11 Apr 1996 14:52:14 -0700 From: Hill_Brian@amelnx.advmar.com Received: from cc:Mail by amelnx.advmar.com id AA829270435; Thu, 11 Apr 96 17:49:32 EST Date: Thu, 11 Apr 96 17:49:32 EST Message-Id: <9603118292.AA829270435@amelnx.advmar.com> To: info-performer@sgi.sgi.com Subject: Cross Platform OpenGL Performer (OpenPerformer) Status: O I have been developing Performer applications since 1.0 but wouldn't call myself a guru and don't know very much about the vis/sim world outside of Performer/SGI. There have been a lot of inquiries about developing low end applications running on other platforms. I don't have any real desire to do this but I see a market forming (or it is already formed) and I will have to be responsive to it to stay competitive (keep my job). I remember some discussion some time ago about an OpenPerformer. Are there any plans to produce such a product? What is this COSMO product and how does it relate to Performer? Does anyone know what is going on with this? Brian Hill hill_brian@advmar.com From guest Thu Apr 11 14:43:45 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA03896; Thu, 11 Apr 1996 14:40:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA03892; Thu, 11 Apr 1996 14:40:19 -0700 Received: from holodeck.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA11891; Thu, 11 Apr 96 14:40:18 -0700 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id OAA15448; Thu, 11 Apr 1996 14:40:13 -0700 Date: Thu, 11 Apr 1996 14:40:13 -0700 From: aschaffe@holodeck (Allan Schaffer) Message-Id: <199604112140.OAA15448@holodeck.asd.sgi.com> To: info-performer Subject: info-performer administrivia Status: O Hello all, The mailserver used for the info-performer mailing list (holodeck.asd.sgi.com) is moving this weekend. I've copied everything to another system temporarily, -so- if everything works right, you'll never notice. But if there are any troubles over the weekend with the 'normal' aliases, try sending mail directly to: info-performer@crusty.asd.sgi.com [for distribution] & info-performer-request@crusty.asd.sgi.com [for administration] ..or just hang tight 'till monday. thanks, Allan ---- Allan Schaffer aschaffe@sgi.com Silicon Graphics http://reality.sgi.com/aschaffe From guest Thu Apr 11 15:43:38 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA04317; Thu, 11 Apr 1996 15:40:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA04314; Thu, 11 Apr 1996 15:40:16 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA15652; Thu, 11 Apr 96 15:40:15 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA06855; Thu, 11 Apr 1996 15:40:08 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id XAA06413; Thu, 11 Apr 1996 23:38:56 +0100 From: "Angus Dorbie" Message-Id: <9604112338.ZM6411@bitch.reading.sgi.com> Date: Thu, 11 Apr 1996 23:38:55 +0100 In-Reply-To: gagnonf@cae.ca (Francois Gagnon) "Fonts in Performer 2.0" (Apr 11, 4:53pm) References: <9604112053.AA17222@zorglub.cae.ca> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: gagnonf@cae.ca (Francois Gagnon), info-performer@sgi.sgi.com Subject: Re: Fonts in Performer 2.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O pfdLoadFont_type1 is one instance of a font loader. It loads Haeberli font definitions into Performer structures. ^^^^^^^^ I'm not sure if I read this here or was told directly but the idea is to use one Paul Haeberlis tools to convert standard font descriptions to the intermediate format. I expect the convertors you require are in the developers toolbox. Rgds, Angus. On Apr 11, 4:53pm, Francois Gagnon wrote: > Subject: Fonts in Performer 2.0 > > > Hello everyone. > > I'm new to this mailing list and I have a question for all the > Performer experts out there. I didn't find any mention of this topic > in the FAQ and I hope that this subject has not been covered recently. > > I'm using Performer 2.0 and would like to display 3D text. The > pfText, pfString and pfFont classes seem to be one way of creating > the proper data structures in memory. However, short of creating my > own font, the only available way to load a font is to use the > pfdLoadFont_type1 routine for which there are only two provided fonts > in the data directory of Performer. > > Are there public loaders available on the net ? > Are there public fonts available on the net ? > > Thanks all. > > Francois Gagnon > gagnonf@cae.ca > > >-- End of excerpt from Francois Gagnon -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Thu Apr 11 16:34:25 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA05365; Thu, 11 Apr 1996 16:31:02 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA05362; Thu, 11 Apr 1996 16:30:59 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA18764; Thu, 11 Apr 96 16:30:58 -0700 Received: from ht.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA14228; Thu, 11 Apr 1996 16:30:43 -0700 Received: from te.ht.com by ht.com (940816.SGI.8.6.9/3.1.090690-High Techsplanations) id TAA02131; Thu, 11 Apr 1996 19:11:39 -0400 Received: by te.ht.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id TAA14879; Thu, 11 Apr 1996 19:11:40 -0400 From: "Paul Sherman" Message-Id: <9604111911.ZM14877@te.ht.com> Date: Thu, 11 Apr 1996 19:11:37 -0400 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: (Fwd) Re: Fonts in Performer 2.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Yep to all of the below. We did it in a recent app. Email me if you want more details and I will see if I can dig up the code. Paul Sherman paul@ht.com --- Forwarded mail from "Angus Dorbie" > Subject: Re: Fonts in Performer 2.0 > > pfdLoadFont_type1 is one instance of a font loader. It loads Haeberli > font definitions into Performer structures. ^^^^^^^^ > > I'm not sure if I read this here or was told directly but the idea is to use > one Paul Haeberlis tools to convert standard font descriptions to the > intermediate format. > > I expect the convertors you require are in the developers toolbox. > >On Apr 11, 4:53pm, Francois Gagnon wrote: >> Subject: Fonts in Performer 2.0 >> >> I'm using Performer 2.0 and would like to display 3D text. The >> pfText, pfString and pfFont classes seem to be one way of creating >> the proper data structures in memory. However, short of creating my >> own font, the only available way to load a font is to use the >> pfdLoadFont_type1 routine for which there are only two provided fonts >> in the data directory of Performer. >-- End of excerpt from Francois Gagnon ---End of forwarded mail from "Angus Dorbie" From guest Thu Apr 11 19:08:11 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA07680; Thu, 11 Apr 1996 19:05:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA07677; Thu, 11 Apr 1996 19:05:07 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA26639; Thu, 11 Apr 96 19:05:05 -0700 Received: from nypinet.nyp.ac.sg by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA01947; Thu, 11 Apr 1996 19:04:55 -0700 Received: from mgate.nyp.ac.sg. (mgate.nyp.ac.sg [202.12.95.26]) by nypinet.nyp.ac.sg (8.7.1/8.7.1) with SMTP id KAA29373 for ; Fri, 12 Apr 1996 10:05:52 +0700 (SST) Received: by mgate.nyp.ac.sg. with Microsoft Mail id <316E8D5B@mgate.nyp.ac.sg.>; Fri, 12 Apr 96 10:05:31 PDT From: "Ng Kian Bee, SIT/CS" To: performer Subject: Q: Where to buy these stuff.. Date: Fri, 12 Apr 96 10:02:00 PDT Message-Id: <316E8D5B@mgate.nyp.ac.sg.> Encoding: 34 TEXT X-Mailer: Microsoft Mail V3.0 Status: O Hello, This is not a technical question. Pls pardon me, I need to get some pointers from you guys to buy some stuff... We are interested in purchasing a 3D motion capture device and a 3D digitizer. I wonder who carries them? These devices must work well with our SGI RE2 and IMPACT machines. And we need it to work with software such as Coryphaeus Software, Performer, Alias | Wavefront, SoftImage. Appreciate if someone could send or fax us the products details and quotations. If there is an international office in Singapore, appreciate if someone could give us the email or fax or tel number. Another more urgent need is a good HMD. I need a HMD to work with Performer and hook up to our RE2. I wonder if anyone knows what brand works well and reliable and provide good support etc. Thank a million! Kian Bee ngkb@nyp.ac.sg Nanyang Polytechnic School of Information Technology 20 Yishun Ave 9 Singapore 768892 Tel: (65) 7501440 Fax: (65) 755 5571 From guest Thu Apr 11 19:23:41 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA07790; Thu, 11 Apr 1996 19:20:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA07787; Thu, 11 Apr 1996 19:20:49 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA27410; Thu, 11 Apr 96 19:20:47 -0700 Received: from farm.ddd.co.jp by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA03420; Thu, 11 Apr 1996 19:20:45 -0700 Received: from [202.230.84.102] by farm.ddd.co.jp (post.office MTA v1.9.3 evaluation license) with SMTP id AAA93 for ; Fri, 12 Apr 1996 11:21:34 +0900 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: kanou@ddd.co.jp (Y.Kanou) Subject: job opportunity To: info-performer@sgi.sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Date: Fri, 12 Apr 1996 11:21:34 +0900 Message-Id: <19960412022133831.AAA93@[202.230.84.102]> Status: O Wanted: 3D Computer Graphics programmers Responsibilities: Design & develop software for Silicon Graphics based applications. Requirements: Knowledge of OpenGL, Open Inventor, IRIS Performer, C, C++, UNIX. Company description: 3D,Inc.is a Japanese company which specializes in developing Realtime 3 Dimensional Computer Graphics Systems. Founded in 1988. The number of employees is 30. If interested, please mail, fax, or e-mail resumes to Yutaka Kanou 3D,Inc. Mitsuishi-Yokohama-building 1-39-3 Hiranuma Nishi-ku Yokohama 220 Japan e-mail:kanou@ddd.co.jp fax:+81-45-314-8335 From guest Fri Apr 12 00:23:47 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA11363; Fri, 12 Apr 1996 00:20:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA11360; Fri, 12 Apr 1996 00:20:36 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA05273; Fri, 12 Apr 96 00:20:33 -0700 Received: from public.bta.net.cn by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id AAA25455; Fri, 12 Apr 1996 00:20:21 -0700 From: flysiml@public.bta.net.cn Received: (from flysiml@localhost) by public.bta.net.cn (8.6.8.1/8.6.9) id PAA00846; Fri, 12 Apr 1996 15:15:46 +0800 Date: Fri, 12 Apr 1996 15:15:46 +0800 Message-Id: <199604120715.PAA00846@public.bta.net.cn> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: WHERE & HOW : .obj --> .flt To: info-performer@sgi.sgi.com, info-performer X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Hi Performers, 1. How to convert model files from .obj to .flt ? 2. Where is the converter on Internet ? Thanks ahead! flysiml@public.bta.net.cn From guest Fri Apr 12 00:23:51 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA11368; Fri, 12 Apr 1996 00:20:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA11365; Fri, 12 Apr 1996 00:20:43 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA05279; Fri, 12 Apr 96 00:20:41 -0700 Received: from public.bta.net.cn by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id AAA25548; Fri, 12 Apr 1996 00:20:36 -0700 From: flysiml@public.bta.net.cn Received: (from flysiml@localhost) by public.bta.net.cn (8.6.8.1/8.6.9) id PAA00846; Fri, 12 Apr 1996 15:15:46 +0800 Date: Fri, 12 Apr 1996 15:15:46 +0800 Message-Id: <199604120715.PAA00846@public.bta.net.cn> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: WHERE & HOW : .obj --> .flt To: info-performer@sgi.sgi.com, info-performer X-Mailer: SPRY Mail Version: 04.00.06.17 Status: O Hi Performers, 1. How to convert model files from .obj to .flt ? 2. Where is the converter on Internet ? Thanks ahead! flysiml@public.bta.net.cn From guest Fri Apr 12 00:39:44 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA11524; Fri, 12 Apr 1996 00:36:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA11521; Fri, 12 Apr 1996 00:36:39 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA05682; Fri, 12 Apr 96 00:36:37 -0700 Received: from mail.gmd.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id AAA26562; Fri, 12 Apr 1996 00:36:34 -0700 Received: from viswiz.gmd.de (viswiz) by mail.gmd.de with SMTP id AA25971 (5.67b8/IDA-1.5 for ); Fri, 12 Apr 1996 09:36:33 +0200 Received: by viswiz.gmd.de id AA22952 (5.67b8/IDA-1.5 for info-performer@sgi.sgi.com); Fri, 12 Apr 1996 09:36:31 +0200 From: Sina Mostafawy Message-Id: <199604120736.AA22952@viswiz.gmd.de> Subject: subscribe To: info-performer@sgi.sgi.com Date: Fri, 12 Apr 1996 09:36:31 +0200 (MDT) X-Mailer: ELM [version 2.4 PL24 ME7] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 49 Status: O please add me to the mailing list thanks Sina From guest Fri Apr 12 01:13:33 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA13106; Fri, 12 Apr 1996 01:10:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA13103; Fri, 12 Apr 1996 01:10:29 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA06682; Fri, 12 Apr 96 01:10:27 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA29660; Fri, 12 Apr 1996 01:10:25 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA06799; Fri, 12 Apr 1996 09:08:59 +0100 From: "Angus Dorbie" Message-Id: <9604120908.ZM6795@bitch.reading.sgi.com> Date: Fri, 12 Apr 1996 09:08:58 +0100 In-Reply-To: "Ng Kian Bee, SIT/CS" "Q: Where to buy these stuff.." (Apr 12, 10:02am) References: <316E8D5B@mgate.nyp.ac.sg.> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Ng Kian Bee, SIT/CS" , performer Subject: Re: Q: Where to buy these stuff.. Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19604120908.ZM6795.reading.sgi.com" Status: O --PART-BOUNDARY=.19604120908.ZM6795.reading.sgi.com Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u Here are two devices which work with SG equipment. The blurb is from the = 3rd parties, not me. Rgds, Angus. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~ FASTRAK=AE Motion Tracker FASTRAK=AE from Polhemus is the ultimate solution for real-time position/orientation sensing. FASTRAK has become the standard for VR and motion capture applications. FASTRAK virtually eliminates latency by util= izing state-of-the-art Digital Signal Processing (DSP) technology to reduce dat= a latency (lag) to 4ms. That is over 10 times faster than competitive syste= ms. It also has an update rate of up to 120 Hz, and can handle multiple receivers. All at a very competi= tive price!! E. W. Costello VP, Marketing & Sales Polhemus, Inc. One Hercules Drive P.O. Box 560 Colchester, VT 05446 USA 800-357-4777 802-655-1439 (fax) e_costello@polhemus.com For applications in related solution areas, see the following indices: Animation, Entertainment, Film & Video Production, Virtual Environments, Virtual Reality, the developer = index for Polhemus, Inc. and the product category index for Peripherals. RenderMan is a Registered Trademark of PIXAR 3DRAW is a Registered Trademark of Polhemus, Inc. FASTRAK is a Registered Trademark of Polhemus, inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~ Flock of Birds Flock of Birds is a modular tracker with six degrees of freedom for simultaneously tracking the position and orientation of 1 - 30 receivers (targets) over a specified range of plus or minus four feet. Motions are tracked to= accuracies of .2 degrees and .05 inch at rates up to 144Hz. Due to simult= aneous tracking, fast update rates and minimal lag occur even when multiple targ= ets are tracked. Designed for head and hand tracking in VR games, simulations, animations, and visualizations. Price: Starts at $2,695. Jack Scully Vice President Ascension Technology Corporation PO Box 527 Burlington, VT 05402 USA 802-860-6440 802-860-6439 (fax) ascension@world.std.com For applications in related solution areas, see the following indices: Ha= rdware Accessories, I/O Devices, Motion-capture, Simulation, Virtual Environments, Virtual Realit= y, the developer index for Ascension Technology Corporation and the product category index for Animation. Flock of Birds is a Trademark of Ascension ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~ On Apr 12, 10:02am, Ng Kian Bee, SIT/CS wrote: > Subject: Q: Where to buy these stuff.. > > Hello, > > This is not a technical question. Pls pardon me, I need to get some poi= nters > from you guys to buy some stuff... > > We are interested in purchasing a 3D motion capture device and a 3D > digitizer. > I wonder who carries them? These devices must work well with our SGI RE= 2 and > IMPACT machines. And we need it to work with software such as Coryphaeu= s > Software, Performer, Alias | Wavefront, SoftImage. > > Appreciate if someone could send or fax us the products details and > quotations. If there is > an international office in Singapore, appreciate if someone could give = us > the email or fax or > tel number. > > Another more urgent need is a good HMD. I need a HMD to work with Perfo= rmer > and hook up > to our RE2. I wonder if anyone knows what brand works well and reliable= and > provide good > support etc. > > Thank a million! > Kian Bee > ngkb@nyp.ac.sg > > Nanyang Polytechnic > School of Information Technology > 20 Yishun Ave 9 > Singapore 768892 > Tel: (65) 7501440 > Fax: (65) 755 5571 > >-- End of excerpt from Ng Kian Bee, SIT/CS -- = Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com --PART-BOUNDARY=.19604120908.ZM6795.reading.sgi.com-- From guest Fri Apr 12 01:50:16 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA13397; Fri, 12 Apr 1996 01:47:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA13394; Fri, 12 Apr 1996 01:47:19 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA07324; Fri, 12 Apr 96 01:47:17 -0700 Received: from vsl-fw.vsl.co.jp by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA02169; Fri, 12 Apr 1996 01:47:15 -0700 Received: from athens.vsl.co.jp (athens.vsl.co.jp [172.20.100.1]) by vsl-fw.vsl.co.jp (8.7.5/3.4W2MX) with SMTP id RAA01304 for ; Fri, 12 Apr 1996 17:47:13 +0900 (JST) Received: from dacca by athens.vsl.co.jp (5.65/3.3W9-uucp) id AA22734; Fri, 12 Apr 1996 17:47:12 +0900 Received: (from kamen@localhost) by dacca.vsl.co.jp (940816.SGI.8.6.9/3.4W2-indirect) id RAA04945 for info-performer@sgi.sgi.com; Fri, 12 Apr 1996 17:48:35 +0900 From: "Kamen Kanev" Message-Id: <9604121748.ZM4943@dacca> Date: Fri, 12 Apr 1996 17:48:35 +0900 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Texture problem on Maximum Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O We have a database in .iv format and would like to use it in Performer 2.0. When we load the databse in perfly the texture does not look smooth (not continuous collor but rather stripes of different collors). Same model when loaded in SceneViewer appears properly textured. In fact we can conterol the texture appearence in SceneViewer by changing the parameter TextureQuality e.g from 0.5 to 1 in the .iv file as follows: Complexity { value 1 TextureQuality 1 } What might be the problem? How can we modify the .iv file in order to get better texture appearence in perfly etc.? Any suggestions and help would be greatly appreciated. Thanks! -- __________________________________ Kamen Kanev, PhD Senior Researcher Visual Science Laboratory Awajicho MH Building 2-21 Kanda Awajicho Chiyoda-ku, Tokyo 101 JAPAN Phone: +81-3-5256-7662 FAX: +81-3-5256-1070 e-mail:kamen@vsl.co.jp __________________________________ From guest Fri Apr 12 02:30:04 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA13821; Fri, 12 Apr 1996 02:27:13 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA13818; Fri, 12 Apr 1996 02:27:11 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA07854; Fri, 12 Apr 96 02:27:10 -0700 Received: from barney.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id CAA04209; Fri, 12 Apr 1996 02:27:06 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id KAA05317; Fri, 12 Apr 1996 10:27:01 +0100 From: "Rob Jenkins" Message-Id: <9604121027.ZM5315@barney.reading.sgi.com> Date: Fri, 12 Apr 1996 10:27:00 +0100 In-Reply-To: "Kamen Kanev" "Texture problem on Maximum Impact" (Apr 12, 5:48pm) References: <9604121748.ZM4943@dacca> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Kamen Kanev" , info-performer@sgi.sgi.com Subject: Re: Texture problem on Maximum Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O What's the config of your machine ? Do /usr/gfx/gfxinfo - if you only have 1 TRAM then textures are only up to 4 bits per colour component so you can get banding on some textures. The way round this is the upgrade to 4 TRAMs which gives you more texture resolution and capacity. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. Forum 1, Station Road, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Fri Apr 12 06:28:11 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA16685; Fri, 12 Apr 1996 06:20:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA16682; Fri, 12 Apr 1996 06:20:49 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA11536; Fri, 12 Apr 96 06:20:48 -0700 Received: from flipper.pvv.unit.no by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA17658; Fri, 12 Apr 1996 06:20:40 -0700 Received: from datter.pvv.unit.no (20118@datter.pvv.unit.no [129.241.210.204]) by flipper.pvv.unit.no (8.6.12/8.6.12) with SMTP id PAA07194 for ; Fri, 12 Apr 1996 15:20:31 +0200 Received: by datter.pvv.unit.no ; Fri, 12 Apr 1996 15:20:26 +0200 Date: Fri, 12 Apr 1996 15:20:24 +0200 (MET DST) From: Morten Eriksen To: info-performer@sgi.sgi.com Subject: Drawing in overlay planes Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi, I've got an image which should behave as a "sprite" cursor in the overlay planes. This works OK with the code below, but the cursor "flashes" a lot - like gfx usually do when you try to update on wrong rasterpositions or updates are too slow. At first I thought the image I'm drawing (with rectwrite) was too big, but the same problem occurs even when it's just 16x16 pixels. I'm running this on an Onyx with RE2 gfx and 4 PUs, so I guess there's enough horsepower present.. The problem also occurs regardless of if I'm running in SP- or MP-mode. Here's the code I use to visualize it (it gets called during PostDraw): [SNIP] // Remember coordinates over invocations. static long xstart = 0; static long xstop = 0; static long ystart = 0; static long ystop = 0; // Erase old image. rectwrite(xstart, ystart, xstop, ystop, sharedmem->marker.store); // Draw some simple stuff here (max 9 pixels each frame). for(i = 0; i < sharedmem->replaycoordcounter; i++) { x = sharedmem->replaycoords[i][0] * sharedmem->mouse.winSizeX; y = sharedmem->replaycoords[i][1] * sharedmem->mouse.winSizeY; rectwrite(x-1, y-1, x+1, y+1, trace); } // Calculate new position for cursor. xstart = x - sharedmem->marker.xspot; ystart = y - sharedmem->marker.yspot; xstop = xstart + sharedmem->marker.width - 1; ystop = ystart + sharedmem->marker.height - 1; // Put underlying gfx in store buffer. rectread(xstart, ystart, xstop, ystop, sharedmem->marker.store); // Write cursor image. rectwrite(xstart, ystart, xstop, ystop, sharedmem->marker.bitmap); [SNIP] I assume my problem is due to sloppy timing - that 'PostDraw' is not a good time to draw this stuff..? I'd be grateful for any input on this. Regards, Morten Eriksen From guest Fri Apr 12 09:02:12 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA18843; Fri, 12 Apr 1996 08:55:02 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA18840; Fri, 12 Apr 1996 08:55:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA16408; Fri, 12 Apr 96 08:54:58 -0700 Received: from vsl-fw.vsl.co.jp by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA05696; Fri, 12 Apr 1996 08:54:23 -0700 Received: from athens.vsl.co.jp (athens.vsl.co.jp [172.20.100.1]) by vsl-fw.vsl.co.jp (8.7.5/3.4W2MX) with SMTP id AAA04565 for ; Sat, 13 Apr 1996 00:54:03 +0900 (JST) Received: from dacca by athens.vsl.co.jp (5.65/3.3W9-uucp) id AA26763; Sat, 13 Apr 1996 00:54:03 +0900 Received: (from kamen@localhost) by dacca.vsl.co.jp (940816.SGI.8.6.9/3.4W2-indirect) id AAA05926 for info-performer@sgi.com; Sat, 13 Apr 1996 00:55:27 +0900 From: "Kamen Kanev" Message-Id: <9604130055.ZM5924@dacca> Date: Sat, 13 Apr 1996 00:55:26 +0900 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfLookupNode() usage Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hello! Where can I find details about the usage of pfNode* pfLookupNode(const char *name, pfType* type); I would like to find a node given its unique name. Since I don't know where to start from pfNode* pfFindNode(pfNode *node, const char *pathName, pfType *type); is not suitable. The problem is that I also don't know the type of the node I am searching for. I tried to specify pfGetMemoryClassType() as a second argument in pfLookupNode() but it did not work. It works fine if I specify the exact type of the searched node e.g. child = pfLookupNode(filename, pfGetGeodeClassType()); Any suggestions would be greatly appreciated! Thanks in advance. -- __________________________________ Kamen Kanev, PhD Senior Researcher Visual Science Laboratory Awajicho MH Building 2-21 Kanda Awajicho Chiyoda-ku, Tokyo 101 JAPAN Phone: +81-3-5256-7662 FAX: +81-3-5256-1070 e-mail:kamen@vsl.co.jp __________________________________ From guest Fri Apr 12 09:29:18 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA19239; Fri, 12 Apr 1996 09:22:01 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA19236; Fri, 12 Apr 1996 09:21:59 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA17805; Fri, 12 Apr 96 09:21:57 -0700 Received: from sun4nl.NL.net by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA09815; Fri, 12 Apr 1996 09:21:34 -0700 Received: from alley.fel.tno.nl by sun4nl.NL.net with SMTP id AA21113 (5.65b/CWI-3.3); Fri, 12 Apr 1996 18:21:23 +0200 Received: from s00sn1.fel.tno.nl (s00sn1 [134.203.8.207]) by alley.fel.tno.nl (8.6.12/8.6.12) with ESMTP id SAA20616 for ; Fri, 12 Apr 1996 18:19:01 +0200 Received: (from rioj7@localhost) by s00sn1.fel.tno.nl (8.7.3/8.7.3) id SAA08120 for info-performer@sgi.com; Fri, 12 Apr 1996 18:19:21 +0200 (MET DST) From: Veraart Message-Id: <199604121619.SAA08120@s00sn1.fel.tno.nl> Subject: Re: Drawing in overlay planes To: info-performer@sgi.sgi.com (performer) Date: Fri, 12 Apr 1996 18:19:20 +0200 (MET DST) In-Reply-To: from "Morten Eriksen" at Apr 12, 96 03:20:24 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Status: O > I've got an image which should behave as a "sprite" cursor in the > overlay planes. This works OK with the code below, but the cursor > "flashes" a lot - like gfx usually do when you try to update on wrong > rasterpositions or updates are too slow. > > At first I thought the image I'm drawing (with rectwrite) was too big, > but the same problem occurs even when it's just 16x16 pixels. I'm > running this on an Onyx with RE2 gfx and 4 PUs, so I guess there's > enough horsepower present.. > > [SNIP] > > I assume my problem is due to sloppy timing - that 'PostDraw' is not a > good time to draw this stuff..? I'd be grateful for any input on this. Why don't you just draw on the screen and not the overlay plane if you draw the code every frame? Just draw your bitmap as if it where a HUD. For IRISGL you can use the following code pfGetChanSize(chan,&xSize,&ySize); sizeRatio = (float)xSize/(float)ySize; /* init state */ pfPushState(); pfBasicState(); zfunction(ZF_ALWAYS); ortho2(-sizeRatio, sizeRatio,-1.0f, 1.0f); // or choose some better mapping mmode(MVIEWING); pfPushIdentMatrix(); /* draw the stuff you want */ /* restore state */ zfunction(ZF_LEQUAL); pfPopMatrix(); pfPopState(); Hope this will be of any help to you. Mario From guest Fri Apr 12 10:03:15 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA19684; Fri, 12 Apr 1996 09:56:01 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA19681; Fri, 12 Apr 1996 09:55:59 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA19729; Fri, 12 Apr 96 09:55:58 -0700 Received: from flipper.pvv.unit.no by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA15528; Fri, 12 Apr 1996 09:55:54 -0700 Received: from datter.pvv.unit.no (20118@datter.pvv.unit.no [129.241.210.204]) by flipper.pvv.unit.no (8.6.12/8.6.12) with SMTP id SAA09920 for ; Fri, 12 Apr 1996 18:55:50 +0200 Received: by datter.pvv.unit.no ; Fri, 12 Apr 1996 18:55:45 +0200 Date: Fri, 12 Apr 1996 18:55:44 +0200 (MET DST) From: Morten Eriksen To: info-performer@sgi.sgi.com Subject: Re: Drawing in overlay planes In-Reply-To: <9604121713.ZM7567@bitch.reading.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Fri, 12 Apr 1996, Angus Dorbie wrote: > The problem is that you are not double buffering the overlay planes. Perhaps > doing this immediately after you swapbuffers() & a finnish() will help, it'll > be nearer the vertical retrace. There wouldn't happen to be a routine somewhere that makes it possible to read the current rasterline-position of the videobeam..? No? Thought not. :) > Do you have any other information in the overlay which you want to keep? Yep. See below. > Perhaps you don't need the first rectwrite & rectread. > > Do you have to do this in the overlay? If your drawing this as a draw callback > you'd be much better using rgb information and drawing to the framebuffer. > It'll be double buffered & you won't need to restore the old information. I'm using the overlay planes during replay to show the trace of how the user pointed a gun towards the screen during simulation. The problem is of course that there's no limit (well, that's not entirely true, there can't be more than width*height unique positions) to how many pixel positions I have to remember (in either a list or a storebuffer) and redraw each frame if I decide to use the regular bitplanes. Anyone out there who have wrestled with such a problem already? Anyway, the flickering cursor is just a minor problem - it isn't _too_ ugly to look at, so I guess I'll just leave it at that. Thanks for the help. Regards, Morten From guest Fri Apr 12 10:35:12 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA19930; Fri, 12 Apr 1996 10:27:46 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA19927; Fri, 12 Apr 1996 10:27:44 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA21682; Fri, 12 Apr 96 10:27:43 -0700 Received: from tuvok.mugu.navy.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA20099; Fri, 12 Apr 1996 10:27:28 -0700 Received: from qmsmtpgw.mugu.navy.mil (qmsendgw.mugu.navy.mil) by tuvok.mugu.navy.mil (4.1/SMI-4.1) id AA11368; Fri, 12 Apr 96 10:25:44 PDT Message-Id: Date: 12 Apr 1996 10:22:09 U From: "SCOTT OFRIEL" Subject: Problem Loading Some Object To: info-performer@sgi.sgi.com X-Mailer: Mail*Link SMTP/QM 3.0.0 Status: O Subject: Time: 10:15 AM OFFICE MEMO Problem Loading Some Objects Date: 4/12/96 Hello Everyone: We cannot understand why we can load "f18.obj" and see it clearly in our scene and not "f117.flt". The f117.flt model is invisible when we load it. The output from the file loader does not indicate any errors. When we use perfly to load the same f117.flt we see the object as expected. We tried scaling the object to a very large scale number to no avail. Any suggestions? Thanks, Scott O' From guest Sun Apr 14 13:44:49 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA04783; Sun, 14 Apr 1996 13:37:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA04780; Sun, 14 Apr 1996 13:37:44 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA27375; Sun, 14 Apr 96 13:37:43 -0700 Received: from holodeck.asd.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA10053; Sun, 14 Apr 1996 13:37:42 -0700 Received: by holodeck.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id NAA01946; Sun, 14 Apr 1996 13:37:39 -0700 From: aschaffe (Allan Schaffer) Message-Id: <9604141337.ZM1944@holodeck.asd.sgi.com> Date: Sun, 14 Apr 1996 13:37:39 -0700 In-Reply-To: "Kamen Kanev" "Texture problem on Maximum Impact" (Apr 12, 5:48pm) References: <9604121748.ZM4943@dacca> X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: "Kamen Kanev" , info-performer@sgi.sgi.com Subject: Re: Texture problem on Maximum Impact Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 12, 5:48pm, Kamen Kanev wrote: > > We have a database in .iv format and would like to use it in > Performer 2.0. When we load the databse in perfly the texture does > not look smooth (not continuous collor but rather stripes of > different collors). In addition to what Rob said: be sure that you have the appropriate set of IMPACT patches loaded, as several texture bugs have been fixed. At present, I believe you'll want "5.3 ALL IMPACT" as the base OS and patches 1098 & 1105. If you have XFS there are some others as well. If the problem is one of apparent quantization or mach-banding on the textures, you'll need more TRAM. But if it's truly "bad colors" then go with the patches. Allan -- Allan Schaffer aschaffe@sgi.com Silicon Graphics http://reality.sgi.com/aschaffe From guest Sun Apr 14 19:26:22 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA06485; Sun, 14 Apr 1996 19:19:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA06482; Sun, 14 Apr 1996 19:19:14 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA02417; Sun, 14 Apr 96 19:19:12 -0700 Received: from sgisgp2.singapore.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA26641; Sun, 14 Apr 1996 19:19:10 -0700 Received: by sgisgp2.singapore.sgi.com (940816.SGI.8.6.9/920502.SGI) for info-performer@sgi.sgi.com id KAA12985; Mon, 15 Apr 1996 10:19:35 +0800 From: "Vincent Oh Kim Soon" Message-Id: <9604151019.ZM12983@sgisgp2.singapore.sgi.com> Date: Mon, 15 Apr 1996 10:19:35 +0000 X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: HMD info? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi all, Could anyone out there pls tell me if there are any good HMDs available that are completely compatible with Performer running on an RE2. Any pointers in the right direction would suffice. Thanks in advance. Vincent -- Vincent Oh Senior Systems Engineer Technical Marketing Silicon Graphics Pte Ltd ASEAN Headquarters 89 Science Park Drive #03-02 to 06 The Rutherford Singapore 118261 e-mail : vincentoh@singapore.sgi.com v-mail : 57576 tel : (065) 777 3088 fax : (065) 779 3650 _______ _______ ________ / ____// / ____// /__ __// / //____ / //____ / // /____ // / ///_ // / // _____/ // / //_/ // __/ //__ /______// /______// /______// ///// @ @ ----------------------------------oOO-(_)-OOo------------------------------ /|||\ From guest Mon Apr 15 02:16:30 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA09454; Mon, 15 Apr 1996 02:09:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA09451; Mon, 15 Apr 1996 02:09:01 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA09485; Mon, 15 Apr 96 02:09:00 -0700 Received: from mail.gmd.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA18878; Mon, 15 Apr 1996 02:08:58 -0700 Received: from sumo.gmd.de (sumo) by mail.gmd.de with SMTP id AA13575 (5.67b8/IDA-1.5 for ); Mon, 15 Apr 1996 11:08:56 +0200 Received: by sumo.gmd.de id AA03844 (5.67b8/IDA-1.5 for info-performer@sgi.com); Mon, 15 Apr 1996 11:08:55 +0200 Date: Mon, 15 Apr 1996 11:08:55 +0200 From: Vali Lalioti Message-Id: <199604150908.AA03844@sumo.gmd.de> To: info-performer@sgi.sgi.com Status: O Dear Sirs, I have a problem with using two pipes and two screens on a machine that is set to the "triple keyboard option" (TKO). The warning I get is that there is no screen 1, which probably is true since with this option the displays are 0.0, 1.0,2.0 instead of 0.0, 0.1, 0.2. Is there any way to solve this problem? I include a small example and the error messages. sincerely yours, Dr. V. Lalioti. --------------------------- #include #include #include #include #include #include #include #include int main(int argc, char** argv) { pfInit(); pfMultiprocess( PFMP_APPCULLDRAW ); pfMultipipe(2); pfConfig(); pfWSConnection con0 = pfOpenScreen(0, FALSE); pfWSConnection con1 = pfOpenScreen(1, FALSE); pfPipe* pipe0 = pfGetPipe(0); pfPipe* pipe1 = pfGetPipe(1); pipe0->setScreen(0); pipe1->setScreen(1); pipe0->setWSConnectionName("sumo:0.0"); pipe1->setWSConnectionName("sumo:1.0"); printf("pipe0->getPipeScreen() = %d\n", pipe0->getScreen()); printf("pipe1->getPipeScreen() = %d\n", pipe1->getScreen()); printf("pipe0->getWSConnectionName() = %s\n", pipe0->getWSConnectionName()); printf("pipe1->getWSConnectionName() = %s\n", pipe1->getWSConnectionName()); pfPipeWindow* window0 = new pfPipeWindow(pipe0); window0->setWinType( PFPWIN_TYPE_X ); window0->setName( "I am on pipe 0" ); window0->setOriginSize(0, 0, 500, 500); window0->open(); pfPipeWindow* window1 = new pfPipeWindow(pipe1); window1->setWinType( PFPWIN_TYPE_X ); window1->setName( "I am on pipe 1" ); window1->setOriginSize(600, 0, 500, 500); window1->open(); pfScene* scene = new pfScene; pfGeode* geode = new pfGeode; pfGeoSet* gset = pfdNewCube(pfGetSharedArena()); scene->addChild(geode); geode->addGSet(gset); // pfEnable(PFEN_LIGHTING); // pfLight* light = new pfLight; // pfLightModel* lmodel = new pfLightModel; // lmodel->apply(); pfMaterial* material = new pfMaterial; // material->apply(); pfChannel* channel0 = new pfChannel(pipe0); pfChannel* channel1 = new pfChannel(pipe1); channel0->attach(channel1); channel0->setShare(channel0->getShare() | PFCHAN_SWAPBUFFERS); channel0->setFOV(45.0f, 0.0f); channel0->setNearFar(0.1f, 100.0f); channel0->setScene(scene); window0->addChan(channel0); window1->addChan(channel1); float drift = 0.04f; float xpos = -1.0f; while (1) { // this is it if (drift < 0.0f) { if (xpos < -1.0f) { drift = -drift; } } else { if (xpos > 1.0f) { drift = -drift; } } xpos += drift; pfVec3 pos(xpos, -6.0f, 0.0f); channel0->setView(pos, pfVec3(0.0f, 0.0f, 0.0f)); // light->setPos(pos[0], pos[1], pos[2], 1.0); // light->on(); pfFrame(); channel0->drawStats(); // channel1->drawStats(); } pfExit(); return 0; } ----------------- error messages PF Warning/Usage: pfPipe::setScreen() pfPipe 1 screen request of 1 is greater than number of available hardware screens (0 - 0). Clamping to screen 0 pipe0->getPipeScreen() = 0 pipe1->getPipeScreen() = 0 pipe0->getWSConnectionName() = sumo:0.0 pipe1->getWSConnectionName() = sumo:1.0 PF Notice: Using 50Hz video rate GL: X error 3, X request = 3 ERROR #93 Error in communication with window server: ERR_WMANIPC PF Notice: Caught SIGCHLD. Exiting due to death of child with pid 3827. From guest Mon Apr 15 04:12:22 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id EAA09967; Mon, 15 Apr 1996 04:05:19 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id EAA09964; Mon, 15 Apr 1996 04:05:17 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA11634; Mon, 15 Apr 96 04:05:15 -0700 Received: from rainich.dcs.ed.ac.uk by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id EAA24956; Mon, 15 Apr 1996 04:05:05 -0700 Received: from calvay.dcs.ed.ac.uk by rainich.dcs.ed.ac.uk with SMTP (PP); Mon, 15 Apr 1996 12:04:29 +0100 Date: Mon, 15 Apr 1996 12:04:17 +0100 (BST) From: Martin Reddy To: Performer List Subject: Finding Screen Coordinates Message-Id: Organisation: Department of Computer Science - University of Edinburgh Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I wish to use Performer for a number of psychophysical experiments I have to carry out. In order to do this, I must know the location and size of objects *on the display device*. I.e. I need to find the projected screen coordinates for an object. Specifically, I want the following: 1) The projected 2D screen coordinates for an object's (3D) position. (assuming the object lies within the viewing frustum) 2) The projected radius/diameter of an object's bounding sphere in pixels (as a quick measure of the object's size in screen space) I had a quick look through the mailing list archives and found a couple of other people asking similar things, but no answers given. Can anyone shed some light on how (or if) I can go about doing this? Cheers, Martin. +============================================================================+ | Martin Reddy Dept. of Computer Science | | University of Edinburgh | | e-mail : mxr@dcs.ed.ac.uk Mayfield Road, EH9 3JZ | | http://www.dcs.ed.ac.uk/home/mxr/ Tel : (0131) 650 5164 | +============================================================================+ From guest Mon Apr 15 05:15:06 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA10196; Mon, 15 Apr 1996 05:07:53 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA10193; Mon, 15 Apr 1996 05:07:50 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA13017; Mon, 15 Apr 96 05:07:48 -0700 Received: from lep.cs.gmr.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA28084; Mon, 15 Apr 1996 05:07:46 -0700 Received: by lep.cs.gmr.com (940816.SGI.8.6.9/940406.SGI) id IAA00627; Mon, 15 Apr 1996 08:07:02 -0400 From: "Larry Peruski" Message-Id: <9604150807.ZM625@lep.cs.gmr.com> Date: Mon, 15 Apr 1996 08:07:01 -0400 In-Reply-To: Vali Lalioti "" (Apr 15, 11:08am) References: <199604150908.AA03844@sumo.gmd.de> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Vali Lalioti , info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 15, 11:08am, Vali Lalioti wrote: > Subject: > Dear Sirs, > > I have a problem with using two pipes and two screens on a machine that > is set to the "triple keyboard option" (TKO). The warning I get is that > there is no screen 1, which probably is true since with this option > the displays are 0.0, 1.0,2.0 instead of 0.0, 0.1, 0.2. > Is there any way to solve this problem? > I include a small example and the error messages. > > sincerely yours, > Dr. V. Lalioti. > > --------------------------- > > #include > #include > #include > #include > #include > #include > #include > #include > > int > main(int argc, char** argv) > { > pfInit(); > pfMultiprocess( PFMP_APPCULLDRAW ); > pfMultipipe(2); > pfConfig(); > > pfWSConnection con0 = pfOpenScreen(0, FALSE); > pfWSConnection con1 = pfOpenScreen(1, FALSE); > > pfPipe* pipe0 = pfGetPipe(0); > pfPipe* pipe1 = pfGetPipe(1); > > pipe0->setScreen(0); > pipe1->setScreen(1); > > pipe0->setWSConnectionName("sumo:0.0"); > pipe1->setWSConnectionName("sumo:1.0"); > > printf("pipe0->getPipeScreen() = %d\n", pipe0->getScreen()); > printf("pipe1->getPipeScreen() = %d\n", pipe1->getScreen()); > > printf("pipe0->getWSConnectionName() = %s\n", > pipe0->getWSConnectionName()); > printf("pipe1->getWSConnectionName() = %s\n", > pipe1->getWSConnectionName()); > > pfPipeWindow* window0 = new pfPipeWindow(pipe0); > window0->setWinType( PFPWIN_TYPE_X ); > window0->setName( "I am on pipe 0" ); > window0->setOriginSize(0, 0, 500, 500); > window0->open(); > > pfPipeWindow* window1 = new pfPipeWindow(pipe1); > window1->setWinType( PFPWIN_TYPE_X ); > window1->setName( "I am on pipe 1" ); > window1->setOriginSize(600, 0, 500, 500); > window1->open(); > > pfScene* scene = new pfScene; > pfGeode* geode = new pfGeode; > pfGeoSet* gset = pfdNewCube(pfGetSharedArena()); > > scene->addChild(geode); > geode->addGSet(gset); > > // pfEnable(PFEN_LIGHTING); > > // pfLight* light = new pfLight; > > // pfLightModel* lmodel = new pfLightModel; > // lmodel->apply(); > > pfMaterial* material = new pfMaterial; > // material->apply(); > > pfChannel* channel0 = new pfChannel(pipe0); > pfChannel* channel1 = new pfChannel(pipe1); > channel0->attach(channel1); > channel0->setShare(channel0->getShare() | PFCHAN_SWAPBUFFERS); > > channel0->setFOV(45.0f, 0.0f); > channel0->setNearFar(0.1f, 100.0f); > channel0->setScene(scene); > > window0->addChan(channel0); > window1->addChan(channel1); > > float drift = 0.04f; > float xpos = -1.0f; > > > while (1) { > > // this is it > > if (drift < 0.0f) { > if (xpos < -1.0f) { > drift = -drift; > } > } else { > if (xpos > 1.0f) { > drift = -drift; > } > } > > xpos += drift; > > pfVec3 pos(xpos, -6.0f, 0.0f); > channel0->setView(pos, pfVec3(0.0f, 0.0f, 0.0f)); > // light->setPos(pos[0], pos[1], pos[2], 1.0); > // light->on(); > > pfFrame(); > channel0->drawStats(); > // channel1->drawStats(); > } > > pfExit(); > return 0; > } > > ----------------- error messages > PF Warning/Usage: pfPipe::setScreen() pfPipe 1 screen request of 1 is greater than number of available hardware screens (0 - 0). Clamping to screen 0 > pipe0->getPipeScreen() = 0 > pipe1->getPipeScreen() = 0 > pipe0->getWSConnectionName() = sumo:0.0 > pipe1->getWSConnectionName() = sumo:1.0 > PF Notice: Using 50Hz video rate > GL: X error 3, X request = 3 > ERROR #93 Error in communication with window server: ERR_WMANIPC > PF Notice: Caught SIGCHLD. Exiting due to death of child with pid 3827. > > >-- End of excerpt from Vali Lalioti I reported this same problem back in early Feb. I logged a support call and provided a source program similar to the one above. An SGI engineer was assigned but I never received a solution. It's a real simple question. How do you open a window on screen 1.0 or 2.0 using Performer 2.0 with TKO installed? I never had a problem with Performer 1.2. I have been busy with other things so I haven't forced this issue but I sure would like to know if there is an answer. -- Larry Peruski Sr Project Engineer Manufacturing & Design Systems Dept GM Research & Development Center 30500 Mound Road, Box 9055 Warren, Michigan 48090-9055 phone - (810) 986-1475 fax - (810) 986-9356 email - peruski@gmr.com From guest Mon Apr 15 05:25:03 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA10217; Mon, 15 Apr 1996 05:17:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA10214; Mon, 15 Apr 1996 05:17:49 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA13138; Mon, 15 Apr 96 05:17:48 -0700 Received: from tcsernet.tcs.ernet.in by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA28597; Mon, 15 Apr 1996 05:17:23 -0700 From: deepa@tcsernet.tcs.ernet.in Message-Id: <9604151753.AA00570@tcsernet.tcs.ernet.in> Subject: pfApply calls To: info-performer@tcsernet.tcs.ernet.in Date: Mon, 15 Apr 96 17:52:07 EDT Content-Length: 786 Content-Type: text X-Mailer: ELM [version 2.3 PL2] Status: O Dear Performer users, I wonder if anyone can help me understand the following: I am using Performer 1.2. I use the following calls to open pipe and initialize it: p = pfGetPipe(0); pfInitPipe(p, OpenPipeLine); If I use the following sequence of calls inside the OpenPipeLine procedure there is no problem. pfEnable(PFEN_LIGHTING); pfApplyLModel(pfNewLModel(NULL)); pfApplyMtl(pfNewMtl(NULL)); pfLightOn(pfNewLight(NULL)); On the other hand, if I use the above sequence of calls sfter the call pfInitPipe(p, NULL) in my main program, a core dump occurs. This happens only on the Onyx and not on the Indigo. Is it necessary that these calls be used only in the pipe initializing function? Deepa Krishnan Tata Consultancy Services Bombay e-mail : deepa@tcsernet.tcs.ernet.in From guest Mon Apr 15 06:59:00 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA10850; Mon, 15 Apr 1996 06:51:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA10845; Mon, 15 Apr 1996 06:51:41 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA14782; Mon, 15 Apr 96 06:51:39 -0700 Received: from trng3.orlando.coryphaeus.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id GAA05643; Mon, 15 Apr 1996 06:51:23 -0700 Received: by trng3.orlando.coryphaeus.com (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA07337; Mon, 15 Apr 1996 11:19:25 -0400 From: "Michael Butterworth" Message-Id: <9604151119.ZM7335@trng3.orlando.coryphaeus.com> Date: Mon, 15 Apr 1996 11:19:18 -0400 In-Reply-To: "Vincent Oh Kim Soon" "HMD info?" (Apr 15, 10:19am) References: <9604151019.ZM12983@sgisgp2.singapore.sgi.com> Reply-To: mbutterw@coryphaeus.com X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Vincent Oh Kim Soon" Subject: Re: HMD info? Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Check out n-vision of McLean, Virginia USA. They demonstrated their HMD technology with our (EasyScene from Coryphaeus Software) Performer based realtime application to NASA Kennedy Space Center in Florida last week. They have some great stuff. Here is the vital information below: n-vision Attn. Frank Wodoslawsky 7680 Old Springhouse Road Madison Building, First Floor McLean, Virginia 22102 703.506.8808 voice 703.903.0455 fax http://www.cais.com/nvision MB - Check out our Web page noted at the bottom of this message. On Apr 15, 10:19am, Vincent Oh Kim Soon wrote: > Subject: HMD info? > Hi all, > > > Could anyone out there pls tell me if there are any good HMDs available that > are completely compatible with Performer running on an RE2. Any pointers in the > right direction would suffice. Thanks in advance. > > > Vincent > > > > -- > Vincent Oh > Senior Systems Engineer > Technical Marketing > Silicon Graphics Pte Ltd > ASEAN Headquarters > 89 Science Park Drive #03-02 to 06 > The Rutherford > Singapore 118261 > e-mail : vincentoh@singapore.sgi.com > v-mail : 57576 > tel : (065) 777 3088 > fax : (065) 779 3650 > _______ _______ ________ > / ____// / ____// /__ __// > / //____ / //____ / // > /____ // / ///_ // / // > _____/ // / //_/ // __/ //__ > /______// /______// /______// ///// > @ @ > ----------------------------------oOO-(_)-OOo------------------------------ > /|||\ > > >-- End of excerpt from Vincent Oh Kim Soon -- Michael Butterworth Coryphaeus Software, Inc. mbutterw@coryphaeus.com 101 Southhall Lane, Suite 400 http://www.coryphaeus.com Maitland, FL 32751 Phone (407)667-4817 FAX (407)667-4816 From guest Mon Apr 15 08:30:22 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA11516; Mon, 15 Apr 1996 08:23:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA11513; Mon, 15 Apr 1996 08:23:25 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA16613; Mon, 15 Apr 96 08:23:24 -0700 Received: from wlv.iipo.gtegsc.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA15308; Mon, 15 Apr 1996 08:23:15 -0700 Received: from MX.IIPO.GTEGSC.COM (MX.IIPO.GTEGSC.COM [199.107.242.21]) by wlv.iipo.gtegsc.com (8.7.4/8.7.3) with SMTP id IAA08216 for ; Mon, 15 Apr 1996 08:21:16 -0700 (PDT) Received: by MX.IIPO.GTEGSC.COM with Microsoft Mail id <3172696B@MX.IIPO.GTEGSC.COM>; Mon, 15 Apr 96 08:21:15 PDT From: Stevens Torrey To: Performer Mailing List Subject: porting 1.2 - 2.0 Date: Mon, 15 Apr 96 08:19:00 PDT Message-Id: <3172696B@MX.IIPO.GTEGSC.COM> Encoding: 14 TEXT X-Mailer: Microsoft Mail V3.0 Status: O Hello all, We are porting from Performer 1.2 to 2.0, and were wondering if any of you could suggest some safe techniques in doing this. Should we install 2.0 to a separate directory something like that. We still want to use the 1.2 libraries but will the installation corrupt some environment variables ? Or anything like that ? Thanks for your help, Torrey Stevens GTE Government Systems torrey.stevens@mtv.gtegsc.com From guest Mon Apr 15 09:14:48 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA11970; Mon, 15 Apr 1996 09:07:30 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA11967; Mon, 15 Apr 1996 09:07:28 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA18293; Mon, 15 Apr 96 09:07:27 -0700 Received: from cs.utah.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA20900; Mon, 15 Apr 1996 09:07:23 -0700 Received: from real.cs.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs) id KAA25367; Mon, 15 Apr 1996 10:07:12 -0600 Received: by real.cs.utah.edu (940816.SGI.8.6.9/utah-2.15sun-leaf) id KAA25474; Mon, 15 Apr 1996 10:06:22 -0600 Date: Mon, 15 Apr 1996 10:06:22 -0600 From: dpugmire@real.cs.utah.edu (David Pugmire) Message-Id: <199604151606.KAA25474@real.cs.utah.edu> To: info-performer@sgi.sgi.com Subject: coplanar polys Status: O hi, I searched the FAQ and archive of selected topics and got a NULL. - I've heard that using coplanar polygons will give you a performance hit. I was looking for more information on it. Specifically, assuming I use the fastest mode, does 1 coplanar poly produce the same hit as man coplanar polys ? What is the correlation ? thanks, dp. From guest Mon Apr 15 09:28:31 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA12122; Mon, 15 Apr 1996 09:21:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA12119; Mon, 15 Apr 1996 09:21:12 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA18822; Mon, 15 Apr 96 09:20:56 -0700 Received: from firewall.cgsd.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id JAA22182; Mon, 15 Apr 1996 09:20:49 -0700 Received: from [192.9.200.107] ([192.9.200.107]) by firewall.cgsd.com (8.6.12/8.6.12) with SMTP id JAA20732; Mon, 15 Apr 1996 09:21:53 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Apr 1996 09:20:47 -0800 To: "Vincent Oh Kim Soon" , info-performer@sgi.sgi.com From: mckenna@cgsd.com (Gene McKenna) Subject: Re: HMD info? Status: O At 2:19 AM 4/15/96, Vincent Oh Kim Soon wrote: >Hi all, > > >Could anyone out there pls tell me if there are any good HMDs available that >are completely compatible with Performer running on an RE2. Any pointers in the >right direction would suffice. Thanks in advance. > > >Vincent In the August issue of our newsletter, Real Time Graphics, we have a survey of 40 different Head Mounted Displays. We can't comment, however of compatibility with Performer on RE2. GENE +-----------------------------------------------------+ | Gene McKenna | | mckenna@cgsd.com CGSD Corporation | | voice 415.903.4928 Software Engineer | | fax 415.967.5252 Webmaster www.cgsd.com | +-----------------------------------------------------+ From guest Mon Apr 15 09:46:12 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA12301; Mon, 15 Apr 1996 09:39:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA12298; Mon, 15 Apr 1996 09:38:58 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA20100; Mon, 15 Apr 96 09:38:56 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA25276; Mon, 15 Apr 1996 09:38:53 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA35226; Mon, 15 Apr 1996 12:32:53 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id MAA20246; Mon, 15 Apr 1996 12:30:59 -0400 From: "Bernard Leclerc" Message-Id: <9604151230.ZM20244@eagle.cae.ca> Date: Mon, 15 Apr 1996 12:30:54 -0400 In-Reply-To: Stevens Torrey "porting 1.2 - 2.0" (Apr 15, 8:19am) References: <3172696B@MX.IIPO.GTEGSC.COM> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Stevens Torrey , Performer Mailing List Subject: Re: porting 1.2 - 2.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 15, 8:19am, Stevens Torrey wrote: > We are porting from Performer 1.2 to 2.0, and were wondering if any of you > could suggest some safe techniques in doing this. Should we install 2.0 to a > separate directory something like that. We still want to use the 1.2 > libraries but will the installation corrupt some environment variables ? Or > anything like that ? Stevens, You mention you still want to use the 1.2 libraries. Do you want to continue developping with 1.2? Or, do you simply want to continue executing old 1.2 applications? If the later is sufficient, I suggest to simply replace pf1.2 with pf2.0 and to install performer_eoe.sw.performer1_2, the Performer 1.2 Compatibility DSOs. This will allow you to execute old 1.2 applications while you develop new one with pf2.0 BTW, pf2.0 has porting tools in /usr/share/Performer/src/tools Hope it helps... -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Mon Apr 15 10:30:07 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA12860; Mon, 15 Apr 1996 10:22:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA12857; Mon, 15 Apr 1996 10:22:40 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA23582; Mon, 15 Apr 96 10:22:39 -0700 Received: from nvl.army.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA03378; Mon, 15 Apr 1996 10:22:37 -0700 Received: by nvl.army.mil (Smail3.1.29.1 #7) id m0u8ryy-0002LWC; Mon, 15 Apr 96 13:22 EDT From: "Mary Williams" Message-Id: <9604151322.ZM37@ike> Date: Mon, 15 Apr 1996 13:22:32 -0400 Header.Main: mwilliam@nvl.army.mil X-Mailer: Z-Mail (3.2.1 6apr95 MediaMail) To: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O unsubscribe Thanks -- Mary M. Williams mwilliam@nvl.army.mil (703)704-1093 (Ft. Belvoir) (703)752-1824 (E-OIR) (703)752-2824 (FAX) From guest Mon Apr 15 11:32:04 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA13363; Mon, 15 Apr 1996 11:24:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA13360; Mon, 15 Apr 1996 11:24:29 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA27281; Mon, 15 Apr 96 11:24:27 -0700 Received: from popper.PBI.net by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA13208; Mon, 15 Apr 1996 11:24:23 -0700 Received: from poser.pbi.net by popper.PBI.net (4.1/PBI-12/1/95) id AA10054; Mon, 15 Apr 96 11:20:15 PDT Received: by poser.pbi.net (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id LAA10624; Mon, 15 Apr 1996 11:24:18 -0700 From: "Chris Cederwall" Message-Id: <9604151124.ZM10622@poser.pbi.net> Date: Mon, 15 Apr 1996 11:24:18 -0700 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Impact Patches Comment Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I finally have a functioning Impact. And I thought I'd send out a note with my success for other Impact Users. I had to install the following patches: - 1098 Xserver - 1105 GFX - showstopper #1 - 1157 hinv fix (the feel good patch of the season) I was a little frustrated by the performance of the Impact prior to these patches. But now every seems to be on track. I would like to request that news like that this get passed along from SGI participants whenever it is appropriate. The side comment from Allan Schaefer was what clued me in to the new set of patches! Cheers, -- Chris Cederwall - ceder@pbi.net - 415.442.4952 From guest Mon Apr 15 11:10:19 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA13217; Mon, 15 Apr 1996 11:02:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA13214; Mon, 15 Apr 1996 11:02:54 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA25962; Mon, 15 Apr 96 11:02:52 -0700 Received: from aleve.media.mit.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA10116; Mon, 15 Apr 1996 11:02:49 -0700 Received: from gin.media.mit.edu by aleve.media.mit.edu; (5.65/1.1/06Jun95-8.2MPM) id AA19831; Mon, 15 Apr 1996 14:02:04 -0400 From: David Small Received: by gin.media.mit.edu; (5.65v3.2/1.1.8.2/29Feb96-0246PM) id AA14056; Mon, 15 Apr 1996 14:01:46 -0400 Date: Mon, 15 Apr 1996 14:01:46 -0400 Message-Id: <9604151801.AA14056@gin.media.mit.edu> Apparently-To: info-performer@sgi.sgi.com Status: O unsubscribe thanks, dave From guest Mon Apr 15 12:30:00 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA13841; Mon, 15 Apr 1996 12:22:43 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA13838; Mon, 15 Apr 1996 12:22:42 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA01621; Mon, 15 Apr 96 12:22:40 -0700 Received: from uu9.psi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA21688; Mon, 15 Apr 1996 12:22:37 -0700 Received: from p3.enzian.com by uu9.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA22494 for info-performer@sgi.com; Mon, 15 Apr 96 15:22:12 -0400 Received: from ENZIAN_02/SpoolDir by P3.ENZIAN.COM (Mercury 1.13); Mon, 15 Apr 96 15:22:44 EST Received: from SpoolDir by ENZIAN_02 (Mercury 1.13); Mon, 15 Apr 96 15:22:14 EST From: "Bill Storma" To: info-performer@sgi.sgi.com Date: Mon, 15 Apr 1996 15:22:14 EDT Subject: Help locating USAF test chart X-Mailer: Pegasus Mail v3.22 Message-Id: <1FC9628466D@P3.ENZIAN.COM> Status: O I am trying the performer group to see if anyone has a copy of the USAF test chart which can be displayed on a REII system. Our compnay needs this pattern for screen resolution tests in conjunction with the delivery of the system to the U.S. Navy. Does anyone know of a source or have a copy that can be acquired for our use ? Thanks in advance. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bill Storma Phone: 407-282-1884 Enzian Technology FAX: 407-282-3013 Orlando, Fl. 32817 e-mail: bill@p3.enzian.com From guest Mon Apr 15 13:21:37 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA14196; Mon, 15 Apr 1996 13:14:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA14193; Mon, 15 Apr 1996 13:14:30 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA04086; Mon, 15 Apr 96 13:14:28 -0700 Received: from acusoft.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA29308; Mon, 15 Apr 1996 13:14:26 -0700 Received: from pwstripes by acusoft.com (5.x/SMI-SVR4) id AA14674; Mon, 15 Apr 1996 16:14:21 -0400 Received: by pwstripes (940816.SGI.8.6.9) id PAA04925; Mon, 15 Apr 1996 15:31:32 -0400 Date: Mon, 15 Apr 1996 15:31:32 -0400 (PDT) From: "Thomas M. Miller" X-Sender: miller@pwstripes To: info-performer@sgi.sgi.com Subject: Inheritance off pfObjects. In-Reply-To: <9604151124.ZM10622@poser.pbi.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Are there problems with inheritance off performer objects? For example if I was to implement a class in the following manner would it cause any problems? class DCS_ListElm : public pfDCS { public: DCS_ListElm *next, *prev; DCS_ListElm( void ) : pfDCS() { next = prev = NULL; } ~DCS_ListElm( void ) { if( next ) next->prev = prev; if( prev ) prev->next = next; } }; Please forgive the crudness of my example class. Would there be mal effects upon the deletion of an object of this class? In what manner should an object of this class be delete anyway, using the delete operator or pfDelete? Thanks, Thomas Miller IV --TMIV From guest Mon Apr 15 14:00:43 1996 Received: by crusty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA14478; Mon, 15 Apr 1996 13:52:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA14475; Mon, 15 Apr 1996 13:52:55 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA06099; Mon, 15 Apr 96 13:52:54 -0700 Received: from amelnx.advmar.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA05450; Mon, 15 Apr 1996 13:52:50 -0700 From: Hill_Brian@amelnx.advmar.com Received: from cc:Mail by amelnx.advmar.com id AA829612465; Mon, 15 Apr 96 16:44:35 EST Date: Mon, 15 Apr 96 16:44:35 EST Message-Id: <9603158296.AA829612465@amelnx.advmar.com> To: info-performer@sgi.sgi.com Subject: Cross Platform Performer (OpenPerformer) Status: O I sent this out last week and only received one reply. I expected more. I'll try this one more time and see what happens. Brian ______________________________ Forward Header __________________________________ I have been developing Performer applications since 1.0 but wouldn't call myself a guru and don't know very much about the vis/sim world outside of Performer/SGI. There have been a lot of inquiries about developing low end applications running on other platforms. I don't have any real desire to do this but I see a market forming (or it is already formed) and I will have to be responsive to it to stay competitive (keep my job). I remember some discussion some time ago about an OpenPerformer. Are there any plans to produce such a product? What is this COSMO product and how does it relate to Performer? Does anyone know what is going on with this? Brian Hill hill_brian@advmar.com From guest Mon Apr 15 15:13:39 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA01759; Mon, 15 Apr 1996 15:07:25 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA01756; Mon, 15 Apr 1996 15:07:24 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA15099; Mon, 15 Apr 1996 15:07:22 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA10719; Mon, 15 Apr 96 15:07:20 -0700 Received: from mred.bgm.link.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA18046; Mon, 15 Apr 1996 15:07:05 -0700 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA22141; Mon, 15 Apr 96 16:58:33 -0500 Date: Mon, 15 Apr 96 16:58:33 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9604152158.AA22141@mred.bgm.link.com> To: info-performer@sgi.sgi.com Subject: ROtation order. Status: O Does anyone out there have a set of routines to convert between each of the (six?) possible orders of rotation and the Performer convention? I have a host program that wants me to perform rotations in the order heading-pitch-roll, but Performer uses (I think) roll-pitch-heading. Since I'm really sick to death of hacking these on a case-by-case basis, it would be really nice to have a simple set of conversions. (It would be even nicer if pfMatrix knew how to do this...) Thanks in advance... Steve Steve Baker 817-323-1361 (Vox-Lab) Hughes Training Inc. 817-695-8776 (Vox-Office/vMail) 2200 Arlington Downs Road 817-695-4028 (Fax) Arlington, Texas. TX 76005-6171 steve@mred.bgm.link.com (eMail) From guest Mon Apr 15 16:00:52 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA02225; Mon, 15 Apr 1996 15:51:58 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA02222; Mon, 15 Apr 1996 15:51:57 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA15313; Mon, 15 Apr 1996 15:51:56 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA13841; Mon, 15 Apr 96 15:51:54 -0700 Received: from holodeck.csd.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA25631; Mon, 15 Apr 1996 15:51:53 -0700 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer@sgi.com id PAA02219; Mon, 15 Apr 1996 15:51:52 -0700 From: aschaffe (Allan Schaffer) Message-Id: <9604151551.ZM2217@holodeck.csd.sgi.com> Date: Mon, 15 Apr 1996 15:51:52 -0700 X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: [fwd] Cross Platform Performer (OpenPerformer) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O [This message bounced during the 'critical moment' of moving aliases around. Forwarding. -Allan] From: Hill_Brian@amelnx.advmar.com Date: Mon, 15 Apr 96 16:44:35 EST Message-Id: <9603158296.AA829612465@amelnx.advmar.com> To: info-performer@sgi.sgi.com I sent this out last week and only received one reply. I expected more. I'll try this one more time and see what happens. Brian ______________________________ Forward Header __________________________________ I have been developing Performer applications since 1.0 but wouldn't call myself a guru and don't know very much about the vis/sim world outside of Performer/SGI. There have been a lot of inquiries about developing low end applications running on other platforms. I don't have any real desire to do this but I see a market forming (or it is already formed) and I will have to be responsive to it to stay competitive (keep my job). I remember some discussion some time ago about an OpenPerformer. Are there any plans to produce such a product? What is this COSMO product and how does it relate to Performer? Does anyone know what is going on with this? Brian Hill hill_brian@advmar.com -- Allan Schaffer aschaffe@sgi.com Silicon Graphics http://reality.sgi.com/aschaffe From guest Mon Apr 15 16:05:20 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA02288; Mon, 15 Apr 1996 15:59:26 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA02285; Mon, 15 Apr 1996 15:59:24 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA15318; Mon, 15 Apr 1996 15:59:23 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA14213; Mon, 15 Apr 96 15:59:21 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA26824; Mon, 15 Apr 1996 15:59:20 -0700 Received: from hell.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA14210; Mon, 15 Apr 96 15:59:18 -0700 Received: by hell.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id PAA01747; Mon, 15 Apr 1996 15:59:17 -0700 From: "Don Hatch" Message-Id: <9604151559.ZM1745@hell.asd.sgi.com> Date: Mon, 15 Apr 1996 15:59:16 -0700 In-Reply-To: steve@mred.bgm.link.com (Steve Baker) "ROtation order." (Apr 15, 4:58pm) References: <9604152158.AA22141@mred.bgm.link.com> X-Face: /7QDEc=iPrsQG=j>iQo4F||T'ys-t--1bb9IJ9qo~4|i0nB|OG%gK}I3J2{/u*-q.I8=OSv/&K}V(pw:~5aIV!Y4:y+Vk#AAX)|i'B-jHf+r(?U'"B'9"D|<-(/1PD32tUN X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: steve@mred.bgm.link.com (Steve Baker), info-performer@sgi.sgi.com Subject: Re: ROtation order. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 15, 4:58pm, Steve Baker wrote: > Subject: ROtation order. > > Does anyone out there have a set of routines to convert between > each of the (six?) possible orders of rotation and the Performer convention? > > I have a host program that wants me to perform rotations in the > order heading-pitch-roll, but Performer uses (I think) roll-pitch-heading. > > Since I'm really sick to death of hacking these on a case-by-case basis, > it would be really nice to have a simple set of conversions. > (It would be even nicer if pfMatrix knew how to do this...) > > Thanks in advance... Take a look Ken Shoemake's article "Euler Angle Conversion" in Graphics Gems IV; I think it has everything you want an then some. Don -- Don Hatch hatch@sgi.com (415) 933-5150 Silicon Graphics, Inc. From guest Mon Apr 15 18:11:17 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA02906; Mon, 15 Apr 1996 18:04:48 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA02903; Mon, 15 Apr 1996 18:04:46 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA15942; Mon, 15 Apr 1996 18:04:45 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA20498; Mon, 15 Apr 96 18:04:43 -0700 Received: from evl.eecs.uic.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id SAA15420; Mon, 15 Apr 1996 18:04:32 -0700 Received: from zbox.eecs.uic.edu by evl.eecs.uic.edu via ESMTP (950215.SGI.8.6.10/940406.SGI.AUTO) for id UAA01611; Mon, 15 Apr 1996 20:04:06 -0500 Received: (swami@localhost) by zbox.eecs.uic.edu (8.6.12/8.6.4) id BAA13178; Tue, 16 Apr 1996 01:04:06 GMT Date: Mon, 15 Apr 1996 20:04:06 -0500 (CDT) From: Swaminathan To: info-performer@sgi.sgi.com Subject: SIGSEGV in pfGroup::nb_cull Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I am having problems reminiscient of the nb_clean() kind. I am loading a vrml scene into performer, and then bufferAddChild() all the respective inlines, with a corresponding pfBuffer::merge() after each addChild. The other suggestion of having a bounding sphere didnt work. The app runs almost all the time, except when I give demos :-). And I get the following in debugger when examining the core file. Core from signal SIGSEGV: Segmentation violation pfGroup::nb_cull() ["pfGroup.C":258, 0x5d47de14] Thanks Swami P.S. The call stack is as follows. pfGroup::nb_cull() ["pfGroup.C":258] pfSCS::nb_cull() ["pfSCS.C":308] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfSCS::nb_cull() ["pfSCS.C":259] pfSCS::nb_cull() ["pfSCS.C":308] pfSCS::nb_cull() ["pfSCS.C":308] pfGroup::nb_cull() ["pfGroup.C":247] pfScene::nb_cull() ["pfScene.C":269] _pfCuller::nb_cull() ["pfCuller.C":197] pfCull() ["pfProcess.C":3295] cbcull() ["pfChannel.C":60] pfChannel::pf_callCullFunc() ["pfChannel.C":1797] threadCull() ["pfProcess.C":3192] doCull() ["pfProcess.C":3244] doCullForkedDraw() ["pfProcess.C":3689] mpCull() ["pfProcess.C":3553] pfConfig() ["pfProcess.C":1630] main(argc = 1, argv = 0x7fffaf2c) ["cave6u.c++":74] __start() ["crt1text.s":133] From guest Mon Apr 15 18:21:07 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA02933; Mon, 15 Apr 1996 18:15:32 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA02930; Mon, 15 Apr 1996 18:15:30 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA16015; Mon, 15 Apr 1996 18:15:30 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA21073; Mon, 15 Apr 96 18:15:28 -0700 Received: from stobart.coryphaeus.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id SAA16618; Mon, 15 Apr 1996 18:15:17 -0700 Received: by stobart.coryphaeus.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id SAA21423; Mon, 15 Apr 1996 18:11:21 -0700 Date: Mon, 15 Apr 1996 18:11:21 -0700 From: burr@@sgi.sgi.com (Tim Burr) Message-Id: <9604151811.ZM21421@stobart.coryphaeus.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Subscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Please subscribe me to the performer mailing list. -- Timothy Burr | "Essence is that about a thing that makes Coryphaeus Software, Inc. | that thing what it is." burr@cory.coryphaeus.com | - existentialist food for thought - From guest Mon Apr 15 20:53:50 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id UAA03323; Mon, 15 Apr 1996 20:48:09 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id UAA03320; Mon, 15 Apr 1996 20:48:08 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA16992; Mon, 15 Apr 1996 20:48:07 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA25787; Mon, 15 Apr 96 20:48:05 -0700 Received: from mcenroe.cs.unc.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id UAA29805; Mon, 15 Apr 1996 20:48:02 -0700 Received: from neumann.cs.unc.edu by mcenroe.cs.unc.edu (8.6.10/UNC_06_21_94) id XAA12304; Mon, 15 Apr 1996 23:47:54 -0400 From: Hansong Zhang Received: by neumann.cs.unc.edu (8.6.10/UNC_06_21_94) id XAA13106; Mon, 15 Apr 1996 23:47:53 -0400 Message-Id: <199604160347.XAA13106@neumann.cs.unc.edu> Subject: custom draw() not called To: info-performer@sgi.sgi.com Date: Mon, 15 Apr 1996 23:47:53 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 867 Status: O Hello performers, I subclassed pfGeoSet and toke over the draw() function. In my test program, I add objects of the derived class to a pfGeode object. The problem is that pfGeoSet's draw() gets called instead of that of the derived class. When I use only libpr, myGeoSet->draw() is called explicitly and the whole thing works fine. Any suggestions? Thanks, Hansong - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - Hansong Zhang zhangh@www cs unc edu Walkthrough Group http://www.cs.unc.edu/~zhangh Department of Computer Science (919)962-1835 (O) UNC-Chapel Hill (919)914-3973 (H) "I create abstract systems from pure information, Albert. I'm the PROGRAMMER... Quantum nonlocality is a bug." -- God = == = == = == = == = == = == = == = == = == = == = == = == = From guest Mon Apr 15 21:21:42 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id VAA03384; Mon, 15 Apr 1996 21:16:18 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id VAA03381; Mon, 15 Apr 1996 21:16:17 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA17146; Mon, 15 Apr 1996 21:16:15 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA26340; Mon, 15 Apr 96 21:16:14 -0700 Received: from mcenroe.cs.unc.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id VAA01874; Mon, 15 Apr 1996 21:16:09 -0700 Received: from neumann.cs.unc.edu by mcenroe.cs.unc.edu (8.6.10/UNC_06_21_94) id AAA13036; Tue, 16 Apr 1996 00:16:08 -0400 From: Hansong Zhang Received: by neumann.cs.unc.edu (8.6.10/UNC_06_21_94) id AAA13274; Tue, 16 Apr 1996 00:16:04 -0400 Message-Id: <199604160416.AAA13274@neumann.cs.unc.edu> Subject: Re: custom draw() not called To: info-performer@sgi.sgi.com Date: Tue, 16 Apr 1996 00:16:03 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1295 Status: O Hello performers, I came to see that pfGeoSet::draw() is not a virtual function. and thus the problem. Now the question is wether there's any workaround. (this is a C++ question rather than a performer question.) Any suggestion is appreciated... Thanks, Hansong p.s. An "easy" solution might be for some nice performer group member to modify the definition of draw() in pfGeoSet.h, recompile pfGeode and pfGeoSet, and let me have the new .o files. Is this possible? > I subclassed pfGeoSet and toke over the draw() function. In my > test program, I add objects of the derived class to a pfGeode > object. The problem is that pfGeoSet's draw() gets called > instead of that of the derived class. > > When I use only libpr, myGeoSet->draw() is called explicitly and the > whole thing works fine. - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - Hansong Zhang zhangh@www cs unc edu Walkthrough Group http://www.cs.unc.edu/~zhangh Department of Computer Science (919)962-1835 (O) UNC-Chapel Hill (919)914-3973 (H) "I create abstract systems from pure information, Albert. I'm a *programmer*... Quantum nonlocality is a bug." -- God = == = == = == = == = == = == = == = == = == = == = == = == = From guest Mon Apr 15 23:04:46 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id WAA03634; Mon, 15 Apr 1996 22:58:32 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id WAA03631; Mon, 15 Apr 1996 22:58:30 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA17770; Mon, 15 Apr 1996 22:58:28 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA28280; Mon, 15 Apr 96 22:58:27 -0700 Received: from vsl-fw.vsl.co.jp by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA08417; Mon, 15 Apr 1996 22:58:23 -0700 Received: from athens.vsl.co.jp (athens.vsl.co.jp [172.20.100.1]) by vsl-fw.vsl.co.jp (8.7.5/3.4W2MX) with SMTP id OAA28698; Tue, 16 Apr 1996 14:58:20 +0900 (JST) Received: from easter by athens.vsl.co.jp (5.65/3.3W9-uucp) id AA30546; Tue, 16 Apr 1996 14:58:20 +0900 Message-Id: <9604160557.AA00104@rydeen.vsl.co.jp> Date: Tue, 16 Apr 1996 14:57:23 +0900 From: Takayuki Kondo To: 3D@softimage.com, support@softimage.com, info-performer@sgi.sgi.com Cc: kondo@vsl.co.jp, kamen@vsl.co.jp Subject: Softimage to Performer animation data X-Mailer: AL-Mail 1.12 Status: O We would like to generate animation data in Softimage and export it to GSI Performer. We are writing a Softimage channel driver to create an appropriate file. How should we interpret the values for RotX, RotY and RotZ? Are these rotations appiled to a global coordinate system or to a local one associated with the moving object and in what order? More precisely if we rotate (1) around X and (2) around Z then around which Z should we rotate: the global one or the one resulting from the initial X rotation (the local one). Any suggestions would be greatly appreciated! Thanks. ---------------- Takayuki Kondo MM-VSL, Tokyo Japan From guest Tue Apr 16 00:22:31 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id AAA03794; Tue, 16 Apr 1996 00:15:35 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA03791; Tue, 16 Apr 1996 00:15:33 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA18229; Tue, 16 Apr 1996 00:15:32 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA29501; Tue, 16 Apr 96 00:15:31 -0700 Received: from listserv.esi.es by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id AAA13349; Tue, 16 Apr 1996 00:15:28 -0700 Received: from esi.es (OFFICE.esi.es) by listserv.esi.es (5.0/SMI-SVR4) id AA17264; Tue, 16 Apr 1996 09:15:29 --100 Received: from OFFICE/MERCURY by esi.es (Mercury 1.21); 16 Apr 96 09:14:56 GMT+0100 Received: from MERCURY by OFFICE (Mercury 1.21); 16 Apr 96 09:14:10 GMT+0100 Received: from VISTA95.esi.es by esi.es (Mercury 1.21); 16 Apr 96 09:13:48 GMT+0100 Message-Id: <3173492D.514C@esi.es> Date: Tue, 16 Apr 1996 09:15:57 +0200 From: Stefan Schuster Organization: ESI X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: info-performer@sgi.sgi.com Subject: Alias 2 Performer animation converter Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Length: 173 Status: O Does anyone know if there exists a tool that allows to transform/convert animations created in Alias Wavefront to Performer 2.0 ? Any hint=B4s appreciated. Thanks, Stefan From guest Tue Apr 16 04:58:09 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id EAA04070; Tue, 16 Apr 1996 04:52:17 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id EAA04067; Tue, 16 Apr 1996 04:52:15 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id EAA19468; Tue, 16 Apr 1996 04:52:14 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA03223; Tue, 16 Apr 96 04:52:12 -0700 Received: from stork.cf.ac.uk by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id EAA27726; Tue, 16 Apr 1996 04:50:51 -0700 Received: from thor.cf.ac.uk by stork.cf.ac.uk with SMTP (PP); Tue, 16 Apr 1996 12:48:16 +0100 Received: (from saprar@localhost) by thor.cf.ac.uk (8.7.4/8.6.12) id MAA13180; Tue, 16 Apr 1996 12:48:49 +0100 (BST) Date: Tue, 16 Apr 1996 12:48:48 +0100 (BST) From: ROY RUDDLE Reply-To: Ruddle@cardiff.ac.uk To: info-performer@sgi.sgi.com Subject: Loading textures on an RE Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O This must have a simple answer, but I can't find it anywhere: As I'm running a small DB I want to force all textures to be loaded into the RE's texture memory while (or just after) the DB is loaded. I've got plenty of texture memory. At the moment (ie. by default) textures are being paged in when they first get displayed. Does anyone know the answer? cheers roy From guest Tue Apr 16 07:02:17 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA04261; Tue, 16 Apr 1996 06:56:57 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA04258; Tue, 16 Apr 1996 06:56:56 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA20022; Tue, 16 Apr 1996 06:56:54 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA05303; Tue, 16 Apr 96 06:56:51 -0700 Received: from stealth.afit.af.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA07851; Tue, 16 Apr 1996 06:56:28 -0700 Received: from louvre.afit.af.mil (gallery.afit.af.mil [129.92.100.126]) by stealth.afit.af.mil (8.7.5/8.7.3) with ESMTP id JAA24326; Tue, 16 Apr 1996 09:55:54 -0400 (EDT) Received: from rembrandt.afit.af.mil (rembrandt [129.92.101.112]) by louvre.afit.af.mil (8.6.12/8.6.12) with ESMTP id QAA05781; Tue, 16 Apr 1996 16:54:44 GMT Received: (gewillia@localhost) by rembrandt.afit.af.mil (8.6.12/8.6.12) id QAA07564; Tue, 16 Apr 1996 16:55:03 GMT From: "Gary E Williams" Message-Id: <9604161255.ZM7562@rembrandt.afit.af.mil> Date: Tue, 16 Apr 1996 12:55:03 -0400 In-Reply-To: ROY RUDDLE "Loading textures on an RE" (Apr 16, 12:48pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Ruddle@cardiff.ac.uk Subject: Re: Loading textures on an RE Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Roy, I must qualify my suggestion with the disclaimer that I'm still a relative novice to Performer myself and I hope someone with more knowledge posts a better /more complete solution, but I'll give you what I've got. We have a large solar system simulation which uses texture maps for planets, moons, asteroids, and even some satellites. We use object oriented programming techniques with C++, i.e. all of our models are objects. The main rountine constructor allocates memory for all the instances of our objects and we load the models in the simulation initialization phase which is called shortly after the constructor is executed. After we've initialized the simulation, we execute the following code: Players_Texture_List = pfuMakeTexList ( (pfNode *)(Renderobj->players)); where Renderobj->players is the node in the Performer tree above all the models. This builds a list of all textures used in the simulation so the textures are loaded before the simulation runs. As a result, the textures are already in memory and we don't have the "stalls" during execution to load them. I hope this helps and if anyone else cares to add to anything I've said, please feel free - I'm always glad to gain a better understanding of how things work. Good luck. Gary -- ************************************************************* GARY E. WILLIAMS, Capt, USAF MS Student: Modeling & Simulation Air Force Institute of Techonology (AFIT) gewillia@afit.af.mil http://www.afit.af.mil/ENGgraphics/people/gewillia/index.html From guest Tue Apr 16 07:10:46 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA04276; Tue, 16 Apr 1996 07:05:46 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA04273; Tue, 16 Apr 1996 07:05:45 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA20099; Tue, 16 Apr 1996 07:05:43 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA05464; Tue, 16 Apr 96 07:05:41 -0700 Received: from artcom.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA08694; Tue, 16 Apr 1996 07:05:25 -0700 Received: from hertie by artcom.de with smtp id m0u9BTT-0000POC; Tue, 16 Apr 96 16:11 MET DST Sender: crux@artcom.de Message-Id: <3173A897.167E@artcom.de> Date: Tue, 16 Apr 1996 16:03:03 +0200 From: Dirk Luesebrink Organization: D-FACTS bv X-Mailer: Mozilla 3.0b2 (X11; I; IRIX 5.3 IP19) Mime-Version: 1.0 To: info-performer@sgi.sgi.com Subject: limit coredumpsize 0 Was: Re: mp problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Michael Jones writes: :First, making a directory named "core" in the directory where you :execute :your application will get you out of the "my core file is too big" :state. maybe a little bit off the topic, but i have seen this kind of ideas to avoid unnecessary core dump files. especially from softimage users :-) mkdir core or touch core; chmod 000 core i recommend: limit coredumpsize 0 // disable limit coredumpsize unlimited // enable as alias: alias lim "limit coredumpsize 0" and alias ulim "limit coredumpsize unlimited" makes it quite easy to switch on per shell level from coredumping to not coredumping. i mp mode perfomer is still able to create a file of 512 kb. but thats no harm, even when i have no idea how its happening. dirk. ps.:p for "normal" users, the adminstrater can put lim in the system wide csh.cshrc, because i dont think they ever need a core dump. From guest Tue Apr 16 07:47:56 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA04457; Tue, 16 Apr 1996 07:42:49 -0700 Return-Path: Received: from crusty.asd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA04454; Tue, 16 Apr 1996 07:42:48 -0700 Received: from giraffe.asd.sgi.com by crusty.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA20261; Tue, 16 Apr 1996 07:42:46 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@crusty.asd.sgi.com id AA06359; Tue, 16 Apr 96 07:42:45 -0700 Received: from phoenix.eai.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA12587; Tue, 16 Apr 1996 07:42:43 -0700 From: carter@eai.com Received: by phoenix.eai.com (940816.SGI.8.6.9/940406.SGI.AUTO) for <@phoenix.eai.com:info-performer@sgi.sgi.com> id JAA10601; Tue, 16 Apr 1996 09:46:12 -0500 Received: from vortex.eai.com(192.186.203.8) by phoenix.eai.com via smap (V1.3) id sma010586; Tue Apr 16 09:45:47 1996 Received: from granite.eai.com by vortex.eai.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA05691; Tue, 16 Apr 1996 09:45:39 -0500 Received: by granite.eai.com (940816.SGI.8.6.9) id JAA06866; Tue, 16 Apr 1996 09:45:38 -0500 Message-Id: <199604161445.JAA06866@granite.eai.com> Subject: OpenPerformer & Vis/Sim outside SGI To: info-performer@sgi.sgi.com Date: Tue, 16 Apr 1996 09:45:38 -0600 (CDT) Cc: carter@vortex.eai.com (2370) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 3023 Status: O I have a couple of things to say on the subject of the Vis/Sim world outside SGI. SGI seems to me largely responsible for developing and driving the field of commercial visual simulation over the past five years or so. They've done so with the excellent RE product line, and the well thought-out Performer library. Others have been slow to catch on. SGI has been alone on the battlefield for so long (so to speak) that _perhaps_ it hasn't had the opportunity to build up its own corporate self-confidence with respect to competing with others. Now, the world is rapidly taking on a different hue with respect to the market for visual simulation. No longer is SGI completely alone in its offerings of HW and SW to this market. Now that other competent graphics hardware is entering the mainstream market on platforms such as HP and Sun, where does that leave SGI with respect to visual simulation on those platforms? Here are some possible, though perhaps extreme, postures SGI might adopt: 1. IBM-style "do it our way or do it all yourself": Performer remains a closed product tied to the SGI platform, and other vendor's customers must invent all their visual simulation applications from scratch. This has the advantage of minimizing "leakage" of the customer base away from the SGI platform, but it makes it very difficult for SGI to win customers away from other vendors -- they would have to rewrite their applications yet again for the platforms whose policy forced them to write it from scratch in the first place! Not to mention that the last time I heard the official policy from SGI (Dev Forum '95), it was "SGI is a hardware company, not a software company. We are interested in selling SGI boxes." Of course, that was before the acquisition of Alias and Wavefront. :-) 2. OpenGL-style: SGI takes the high road and places its hardware and support into direct, level, fair, head-to-head competition with HP, Sun, E&S and anyone else who feels that they have the "grambaugh" to tangle with the inventors of visual simulation, and the leaders in commercial hardware rendering! OpenPerformer. This has the added advantage that the sales force can compete to "convert" customers from other platforms to SGI. The market for visual simulation on platforms other than SGI is not growing, it is *HERE* ***NOW***!!! The market is *not* standing still waiting to see if SGI will open up performer. Both HP and Sun have competent graphics products available NOW. You can bet that they have announcements of excellent products on the way. Both have the strategic advantage of being MUCH larger organizations than SGI. Both have the distinct tactical disadvantage that they are now trying to break into SGI's home turf. SGI is at a critical policy crossroads: it can finesse the entire market into playing by ITS rules (by opening Performer), or it can leave Performer a proprietary library and let the market decide whose rules to play by. From guest Tue Apr 16 09:38:28 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA04793; Tue, 16 Apr 1996 09:30:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA04790; Tue, 16 Apr 1996 09:30:40 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA10333; Tue, 16 Apr 96 09:30:38 -0700 Received: from ht.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA27509; Tue, 16 Apr 1996 09:30:26 -0700 Received: from er.ht.com by ht.com (940816.SGI.8.6.9/3.1.090690-High Techsplanations) id MAA07931; Tue, 16 Apr 1996 12:25:32 -0400 Received: by er.ht.com (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA00991; Tue, 16 Apr 1996 12:25:30 -0400 From: scott@er.ht.com (Scott McMillan) Message-Id: <199604161625.MAA00991@er.ht.com> Subject: Re: ROtation order. To: steve@mred.bgm.link.com (Steve Baker) Date: Tue, 16 Apr 1996 12:25:30 -0400 (EDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <9604152158.AA22141@mred.bgm.link.com> from "Steve Baker" at Apr 15, 96 04:58:33 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2121 Status: O > Does anyone out there have a set of routines to convert between > each of the (six?) possible orders of rotation and the Performer convention? Actually 12 or 24 combinations depending on who you talk to. > I have a host program that wants me to perform rotations in the > order heading-pitch-roll, but Performer uses (I think) roll-pitch-heading. This should not be an issue. The short answer is don't use Performer pfCoords, and do something like the following where the desired matrix is computed directly: pfMatrix tx_mat1, tx_mat2; float angle[3]; // set elsewhere -- three euler angles in degrees tx_mat2.preRot(angle[0], 0.0, 0.0, 1.0, tx_mat1); // psi about Z tx_mat1.preRot(angle[1], 0.0, 1.0, 0.0, tx_mat2); // theta about Y tx_mat2.preRot(angle[2], 1.0, 0.0, 0.0, tx_mat1); // phi about X dcs_node->setMat(tx_mat2); If you really want to get the Performer hpr's from this do the following: pfCoord coord; tx_mat2.getOrthoCoord(&coord); This is not the most efficient way to convert from an arbitrary set of Euler angles to Performer's hpr's but it works. An algorithm for direct conversion from each of the twelve combinations to HPR would have to be worked out on a case by case basis. Robotics books by Craig and Fu, Gonzales, and Lee give the mathematically grounding to develop these algorithms...it is a simplified inverse kinematics algorithm. > Since I'm really sick to death of hacking these on a case-by-case basis, > it would be really nice to have a simple set of conversions. > (It would be even nicer if pfMatrix knew how to do this...) > > Thanks in advance... > > Steve > > > > Steve Baker 817-323-1361 (Vox-Lab) > Hughes Training Inc. 817-695-8776 (Vox-Office/vMail) > 2200 Arlington Downs Road 817-695-4028 (Fax) > Arlington, Texas. TX 76005-6171 steve@mred.bgm.link.com (eMail) > > -- Scott McMillan / scott@ht.com / (301)984-3706 x250 / FAX (301)984-2104 High Techsplanations Inc. 6001 Montrose Road, Suite 902 / Rockville, MD 20852-4874 From guest Tue Apr 16 09:52:18 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA04814; Tue, 16 Apr 1996 09:44:13 -0700 Return-Path: Received: from kern.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA04811; Tue, 16 Apr 1996 09:44:12 -0700 Received: by kern.csd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer id JAA11442; Tue, 16 Apr 1996 09:44:12 -0700 From: indu@kern (Indu Bingham) Message-Id: <199604161644.JAA11442@kern.csd.sgi.com> To: info-performer@kern Date: Tue, 16 Apr 1996 09:44:07 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 31 Status: O -- Indu Bingham indu@sgi.com From guest Tue Apr 16 09:54:35 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA04825; Tue, 16 Apr 1996 09:47:05 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA04822; Tue, 16 Apr 1996 09:47:00 -0700 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA11171; Tue, 16 Apr 96 09:46:51 -0700 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id JAA26015; Tue, 16 Apr 1996 09:46:49 -0700 From: "Remi Arnaud" Message-Id: <9604160946.ZM26013@remi.asd.sgi.com> Date: Tue, 16 Apr 1996 09:46:48 -0700 In-Reply-To: ROY RUDDLE "Loading textures on an RE" (Apr 16, 12:48pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Ruddle@cardiff.ac.uk Subject: Re: Loading textures on an RE Cc: info-performer@remi.asd.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 16, 12:48pm, ROY RUDDLE wrote: > Subject: Loading textures on an RE > This must have a simple answer, but I can't find it anywhere: > > As I'm running a small DB I want to force all textures to be loaded into > the RE's texture memory while (or just after) the DB is loaded. I've got > plenty of texture memory. At the moment (ie. by default) textures are > being paged in when they first get displayed. That's it. All textures are mip-mapped the first time they are displayed. So, one must display all textures when (or just after) the DB is loaded. That's why perfly shows all textures before entering in the 'drive' mode. It's not mandatory to display the texture, one can use the back-buffer to draw a polygon per texture when displaying something else on the front-buffer. In libpfutil, a smart function called pfuMakeTexList() construct a list of textures by traversing the scene graph, pfuDownloadTexList() will do the downloading job. Look at the man pages for more informations. -- o o Remi ARNAUD - Silicon Graphics, Advanced Systems Dev o o o o Mail Stop 590 - 2011 N. Shoreline Boulevard o o o o Mountain View, California 94043-1389, USA o o o o Tel: (415) 933 6208 Fax: (415) 965 2658 o o From guest Tue Apr 16 10:14:30 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA04872; Tue, 16 Apr 1996 10:06:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA04869; Tue, 16 Apr 1996 10:06:33 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA12495; Tue, 16 Apr 96 10:06:32 -0700 Received: from server1.ctc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA03696; Tue, 16 Apr 1996 10:06:26 -0700 Received: by server1.ctc.com (5.65/DEC-Ultrix/4.3) id AA13692; Tue, 16 Apr 1996 13:07:35 -0400 Received: by sgi84.ctc.com (940816.SGI.8.6.9/930416.SGI.AUTO) id NAA06229; Tue, 16 Apr 1996 13:07:22 -0400 Date: Tue, 16 Apr 1996 13:07:22 -0400 From: koopman@ctc.com (Michael G. Koopman) Message-Id: <199604161707.NAA06229@sgi84.ctc.com> To: carter@vortex.eai.com Cc: info-performer@sgi.sgi.com In-Reply-To: carter@eai.com's message of Tue, 16 Apr 1996 09:45:38 -0600 (CDT) <199604161445.JAA06866@granite.eai.com> Subject: OpenPerformer & Vis/Sim outside SGI Status: O SGI is not alone.... Bravo! Well put... XCoff now, let's bring parity to issues of back planes and cacheing architecture where it should be thrashed out! Indeed. Mike Koopman +1-814.269.2637 .fax ~x2666 From guest Tue Apr 16 10:24:11 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA04928; Tue, 16 Apr 1996 10:16:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA04925; Tue, 16 Apr 1996 10:16:37 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA13032; Tue, 16 Apr 96 10:16:36 -0700 Received: from xmission.xmission.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA04993; Tue, 16 Apr 1996 10:13:59 -0700 Received: (from klaus@localhost) by xmission.xmission.com (8.7.5/8.7.5) id LAB10780; Tue, 16 Apr 1996 11:13:46 -0600 (MDT) From: klaus Message-Id: <199604161713.LAB10780@xmission.xmission.com> Subject: Re: OpenPerformer & Vis/Sim outside SGI To: info-performer@sgi.sgi.com Date: Tue, 16 Apr 1996 11:13:40 -0600 (MDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: O > > From: carter@eai.com > Subject: OpenPerformer & Vis/Sim outside SGI > To: info-performer@sgi.sgi.com > > 2. OpenGL-style: SGI takes the high road and places its hardware and support > into direct, level, fair, head-to-head competition with HP, Sun, E&S and > anyone else who feels that they have the "grambaugh" to tangle with the > inventors of visual simulation, and the leaders in commercial hardware > rendering! OpenPerformer. This has the added advantage that the sales > force can compete to "convert" customers from other platforms to SGI. > Are you claiming that SGI are the inventors of visual simulation? Hmmmm. Not very old, are you? And Apple invented GUI's, right? ;> -klaus From guest Tue Apr 16 10:43:23 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA05087; Tue, 16 Apr 1996 10:35:55 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA05084; Tue, 16 Apr 1996 10:35:55 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA14173; Tue, 16 Apr 96 10:35:49 -0700 Received: from uu9.psi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA08745; Tue, 16 Apr 1996 10:35:47 -0700 Received: from ivex3d.com by uu9.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA17152 for info-performer@sgi.sgi.com; Tue, 16 Apr 96 13:35:44 -0400 Message-Id: <9604161735.AA17152@uu9.psi.com> From: Hudson Holmes To: info-performer@sgi.sgi.com Date: Tue, 16 Apr 1996 13:37:35 +0000 Subject: Performer Programmer X-Mailer: Pegasus Mail for Windows (v2.20) Status: O Does anyone know of a job bank, bulletin board, or web site where I can look for a Performer Programmer familiar with high-end SGI systems. From guest Tue Apr 16 11:04:23 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA05359; Tue, 16 Apr 1996 10:58:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA05356; Tue, 16 Apr 1996 10:58:16 -0700 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA15738; Tue, 16 Apr 96 10:58:15 -0700 Received: from giraffe.asd.sgi.com by remi.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA26464; Tue, 16 Apr 1996 10:58:13 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for remi@remi.asd.sgi.com id AA15728; Tue, 16 Apr 96 10:58:10 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA05777; Tue, 16 Apr 1996 10:58:08 -0700 From: "Sharon Clay" Message-Id: <9604161058.ZM5775@rose.asd.sgi.com> Date: Tue, 16 Apr 1996 10:58:08 -0700 In-Reply-To: "Remi Arnaud" "Re: Loading textures on an RE" (Apr 16, 9:46am) References: <9604160946.ZM26013@remi.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Remi Arnaud" , Ruddle@cardiff.ac.uk Subject: Re: Loading textures on an RE Cc: info-performer@remi.asd.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 16, 9:46am, Remi Arnaud wrote: > Subject: Re: Loading textures on an RE ->From guest@holodeck.csd.sgi.com Tue Apr 16 10:48:27 1996 ->From: "Remi Arnaud" ->Date: Tue, 16 Apr 1996 09:46:48 -0700 ->In-Reply-To: ROY RUDDLE -> "Loading textures on an RE" (Apr 16, 12:48pm) ->X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) ->To: Ruddle@cardiff.ac.uk ->Subject: Re: Loading textures on an RE ->Cc: info-performer@remi -> ->On Apr 16, 12:48pm, ROY RUDDLE wrote: ->> Subject: Loading textures on an RE ->> This must have a simple answer, but I can't find it anywhere: ->> ->> As I'm running a small DB I want to force all textures to be loaded into ->> the RE's texture memory while (or just after) the DB is loaded. I've got ->> plenty of texture memory. At the moment (ie. by default) textures are ->> being paged in when they first get displayed. -> ->That's it. All textures are mip-mapped the first time they are displayed. ->So, one must display all textures when (or just after) the DB is loaded. ->That's why perfly shows all textures before entering in the 'drive' mode. -> ->It's not mandatory to display the texture, one can use the back-buffer to draw ->a polygon per texture when displaying something else on the front-buffer. -> Actually, it isn't really necessary to draw them at all. Having them be bound as the current texture will do it. The PFUTEX_APPLY option to pfuDownloadTexList() does exactly this by calling pfApplyTex(). FYI, if you don't have enough total texture memory, but want the textures to get pre-defined with their mipmaps generated before starting your simulation, you can use the PFU_DEFINE option which simply calls pfFormatTex() for each pfTexture. It is important that textures generally not wait for a polygon to get downloaded or it would be hard schedule or pre-load textures when database paging. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue Apr 16 11:25:52 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA05576; Tue, 16 Apr 1996 11:20:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA05573; Tue, 16 Apr 1996 11:20:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA17240; Tue, 16 Apr 96 11:19:58 -0700 Received: from pluto.colsa.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA17061; Tue, 16 Apr 1996 11:19:44 -0700 Received: from colsa.iquest.com ([199.172.89.48]) by pluto.colsa.com (8.6.9/8.6.9) with SMTP id TAA11904 for ; Tue, 16 Apr 1996 19:29:06 -0500 Date: Tue, 16 Apr 1996 19:29:06 -0500 Message-Id: <199604170029.TAA11904@pluto.colsa.com> X-Sender: lhoffman@colsa.iquest.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: lhoffman@colsa.com (Luke Hoffman) Subject: Re: OpenPerformer & Vis/Sim outside SGI Status: O > ....... Performer remains a > closed product tied to the SGI platform, and other vendor's customers > must invent all their visual simulation applications from scratch. [snip] >2. OpenGL-style: SGI takes the high road and places its hardware and support > into direct, level, fair, head-to-head competition with HP, Sun, E&S and > anyone else who feels that they have the "grambaugh" to tangle with the > inventors of visual simulation, and the leaders in commercial hardware > rendering! OpenPerformer. This has the added advantage that the sales > force can compete to "convert" customers from other platforms to SGI. > > The market for visual simulation on platforms other than SGI is not >growing, it is *HERE* ***NOW***!!! The market is *not* standing still >waiting to see if SGI will open up performer. Both HP and Sun have >competent graphics products available NOW. You can bet that they have >announcements of excellent products on the way. Here's another question to add to the list. How do we compare offerings from other vendors with SG equipment. Another vendor offering a Vis/Sim solution will almost certainly use OpenGL. OpenGL is fine, but it ain't Performer. Which means two things. First, the Performer based code were using will have to be rewritten using the OpenGL API. Second (and this is my opinion here), OpenGL based applications are not going to be as fast as Performer based applications. Please, correct me on the second if I'm wrong, but I have yet to see an API as sophisticated as Performer for Vis/Sim applications. What then would be the best way to compare a non SGI platform with an SGI platform? I'd like to have two versions of one application, one based in Performer the other in OpenGL. Luke _____________________________________________________ Luke Hoffman Voice: (205)922-1512x1157 COLSA Corporation FAX: (205)971-0002 6726 Odyssey Dr. Huntsville, AL 35806 When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. From guest Tue Apr 16 11:23:32 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA05558; Tue, 16 Apr 1996 11:17:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA05555; Tue, 16 Apr 1996 11:17:49 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA17168; Tue, 16 Apr 96 11:17:48 -0700 Received: from virtual.me.uic.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA16643; Tue, 16 Apr 1996 11:17:43 -0700 Received: by virtual.me.uic.edu (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.sgi.com id NAA28219; Tue, 16 Apr 1996 13:17:40 -0500 From: fred@virtual.me.uic.edu (Fred Dech) Message-Id: <199604161817.NAA28219@virtual.me.uic.edu> Subject: pfiInputXform question. To: info-performer@sgi.sgi.com Date: Tue, 16 Apr 1996 13:17:36 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 575 Status: O hi. i've been using pfiInputXformTrackball objects in an application. everything seems to work fairly predictably except tball->setMat(mat) never, ever, actually let's me set the InputXform matrix directly. no problem with pfiInputXformTrackball::getMat(). also, no problem at all with reset(). does anyone have any experience with this? is there a known bug with pfiInputXformTrackball::setMat(), perhaps? thanks. --fred ps. the analogous C routines gave me exactly the same behavior. - Fred Dech fred@virtual.me.uic.edu (312) 413-3619 Fax: (312) 413-0447 From guest Tue Apr 16 12:59:13 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA06361; Tue, 16 Apr 1996 12:53:58 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA06358; Tue, 16 Apr 1996 12:53:57 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA21822; Tue, 16 Apr 96 12:53:56 -0700 Received: from ns.nrtc.northrop.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA02454; Tue, 16 Apr 1996 12:53:18 -0700 Received: from lazarus.nrtc.northrop.com by ns.nrtc.northrop.com (4.1/nrtc-15.6a) id AA28834; Tue, 16 Apr 96 12:53:04 PDT Received: from world.nad.northrop.com by lazarus.nrtc.northrop.com (15.4a/15.6.b) id AA05109; Tue, 16 Apr 96 11:51:48 pst Received: from esplt14m-s.grumman.com by world.northgrum.com (4.1/SMI-4.1.1) id AA18730; Tue, 16 Apr 96 12:56:13 PDT Message-Id: Date: 16 Apr 1996 15:50:12 -0500 From: "Shawn Soeder" Subject: zbuffer data representation To: "info-performer" X-Mailer: Mail*Link SMTP/QM 3.0.0 Status: O Performers, Suppose that someone wanted to extract distance data from the zbuffer after a scene has been rendered. Is the value in the zbuffer simply a linear value ranging from 0x00 at the near clipping plane to 0xff (with the appropriate number of places) at the far clipping plane? Is it nonlinear? Is there a source of information that describes the zbuffer values? Thanks, Shawn From guest Tue Apr 16 13:18:33 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA06399; Tue, 16 Apr 1996 13:12:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA06396; Tue, 16 Apr 1996 13:12:14 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA22745; Tue, 16 Apr 96 13:12:08 -0700 Received: from sgigate.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA05341; Tue, 16 Apr 1996 13:12:02 -0700 From: tidrowd@cc.tacom.army.mil Received: from octagon.tacom.army.mil by sgigate.sgi.com via ESMTP (950911.SGI.8.6.12.PATCH825/940406.SGI) for id NAA06581; Tue, 16 Apr 1996 13:12:00 -0700 Received: from cc.tacom.army.mil by octagon.tacom.army.mil (8.7.5/8.7.3-kbp) with SMTP id QAA25681; Tue, 16 Apr 1996 16:06:13 -0400 (EDT) Received: from ccMail by cc.tacom.army.mil (IMA Internet Exchange 1.04b) id 173fbd50; Tue, 16 Apr 96 15:58:13 -0400 Mime-Version: 1.0 Date: Tue, 16 Apr 1996 15:55:58 -0400 Message-Id: <173fbd50@cc.tacom.army.mil> To: lhoffman@colsa.com (Luke Hoffman), info-performer@sgi.sgi.com Subject: Re[2]: OpenPerformer & Vis/Sim outside SGI Content-Type: multipart/mixed; boundary="IMA.Boundary.396486928" Status: O This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.396486928 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Received: from octagon.tacom.army.mil by cc.tacom.army.mil with SMTP (IMA Internet Exchange 1.04b) id 173effe0; Tue, 16 Apr 96 15:07:42 -0400 Received: from sgigate.sgi.com by octagon.tacom.army.mil (8.7.5/8.7.3-kbp) with S MTP id PAA24700; Tue, 16 Apr 1996 15:08:25 -0400 (EDT) Received: from holodeck.csd.sgi.com by sgigate.sgi.com via ESMTP (950911.SGI.8.6. 12.PATCH825/940406.SGI) id MAA06110; Tue, 16 Apr 1996 12:03:13 -0700 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA05576; Tue, 16 Apr 1996 11:20:00 -0700 Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8 .6.12/940406.SGI.AUTO) for id LAA05573; Tue, 16 Apr 1996 11:20:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/93041 6.SGI) for info-performer@holodeck.csd.sgi.com id AA17240; Tue, 16 Apr 96 11:19:58 -070 0 Received: from pluto.colsa.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110 .SGI) for id LAA17061; Tue, 16 Apr 1996 11:19:44 -0700 Received: from colsa.iquest.com ([199.172.89.48]) by pluto.colsa.com (8.6.9/8.6.9 ) with SMTP id TAA11904 for ; Tue, 16 Apr 1996 19:29: 06 -0500 Date: Tue, 16 Apr 1996 19:29:06 -0500 Message-Id: <199604170029.TAA11904@pluto.colsa.com> X-Sender: lhoffman@colsa.iquest.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: lhoffman@colsa.com (Luke Hoffman) Subject: Re: OpenPerformer & Vis/Sim outside SGI --IMA.Boundary.396486928 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Before Performer was widely available (1.2), we used Gemini Technology's GVS software for all our image generation software needs. They now have an OpenGL version that runs on other platforms (PC's, Kubotas when they were still around, prob. any other OpenGL platform you want - they are kind of hurting for business, from what I hear - could be wrong) It had basically everything Performer had, with the big exception of not being multithreaded (app-cull-draw sense, although this may have changed) I still have some old code lying around somewhere if you want an example of what it looked like. One of the nice features it had was that you could attach a 'camera' (~= pfChannel) to an graphical object and it would update the position of the camera automatically when you moved the object (including articulated parts) As for OpenGL application speed, Performer 2.0 is implemented via OpenGL (as well as IrisGL), so a well-done straight OpenGL vis/sim application should perform nearly as fast as Performer, maybe even faster if you restrict its application domain. My take on all this is that Sun and HP don't seem to be targeting the top-end SGI's, instead they are targeting the mid-range (Impact) area. The top-end SGI's really compete in the vis/sim arena with ESIG's and other dedicated image generators, with an InfiniteReality system (loaded) probably being roughly equal to an ESIG3000 (educated guess - no flamage please) Their big advantage, IMHO, is that they are generally more flexible in what you can do with them - you can 'easily' reprogram them to get what you want. Most other IG's can render databases that you supply, but adding new functionality is difficult at best. Of course, I'm a big fan of SGI's, so I'm a bit biased. Don Tidrow Visual Simulation Developer US Army Tank-automotive and Armaments Command (Views and opinions expressed here are mine and mine alone!) ______________________________ Reply Separator _________________________________ Subject: Re: OpenPerformer & Vis/Sim outside SGI Author: lhoffman@colsa.com (Luke Hoffman) at TWLAN-SMTP Date: 4/16/96 7:29 PM > ....... Performer remains a > closed product tied to the SGI platform, and other vendor's customers > must invent all their visual simulation applications from scratch. [snip] >2. OpenGL-style: SGI takes the high road and places its hardware and support > into direct, level, fair, head-to-head competition with HP, Sun, E&S and > anyone else who feels that they have the "grambaugh" to tangle with the > inventors of visual simulation, and the leaders in commercial hardware > rendering! OpenPerformer. This has the added advantage that the sales > force can compete to "convert" customers from other platforms to SGI. > > The market for visual simulation on platforms other than SGI is not >growing, it is *HERE* ***NOW***!!! The market is *not* standing still >waiting to see if SGI will open up performer. Both HP and Sun have >competent graphics products available NOW. You can bet that they have >announcements of excellent products on the way. Here's another question to add to the list. How do we compare offerings from other vendors with SG equipment. Another vendor offering a Vis/Sim solution will almost certainly use OpenGL. OpenGL is fine, but it ain't Performer. Which means two things. First, the Performer based code were using will have to be rewritten using the OpenGL API. Second (and this is my opinion here), OpenGL based applications are not going to be as fast as Performer based applications. Please, correct me on the second if I'm wrong, but I have yet to see an API as sophisticated as Performer for Vis/Sim applications. What then would be the best way to compare a non SGI platform with an SGI platform? I'd like to have two versions of one application, one based in Performer the other in OpenGL. Luke _____________________________________________________ Luke Hoffman Voice: (205)922-1512x1157 COLSA Corporation FAX: (205)971-0002 6726 Odyssey Dr. Huntsville, AL 35806 When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. --IMA.Boundary.396486928-- From guest Tue Apr 16 15:36:23 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA07022; Tue, 16 Apr 1996 15:20:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA07019; Tue, 16 Apr 1996 15:20:11 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA00280; Tue, 16 Apr 96 15:20:09 -0700 Received: from uucp-1.csn.net by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id PAA02923; Tue, 16 Apr 1996 15:20:08 -0700 Received: from evt.com (uucp@localhost) by uucp-1.csn.net (8.6.12/8.6.12) with UUCP id QAA26186 for csn!sgi.com!info-performer; Tue, 16 Apr 1996 16:18:53 -0600 Received: from snowmass by vail via ESMTP (940816.SGI.8.6.9/930416.SGI) for <@vail:info-performer@sgi.com> id PAA05027; Tue, 16 Apr 1996 15:57:51 -0700 Received: by snowmass (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id PAA12980; Tue, 16 Apr 1996 15:57:50 -0700 From: "Dewey Anderson" Message-Id: <9604161557.ZM12978@snowmass> Date: Tue, 16 Apr 1996 15:57:50 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.com Subject: Texture Memory & ref counts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I think I'm having a problem with texture memory not clearing and wonder if it's related to the reference count. This is Performer 2.0 on an Onyx with RE 2. Basic flow of the program is: create a basic scene Loop: create a few textures & put them on rectangles. Create a pfNode for each with DCS-SCS-rectangle (all unique) attach them to the scene pfuDownloadTexList( pfuMakeSceneTexList( (scene), PFUTEX_APPLY ); fly them around some for each node detach it from scene pfDelete the node I noticed that after doing this a number of times (dependent on the amount of texture), the call to pfuDownloadTexList crashes deep in a bcopy. I get the impression that texture memory has filled up and that's causing the crash. This made me figure that the pfDelete must not be clearing the textures from texture memory. I took a look at the refCounts and noticed that when I go into my draw callback (which does nothing but call pfDraw), the refCount on the pfTexture is 1 but after the call to pfDraw, that refCount has gone up to 2. This only happens during the FIRST call to pfDraw in the "fly around some" animation loop. (It remains 2 thereafter.) Is this correct that drawing an object with a texture counts as an ADDITIONAL reference to that texture? Is there some Performer protocol or convention that I'm not following that would make the general flow work, i.e. delete the texture when I'm done with it? OK, next comes the kludge fix. I stuck in an unref right after the texture gets applied to the rectangle: gstate->setAttr( PFSTATE_TEXTURE, tex ); tex->unref(); // FIX: kludge to keep ref count low enough Printing out the refCount now shows 0 going into the draw callback (probably not recommended practice, I know...) and 1 after the pfDraw. This did not solve the problem making me think that maybe just doing a pfDelete on the pfNode isn't enough to make it walk down the branch and delete the texture from texture memory. Do I need to explicitly pfDelete the pfTexture to clear it out of texture memory? Any help is appreciated. Dewey Anderson Evolving Video Technologies From guest Tue Apr 16 16:53:46 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id QAA07601; Tue, 16 Apr 1996 16:51:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id QAA07598; Tue, 16 Apr 1996 16:51:02 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA05649; Tue, 16 Apr 96 16:51:01 -0700 Received: from jeeves.icemt.iastate.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA10802; Tue, 16 Apr 1996 16:50:56 -0700 Received: from helser75.res.iastate.edu (helser75.res.iastate.edu [129.186.76.75]) by jeeves.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) with SMTP id SAA12898 for ; Tue, 16 Apr 1996 18:50:53 -0500 Received: by helser75.res.iastate.edu with Microsoft Mail id <01BB2BC5.9EA22A00@helser75.res.iastate.edu>; Tue, 16 Apr 1996 18:50:45 -0500 Message-Id: <01BB2BC5.9EA22A00@helser75.res.iastate.edu> From: Allen Bierbaum To: "'Performer List'" Subject: Tele source Date: Tue, 16 Apr 1996 18:50:30 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: O Here is an extract from the IRIS Performer Gallery web page.... >Tele: Video Special Effects using Draw callbacks >Real-time video special effects such as the "page-turn" shown here can be implemented using Onyx >RealityEngine systems >with IRIS Performer. Live video images can be manipulated when the Sirius Video option is used. The >IRIS Performer >based Tele program shown here was developed by Wade Olsen and Vince Uttley of SGI. It is available >in source form and >can perform many innovative video transitions. Tele is a cornerstone of SGI's Silicon Studio video >environment. Who do I contact to get this source???? -Allen Bierbaum allenb@vislab.iastate.edu ISU CAVE From guest Tue Apr 16 21:58:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id VAA08724; Tue, 16 Apr 1996 21:55:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id VAA08721; Tue, 16 Apr 1996 21:55:49 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA18188; Tue, 16 Apr 96 21:55:48 -0700 Received: from waverly.psyberlink.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id VAA09230; Tue, 16 Apr 1996 21:55:46 -0700 Received: from net4.psyberlink.net (net4 [205.241.30.14]) by waverly.psyberlink.net (8.6.11/8.6.9) with SMTP id XAA09745 for ; Tue, 16 Apr 1996 23:58:47 -0500 Message-Id: <199604170458.XAA09745@waverly.psyberlink.net> X-Sender: phantasm@psyberlink.net (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Apr 1996 23:03:32 -0500 To: info-performer@sgi.sgi.com From: phantasm@psyberlink.net (Larry Kjellberg) Subject: seeking homes for X-Mailer: Status: O High Impact - 250mhz, 128mb ram, 4gb disk, 2mb cache, CD-ROM, 20" monitor RE2 - 2 cpu @ 150 mhz, 64mb ram, 2 @ 2gb disk, 1 RM4, 21" monitor We are upgrading. Both available in USA at significant discount from list. If interested send email to Phantasm@psyberlink.net directly. From guest Wed Apr 17 00:45:39 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id AAA10003; Wed, 17 Apr 1996 00:43:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA10000; Wed, 17 Apr 1996 00:43:32 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA21988; Wed, 17 Apr 96 00:43:30 -0700 Received: from farm.ddd.co.jp by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id AAA00644; Wed, 17 Apr 1996 00:43:28 -0700 Received: from [202.230.84.102] by farm.ddd.co.jp (post.office MTA v1.9.3 evaluation license) with SMTP id AAA133 for ; Wed, 17 Apr 1996 16:43:22 +0900 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: kanou@ddd.co.jp (Y.Kanou) Subject: IR video format To: info-performer@sgi.com X-Mailer: SPRY Mail Version: 04.00.06.17 Date: Wed, 17 Apr 1996 16:43:22 +0900 Message-Id: <19960417074321646.AAA133@[202.230.84.102]> Status: O I heard that InfiniteReality can output 2 channel without MCO. Does anyone know what kind of video format? Thanks in advance. Yutaka Kanou(3D Inc) e-mail:kanou@ddd.co.jp tel:+81-45-314-8334 fax:+81-45-314-8335 Mitsuishi-Yohohama-building 1-39-3 Hiranuma Nishi-ku Yokohama 220 Japan From guest Wed Apr 17 01:04:25 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA10209; Wed, 17 Apr 1996 01:02:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA10206; Wed, 17 Apr 1996 01:02:32 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA22295; Wed, 17 Apr 96 01:02:31 -0700 Received: from hntp2.hinet.net by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id BAA02330; Wed, 17 Apr 1996 01:02:26 -0700 Received: from systech.hinet.net (systech.hinet.net [168.95.200.3]) by hntp2.hinet.net (8.6.11/8.6.11) with SMTP id QAA13134 for <@hntp2.hinet.net:info-performer@sgi.com>; Wed, 17 Apr 1996 16:00:24 +0800 Received: by systech.hinet.net (931110.SGI/930416.SGI) for @hntp2.hinet.net:info-performer@sgi.com id AA25768; Wed, 17 Apr 96 17:02:25 -0700 Date: Wed, 17 Apr 96 17:02:25 -0700 From: terence@systech.hinet.net (Terence Ker) Message-Id: <9604180002.AA25768@systech.hinet.net> To: info-performer@sgi.com Subject: Proceedings of SIGGRAPH'93 Status: O Hi, Performer; Can any one tell me where to get, or e-mail me if available, the following paper: Akeley, K.: RealityEngine Graphics Proceedings of SIGGRAPH'93 pp. 109 - 116 I tried sgigate.sgi.com/pub/Performer/docs only to see '94 and '95 pastscript compressed docs. I don't have a postscript printer and need only plain ASCII format. Thanks for your help! -= Terence Ke =- Systems & Technology Taipei, Taiwan e-mail: terence@systech.hinet.net From guest Wed Apr 17 04:00:54 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id DAA04735; Wed, 17 Apr 1996 03:56:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id DAA04732; Wed, 17 Apr 1996 03:56:15 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA24376; Wed, 17 Apr 96 03:56:13 -0700 Received: from evl.eecs.uic.edu by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id DAA15412; Wed, 17 Apr 1996 03:56:12 -0700 Received: from idesk.eecs.uic.edu by evl.eecs.uic.edu via ESMTP (950215.SGI.8.6.10/940406.SGI.AUTO) id FAA21028; Wed, 17 Apr 1996 05:55:00 -0500 Received: (pape@localhost) by idesk.eecs.uic.edu (8.6.12/8.6.4) id KAA01875; Wed, 17 Apr 1996 10:54:55 GMT From: "Dave Pape" Message-Id: <9604170554.ZM1873@idesk.eecs.uic.edu> Date: Wed, 17 Apr 1996 05:54:55 -0500 In-Reply-To: "Larry Peruski" "" (Apr 15, 8:07am) References: <199604150908.AA03844@sumo.gmd.de> <9604150807.ZM625@lep.cs.gmr.com> Reply-To: pape@evl.eecs.uic.edu X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Larry Peruski" , Vali Lalioti , info-performer@sgi.com Subject: Re: TKO & pf 2.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > On Apr 15, 11:08am, Vali Lalioti wrote: > > I have a problem with using two pipes and two screens on a machine that > > is set to the "triple keyboard option" (TKO). The warning I get is that > > there is no screen 1, which probably is true since with this option > > the displays are 0.0, 1.0,2.0 instead of 0.0, 0.1, 0.2. > > Is there any way to solve this problem? > > I include a small example and the error messages. > > > > sincerely yours, > > Dr. V. Lalioti. I recently ran into on this problem as well. The program below shows the relevant calls which finally worked on our TKO. Note that this only works with the OpenGL libraries. If I compile with IrisGL, both windows are opened on the same display. -Dave ----- #include #include #include #include void config0(pfPipeWindow *pwin) { pfOpenWSConnection(":0.0",TRUE); pfOpenPWin(pwin); } void config1(pfPipeWindow *pwin) { pfOpenWSConnection(":1.0",TRUE); pfOpenPWin(pwin); } int main(int argc,char **argv) { pfPipe *pipe[2]; pfPipeWindow *pwin[2]; pfInit(); pfMultipipe(2); pfConfig(); pipe[0] = pfGetPipe(0); pfPipeWSConnectionName(pipe[0],":0.0"); pfPipeScreen(pipe[0],0); pwin[0] = pfNewPWin(pipe[0]); pfPWinOriginSize(pwin[0],0,0,512,512); pfPWinConfigFunc(pwin[0],config0); pfConfigPWin(pwin[0]); pipe[1] = pfGetPipe(1); pfPipeWSConnectionName(pipe[1],":1.0"); pfPipeScreen(pipe[1],0); pwin[1] = pfNewPWin(pipe[1]); pfPWinOriginSize(pwin[1],0,0,512,512); pfPWinConfigFunc(pwin[1],config1); pfConfigPWin(pwin[1]); while (1) { pfSync(); pfFrame(); } pfExit(); } -- --------------------------------------------------------------------------- Dave Pape Electronic Visualization Laboratory, UIC pape@evl.eecs.uic.edu http://evlweb.eecs.uic.edu/pape/ From guest Wed Apr 17 05:42:57 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA05176; Wed, 17 Apr 1996 05:35:42 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA05173; Wed, 17 Apr 1996 05:35:41 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA26284; Wed, 17 Apr 96 05:35:40 -0700 Received: from orbit16i.nesdis.noaa.gov by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id FAA22445; Wed, 17 Apr 1996 05:35:35 -0700 Received: by orbit16i.nesdis.noaa.gov (950215.SGI.8.6.10/940406.SGI.AUTO) id IAA12035; Wed, 17 Apr 1996 08:33:19 -0400 From: "Robert Carey" Message-Id: <9604170833.ZM12033@orbit16i.nesdis.noaa.gov> Date: Wed, 17 Apr 1996 08:33:07 -0400 In-Reply-To: terence@systech.hinet.net (Terence Ker) "Proceedings of SIGGRAPH'93" (Apr 17, 5:02pm) References: <9604180002.AA25768@systech.hinet.net> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: terence@systech.hinet.net (Terence Ker) Subject: Re: Proceedings of SIGGRAPH'93 Cc: info-performer@sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Terence, You asked: > Can any one tell me where to get, or e-mail me if available, the >following paper: >Akeley, K.: >RealityEngine Graphics >Proceedings of SIGGRAPH'93 pp. 109 - 116 You might try contacting ACM/SIGGRAPH to get those proceedings. It'll run about $45.00 or so. Write to ACM Order Dept. PO Box 64145 Baltimore, Maryland 21264 USA or email to acmpubs@acm.org and inquire. Hope this helps! bobzilla, (who was actually AT SIGGRAPH 93 %^) From guest Wed Apr 17 07:48:40 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA05434; Wed, 17 Apr 1996 07:41:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA05431; Wed, 17 Apr 1996 07:41:56 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA28252; Wed, 17 Apr 96 07:41:54 -0700 Received: from bhole.cae.ca by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id HAA05618; Wed, 17 Apr 1996 07:41:53 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA06701; Wed, 17 Apr 1996 09:58:39 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id JAA25380; Wed, 17 Apr 1996 09:39:32 -0400 From: "Bernard Leclerc" Message-Id: <9604170939.ZM25378@eagle.cae.ca> Date: Wed, 17 Apr 1996 09:39:27 -0400 In-Reply-To: terence@systech.hinet.net (Terence Ker) "Proceedings of SIGGRAPH'93" (Apr 17, 5:02pm) References: <9604180002.AA25768@systech.hinet.net> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: terence@systech.hinet.net (Terence Ker), info-performer@sgi.com Subject: Re: Proceedings of SIGGRAPH'93 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 17, 5:02pm, Terence Ker wrote: > Can any one tell me where to get, or e-mail me if available, the > following paper: > > Akeley, K.: > RealityEngine Graphics > Proceedings of SIGGRAPH'93 pp. 109 - 116 > > I tried sgigate.sgi.com/pub/Performer/docs only to see '94 and '95 > pastscript compressed docs. I don't have a postscript printer and need > only plain ASCII format. Terence, Try the SIGGRAPH web site at http://www.siggraph.org -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Wed Apr 17 08:05:21 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA05447; Wed, 17 Apr 1996 07:58:43 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA05444; Wed, 17 Apr 1996 07:58:42 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA28914; Wed, 17 Apr 96 07:58:41 -0700 Received: from huey.ntsc.navy.mil by deliverator.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id HAA07368; Wed, 17 Apr 1996 07:58:40 -0700 From: william_marinelli@ntsc.navy.mil Received: from CCMAIL.NTSC.NAVY.MIL ([192.44.253.30]) by huey.ntsc.navy.mil (4.1/SMI-4.1) id AA13244; Wed, 17 Apr 96 10:43:24 EDT Received: from ccMail by CCMAIL.NTSC.NAVY.MIL (SMTPLINK V2.11) id AA829763513; Wed, 17 Apr 96 10:50:06 EST Date: Wed, 17 Apr 96 10:50:06 EST Message-Id: <9603178297.AA829763513@CCMAIL.NTSC.NAVY.MIL> To: info-performer@sgi.com Subject: Re: Proceedings of SIGGRAPH'93 Status: O On page 110 we are told that there is frame buffer memory allocated to support 256 bits per pixel, which sounds very impressive. I think it's a misprint because in my mind I can only account for 56. Please confirm/refute. ______________________________ Reply Separator _________________________________ Subject: Proceedings of SIGGRAPH'93 Author: terence@systech.hinet.net (Terence Ker) at SMTPLINK-NTSC Date: 4/17/96 5:02 PM Hi, Performer; Can any one tell me where to get, or e-mail me if available, the following paper: Akeley, K.: RealityEngine Graphics Proceedings of SIGGRAPH'93 pp. 109 - 116 I tried sgigate.sgi.com/pub/Performer/docs only to see '94 and '95 pastscript compressed docs. I don't have a postscript printer and need only plain ASCII format. Thanks for your help! -= Terence Ke =- Systems & Technology Taipei, Taiwan e-mail: terence@systech.hinet.net From guest Wed Apr 17 08:51:11 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA05635; Wed, 17 Apr 1996 08:44:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA05632; Wed, 17 Apr 1996 08:44:33 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA00087; Wed, 17 Apr 96 08:44:32 -0700 Received: from goggins.bath.ac.uk by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA00350; Wed, 17 Apr 1996 08:43:59 -0700 Received: from bath.ac.uk (actually host ss1.bath.ac.uk) by goggins.bath.ac.uk with SMTP (PP); Wed, 17 Apr 1996 14:03:02 +0100 Received: from gazza.bath.ac.uk by ss1.bath.ac.uk id aa26380; 17 Apr 96 14:03 BST Date: Wed, 17 Apr 1996 14:03:01 +0100 () From: Gazza To: Performer list Subject: Performer 2.0 and 3DS files Message-Id: X-Sender: absgh@mail.bath.ac.uk Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi. Just got our new Max Impact with Performer 2.0. I'm completely new to Performer and I'm not a programmer (yet... that's the next step!). Anyway, I've noticed in this list archive of the last few months that other people have had the same problem loading 3DStudio files into perfly. What I haven't noticed, however, are any answers that are helpful to me, perhaps people have been answering via private email. Anyway, if anyone has any ideas as to how to get it working, I'd be more than pleased to find out, as we have a number of 3ds files that we want to view. At the moment, perfly is perfectly acceptable, but as time goes on and I, or whoever, works out how to program and use C++ etc, we shall be able to produce our own applications! Thanks for your help. Gary PS. I think I know the answer to this already, but is it possible to get a spacemouse to work with perfly? I know (hope) it would be possible to get some interaction if I wrote my own application but as I say... From guest Wed Apr 17 09:07:12 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA05722; Wed, 17 Apr 1996 09:00:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA05719; Wed, 17 Apr 1996 09:00:31 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA00829; Wed, 17 Apr 96 09:00:29 -0700 Received: from coryphaeus.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA02710; Wed, 17 Apr 1996 09:00:18 -0700 Message-Id: Date: 17 Apr 1996 07:50:39 -0800 From: "Bruce Sinclair" Subject: passive into interactive To: "a a" Cc: "p p" X-Mailer: Mail*Link SMTP-QM 3.0.1 Status: O stefan, we here at coryphaeus have products that will read wavefront keyframe animation and character animation files into our real-time (performer-based) system. the keyframe animation is not *steerable* when inside the interactive environment but it can interact with other elements (an example of this is a bird flying around). the character animation data can be either softbodied or hardbodied (rigid transformations) and is controllable withing the interactive environment. to the best of our knowledge we are the only company with this capability. with our new product activation - real-time graphics software to prototype interactive 3D games - we will also be able to read in alias, softimage, 3d studio, nichiman, etc.. geometry formats with textures and materials. contact me directly if you would like anymore information bruce --- Forwarded mail from Stefan Schuster Date: Tue, 16 Apr 1996 09:15:57 +0200 From: Stefan Schuster To: info-performer@sgi.sgi.com Subject: Alias 2 Performer animation converter [ plain text Encoded with "quoted-printable" ] : Does anyone know if there exists a tool that allows to transform/convert animations created in Alias Wavefront to Performer 2.0 ? Any hint's appreciated. Thanks, Stefan ---End of forwarded mail from Stefan Schuster From guest Wed Apr 17 11:10:51 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA06123; Wed, 17 Apr 1996 11:05:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA06120; Wed, 17 Apr 1996 11:05:08 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA06385; Wed, 17 Apr 96 11:05:05 -0700 Received: from netcom8.netcom.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA06475; Wed, 17 Apr 1996 11:05:01 -0700 Received: by netcom8.netcom.com (8.6.13/Netcom) id JAA12947; Wed, 17 Apr 1996 09:25:44 -0700 Date: Wed, 17 Apr 1996 09:25:44 -0700 (PDT) From: "Paul S. Cutt" Subject: Re: Performer 2.0 and 3DS files To: Gazza Cc: Performer list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi, I notice you wanted to get a spacemouse working with perfly. We sell a VR device API which enables very easy interface with most VR devices such as the space mouse. Works great with performer. Thanks, paul On Wed, 17 Apr 1996, Gazza wrote: > > Hi. > > Just got our new Max Impact with Performer 2.0. I'm completely new to > Performer and I'm not a programmer (yet... that's the next step!). > Anyway, I've noticed in this list archive of the last few months that > other people have had the same problem loading 3DStudio files into perfly. > > What I haven't noticed, however, are any answers that are helpful to me, > perhaps people have been answering via private email. Anyway, if anyone > has any ideas as to how to get it working, I'd be more than pleased to > find out, as we have a number of 3ds files that we want to view. > > At the moment, perfly is perfectly acceptable, but as time goes on and I, > or whoever, works out how to program and use C++ etc, we shall be able to > produce our own applications! > > Thanks for your help. > > Gary > > PS. I think I know the answer to this already, but is it possible to get a > spacemouse to work with perfly? I know (hope) it would be possible to get > some interaction if I wrote my own application but as I say... > > > From guest Wed Apr 17 11:33:31 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA06166; Wed, 17 Apr 1996 11:27:45 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA06163; Wed, 17 Apr 1996 11:27:44 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA07795; Wed, 17 Apr 96 11:27:41 -0700 Received: from sgigate.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA08197; Wed, 17 Apr 1996 11:27:40 -0700 From: tidrowd@cc.tacom.army.mil Received: from octagon.tacom.army.mil by sgigate.sgi.com via ESMTP (950911.SGI.8.6.12.PATCH825/940406.SGI) for id KAA22837; Wed, 17 Apr 1996 10:20:34 -0700 Received: from cc.tacom.army.mil by octagon.tacom.army.mil (8.7.5/8.7.3-kbp) with SMTP id NAA07629; Wed, 17 Apr 1996 13:16:59 -0400 (EDT) Received: from ccMail by cc.tacom.army.mil (IMA Internet Exchange 1.04b) id 175258b0; Wed, 17 Apr 96 13:08:27 -0400 Mime-Version: 1.0 Date: Wed, 17 Apr 1996 13:03:08 -0400 Message-Id: <175258b0@cc.tacom.army.mil> To: info-performer@sgi.sgi.com, william_marinelli@ntsc.navy.mil Subject: Re[2]: Proceedings of SIGGRAPH'93 Content-Type: multipart/mixed; boundary="IMA.Boundary.709067928" Status: O This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.709067928 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Let's see, in 'normal' mode - 32 bits RGBA, 32 bits Z, double buffered = 128 bits/pixel Don't forget multisample mode - 32/48 RGBA bits, 24/32 Z bits x #samples/pixel - adds up fast. Also accumulation buffer, stencil planes, underlay/overlay... Actually in large pixel depth, there are 1024 bits/pixel - needed if you use 16 multisamples per pixel. Don Tidrow Visual Simulation Developer US Army Tank-automotive and Armaments Command ______________________________ Reply Separator _________________________________ Subject: Re: Proceedings of SIGGRAPH'93 Author: william_marinelli@ntsc.navy.mil at TWLAN-SMTP Date: 4/17/96 10:50 AM On page 110 we are told that there is frame buffer memory allocated to support 256 bits per pixel, which sounds very impressive. I think it's a misprint because in my mind I can only account for 56. Please confirm/refute. ______________________________ Reply Separator _________________________________ Subject: Proceedings of SIGGRAPH'93 Author: terence@systech.hinet.net (Terence Ker) at SMTPLINK-NTSC Date: 4/17/96 5:02 PM Hi, Performer; Can any one tell me where to get, or e-mail me if available, the following paper: Akeley, K.: RealityEngine Graphics Proceedings of SIGGRAPH'93 pp. 109 - 116 I tried sgigate.sgi.com/pub/Performer/docs only to see '94 and '95 pastscript compressed docs. I don't have a postscript printer and need only plain ASCII format. Thanks for your help! -= Terence Ke =- Systems & Technology Taipei, Taiwan e-mail: terence@systech.hinet.net --IMA.Boundary.709067928 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Received: from octagon.tacom.army.mil by cc.tacom.army.mil with SMTP (IMA Internet Exchange 1.04b) id 175122a1; Wed, 17 Apr 96 11:45:46 -0400 Received: from sgigate.sgi.com by octagon.tacom.army.mil (8.7.5/8.7.3-kbp) with S MTP id LAA06088; Wed, 17 Apr 1996 11:47:35 -0400 (EDT) Received: from holodeck.csd.sgi.com by sgigate.sgi.com via ESMTP (950911.SGI.8.6. 12.PATCH825/940406.SGI) id IAA08130; Wed, 17 Apr 1996 08:44:04 -0700 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA05447; Wed, 17 Apr 1996 07:58:43 -0700 Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8 .6.12/940406.SGI.AUTO) for id HAA05444; Wed, 17 Apr 1996 07:58:42 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/93 0416.SGI) for info-performer@holodeck.csd.sgi.com id AA28914; Wed, 17 Apr 96 07:58:41 -070 0 Received: from huey.ntsc.navy.mil by deliverator.sgi.com via SMTP (951211.SGI.8.6 .12.PATCH1042/951211.SGI.AUTO) for id HAA07368; Wed, 17 Apr 1996 07:58:40 -0700 From: william_marinelli@ntsc.navy.mil Received: from CCMAIL.NTSC.NAVY.MIL ([192.44.253.30]) by huey.ntsc.navy.mil (4.1/ SMI-4.1) id AA13244; Wed, 17 Apr 96 10:43:24 EDT Received: from ccMail by CCMAIL.NTSC.NAVY.MIL (SMTPLINK V2.11) id AA829763513; Wed, 17 Apr 96 10:50:06 EST Date: Wed, 17 Apr 96 10:50:06 EST Message-Id: <9603178297.AA829763513@CCMAIL.NTSC.NAVY.MIL> To: info-performer@sgi.com Subject: Re: Proceedings of SIGGRAPH'93 --IMA.Boundary.709067928-- From guest Wed Apr 17 11:37:25 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA06206; Wed, 17 Apr 1996 11:31:46 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA06203; Wed, 17 Apr 1996 11:31:45 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA08121; Wed, 17 Apr 96 11:31:37 -0700 Received: from barney.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id LAA09189; Wed, 17 Apr 1996 11:30:40 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id JAA22099; Wed, 17 Apr 1996 09:00:46 +0100 From: "Rob Jenkins" Message-Id: <9604170900.ZM22097@barney.reading.sgi.com> Date: Wed, 17 Apr 1996 09:00:45 +0100 In-Reply-To: "Shawn Soeder" "zbuffer data representation" (Apr 16, 3:50pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Shawn Soeder" , "info-performer" Subject: Re: zbuffer data representation Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19604170900.ZM22097.reading.sgi.com" Status: O -- --PART-BOUNDARY=.19604170900.ZM22097.reading.sgi.com Content-Type: text/plain; charset=us-ascii the zbuffer is non linear - most resolution near the eye, I've attached a great Pipeline article which covers several zbuffer techniques including reading back from the buffer. It has the equations you need. It's a bit old now but the general idea is still the same. Cheers Rob PS I'm sure several people will have implemented this in code - If you don't get any examples let me know and I'll try to track one down. -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. Forum 1, Station Road, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, --PART-BOUNDARY=.19604170900.ZM22097.reading.sgi.com X-Zm-Content-Name: zbufferABC Content-Description: Text Content-Type: text/plain ; name="zbufferABC" ; charset=us-ascii ABCs of the Z-Buffer IRIS graphics systems utilize a hardware z-buffer to render images with hidden surfaces eliminated. The z-buffer hardware is configurable, meaning not only can its use be optimized for hidden surface elimination, it can be used for additional operations as well. This article describes the z-buffer, suggests how it can be used for simple hidden surface elimination, and provides solutions for some of the more complex operations, including applying decals, highlighting surface tessellations and generating line drawings with hidden lines removed. Many of the techniques described here are applicable to all IRIS graphics systems. The hardware-specific approaches, all of which have been noted as such, work with the GT/GTX architecture. The z-buffer is a set of 24-bit numbers, each of which relates to a pixel on the screen. Use of the z-buffer is enabled with the zbuffer command: zbuffer(TRUE); Points, lines, polygons, and characters are reduced during rendering to pixels, each with its own color and x and y coordinates. Also, when the z- buffer is enabled, a z coordinate is computed for each pixel. This coordinate effectively specifies the distance from pixel to eye. Before a pixel's color is written to the framebuffer, its z value is compared with the value already stored in the z-buffer. If the incoming pixel is nearer (that is, if it has a lower z value), its color is written into the framebuffer and its z is written into the z-buffer. If it is farther (that is, if it has a greater z value), the incoming color and z are discarded. Thus, at any point in the drawing, the values in the z-buffer represent the distance to the item which currently is closest to the eye. By first clearing the z-buffer to the maximum z value and then rendering all primitives using the zbuffer algorithm, an image including only the nearest surfaces to the eye is produced. Mapping Transformed Z to Screen Z --------------------------------- Mathematically, z coordinates are treated just like x and y coordinates. After transformation, clipping, and perspective division, they occupy the range -1.0 through 1.0. Just as you specify a viewport transformation to map x and y from this range to a window's boundaries, so must you specify a mapping of z coordinates. Because the 24-bit z-buffer on the GT and GTX graphics systems is unsigned, it supports the range OxOOOOOO through Oxffffff. Only values in the range OxOOOOOO through Ox7fffff are correctly iterated during rendering, however, so only 23 of the 24 z-buffer bits typically are used. (A use for the 24th bit will be demonstrated later in this article.) By default, GT and GTX graphics systems map those pixels nearest the eye (i.e. the ones at the near clip plane) to OxOOOOOO, while the pixels farthest from the eye (i.e., those at the far clip plane) are mapped to Ox7fffff. This can be changed with the lsetdepth command: lsetdepth(OxOOOOOO,Ox3fffff); Called like this. the mapping will be reduced to use only half of the hardware range. Recall also that each z-buffer location must be initialized to farthest prior to rendering. Application performance is increased if the z-buffer and the framebuffer are initialized at the same time. To accomplish this, replace the code sequence: cpack(Oxffffff); clear(); zclear(); /*clears z-buffer to Oxffffff*/ with: czclear(Oxffffff,Oxffffff); On GT and GTX hardware, czclear operates on the framebuffer and the z-buffer simultaneously only if the color argument (first) and the depth argument (second) are the same (see the czclear man page for details). This example has a white background and the z-buffer has been cleared to its maximum value. The fact that this value is greater than the greatest rendered value (Ox7fffff) has no effect on the rendering operation. It is also possible to achieve simultaneous clears with a black background, like so: czclear(OxOOOOOO,OxOOOOOO); For this to provide correct results, however, both the z mapping and the z comparison must be reversed: lsetdepth(Ox7fffff,0xOOOOOO); zfunction(ZF_GEQUAL); This mapping gives nearer pixels greater z-buffer values than farther pixels, with pixels at the near plane mapped to Ox7fffff, and those at the far plane mapped to OxOOOOOO (the value the z-buffer was cleared to). In order to correctly select the nearest pixel, the comparison function is simply reversed to select the pixel with the greater z value. (The default zfunction is ZF_LEQUAL.) It was previously asserted that a z-buffer value, in effect, specifies the distance from pixel to eye. While this is true, the relationship between distance and z is linear only in an orthographic projection. In the case of a true perspective projection, such as: perspective(fovy,aspect,near,far); the relationship is non-linear, sometimes very much so. The degree of non-linearity is controlled by the ratio of far to near in the perspective call. The greater the ratio, the greater the non-linearity. Figure 1 shows the equations relating screen z to eye z as a function of the ratio far/near in the perspective call. ------------------------------------------------------------------------------ When the projection matrix is defined by perspective (fovy, aspect, near, far); and the z viewport transformation is defined by lsetdepth (near ,far ); vp vp then z and z are related by the following equations: eye screen -- -- -- -- | | |far - near | far + near |far + near 2 far near | | vp vp| vp vp z = |---------- + -----------------| |--------------| + -------------- screen |far - near z (far - near)| | 2 | 2 | eye | | | -- -- -- -- far near(far - near ) vp vp ------------------------ far - near z = ------------------------------------------------------------------ eye (far + near) (far - near ) far + near vp vp vp vp z - ----------------------------- - -------------- screen 2 (far - near) 2 ------------------------------------------------------------------------------ Figure 1. The equations relating screen z to eye z. In practice, non-linearity increases z-buffer precision in a small range adjacent to the near clipping plane and reduces precision throughout the rest of the viewing volume. While some precision increase near the viewer can be desirable, the effect of substantial non-linearity is to defeat z-buffer operation throughout much of the viewing volume. Experience shows that ratios greater than 1000 have this undesired result. The ratio of far to near is most easily controlled by simply moving the near clipping plane away from the eye position. Note that changing near in the perspective call has no effect on the projection of x and y and so has little effect on the resulting image. Instead, its effect is limited to the position of the near clipping plane and the projection of z values. Because of this, you should always move the near plane as far from the eye as possible. Z-Buffered Decals ----------------- Because of the limitations of z-buffer precision and because the precision that exists is lost due to non-linear mapping, the IRIS z-buffer has difficulty in computing the correct intersection of nearly coplanar objects. As a result, objects intended to be coplanar, such as a stripe on a runway, or a marking on an airplane wing, are rendered very poorly when nothing more than the standard z-buffer algorithm is used (e.g. a runway shows through a stripe on it or a wing shows through a marking on it). This problem is referred to as the decal problem. GL commands writemask and zwritemask support a simple solution to the decal problem. In effect, they allow the use of a painter's algorithm (the last object written overwrites) among coplanar polygons, and yet they use the z- buffer algorithm to integrate coplanar polygons into the scene. The following pseudo-code sequence implements the algorithm (the GL commands designate real code). The GrayMaterial object is the surface that the RedMaterial object is drawn onto: zwritemask(OxOOOOOO); lmbind(MATERIAL,GrayMaterial); draw the underlying object lmbind(MATERIAL,RedMaterial); draw the overwriting object zwritemask(Oxffffff); wmpack(OxOOOOOOOO); /*RGB version of writemask*/ draw the underlying object again wmpack(Oxffffffff); Note that material does not matter during the second drawing of the GrayMaterial object because framebuffer colors are not modified. The writemask is returned to Oxffffffff when done to ensure that subsequent z-buffer operation will be normal. Outlined Polygons and Hidden Lines ---------------------------------- Now consider what's involved in outlining a polygon. The problem seems similar to rendering decals, except in this instance an outline segment shared between two (typically non-coplanar) polygons must be taken into account. The decal algorithm fails when a single decal is shared among multiple, non-coplanar polygons. The decal problem was solved by working around the inaccuracies of z projection and iteration. Assume now that the z-buffer works perfectly, meaning that coplanar objects match values pixel for pixel during rendering. In this case, the painting effect could be had simply by selecting the appropriate zfunction, thus avoiding the need for writemask tricks. For example, selecting the zfunction ZF_LEQUAL (pass if less than or equal) causes the second coplanar polygon to completely overwrite the first, because the z- values of the coplanar polygons are equal at each pixel where they coincide and equality passes the z test. Likewise, if zfunction ZF_LESS is chosen, the second coplanar polygon will be completely ignored, because the equal z values will never pass the test. This demonstrates that it is possible to accurately composite coplanar objects if their pixels match z for z. All that remains is to postulate an outline method that ensures matched z values. The method exists, and is known as hollow polygons. (Definition: A hollow polygon fills a subset of the pixels that would have been filled had the polygon been drawn normally. This subset is comprised of the pixels adjacent to the polygon perimeter. All filled pixels have color and values identical to their counterpart pixels in the filled polygon.) When a filled polygon is composited with its hollow counterpart, zfunction can be used to accurately control the results because the z values of shared pixels are identical. We can, for example, draw a gray solid object with each polygon outlined in red using the following code sequence: zbuffer(TRUE); zfunction(ZF_LEQUAL); /*this is the default*/ lmbind(MATERIAL,GrayMaterial); draw all polygons -- filled lmbind(MATERIAL,RedMaterial); draw all polygons -- hollow Changing the zfunction to ZF_LESS will arrive at same result by first drawing all the polygons hollow, and then drawing them filled: zbuffer(TRUE); zfunction(ZF_LESS); lmbind(MATERIAL,RedMaterial); draw all polygons -- hollow lmbind(MATERIAL,GrayMaterial); draw all polygons -- filled In both cases, all hidden surfaces are correctly removed and all outlines are drawn without pixel errors. A hollow polygon primitive is available in Silicon Graphics' new PowerVision. However, until you have PowerVision, you'll have to generate the hollow polygons yourself. This is best done using the 24th bit of the z-buffer as a stencil bit to control whether a pixel is writable or not. By doing this independently of the contents of the 23 depth bits, it's possible to stencil and z-buffer simultaneously. (WARNING: This algorithm operates correctly only on GT and GTX graphics systems.) The algorithm for hollow polygon generation is substantially more complex than any of the algorithms previously discussed. It will be described here one step at a time, first explaining what will happen, and then providing a pseudo code implementation. First, the z-buffer must be set up with a reverse mapping: zbuffer(TRUE); lsetdepth(Ox7fffff,0xOOOOOO); zfunction(ZF_GEQUAL); czclear(OxOOOOOOOO,OxOOOOOO); Then, to draw a single hollow polygon, first disable (for drawing purposes) all of the pixels in the polygon. Do this by setting the 24th bit of each pixel's z value, effectively making all values nearer than Ox7fffff, the mapping of the near plane: zbuffer(FALSE); backbuffer(FALSE); zdraw(TRUE); wmpack(Ox800000); cpack(Ox800000); fill the polygon Now enable only those pixels on the perimeter of the polygon. Do this by drawing a width-2 line around the perimeter, clearing the 24th z-buffer bit at each pixel drawn: cpack(OxOOOOOO); outline the polygon with a double-width line At this point, pixels on the perimeter of the polygon will have their original z values. Those in the interior will have values nearer than any generated during rendering and are therefore effectively masked. Now, we simply fill the polygon using normal z-buffer operation, which in fact fills only perimeter pixels -- creating a hollow polygon: zbuffer(TRUE); backbuffer(TRUE); zdraw(FALSE); wmpack(Oxffffffff); cpack(color); fill the polygon -- changing only perimeter pixel values The 24th bit of all z-buffer pixels that still can be set now must be cleared to ensure that future hollow polygons are not corrupted: zbuffer(FALSE); backbuffer(FALSE); zdraw(TRUE); wmpack(Ox800000); cpack(OxOOOOOO); fill the polygon Finally, all drawing states should be returned to reasonable values: zbuffer(TRUE); backbuffer(TRUE); zdraw(FALSE); wmpack(Oxffffffff); When hollow polygons are drawn back-to-back, many of the mode changes in the first and last steps can be skipped, resulting in improved performance. You may draw any solid as a line drawing with hidden lines removed by simply filling the hollow polygons with background color rather than with surface color. Conclusion ---------- The GT/GTX z-buffer is a powerful tool for use with applications -- beyond simple hidden-surface removal. In addition to the examples provided, the z- buffer has been used in programs to perform constructive solid geometry, shadow casting, and more. This article was reprinted with permission from Issue Number 11 of the IRIS Universe, a quarterly magazine of visual processing published by Silicon Graphics. To subscribe to the magazine, call (415) 962-3320. ABCs of the Z-Buffer IRIS graphics systems utilize a hardware z-buffer to render images with hidden surfaces eliminated. The z-buffer hardware is configurable, meaning not only can its use be optimized for hidden surface elimination, it can be used for additional operations as well. This article describes the z-buffer, suggests how it can be used for simple hidden surface elimination, and provides solutions for some of the more complex operations, including applying decals, highlighting surface tessellations and generating line drawings with hidden lines removed. Many of the techniques described here are applicable to all IRIS graphics systems. The hardware-specific approaches, all of which have been noted as such, work with the GT/GTX architecture. The z-buffer is a set of 24-bit numbers, each of which relates to a pixel on the screen. Use of the z-buffer is enabled with the zbuffer command: zbuffer(TRUE); Points, lines, polygons, and characters are reduced during rendering to pixels, each with its own color and x and y coordinates. Also, when the z- buffer is enabled, a z coordinate is computed for each pixel. This coordinate effectively specifies the distance from pixel to eye. Before a pixel's color is written to the framebuffer, its z value is compared with the value already stored in the z-buffer. If the incoming pixel is nearer (that is, if it has a lower z value), its color is written into the framebuffer and its z is written into the z-buffer. If it is farther (that is, if it has a greater z value), the incoming color and z are discarded. Thus, at any point in the drawing, the values in the z-buffer represent the distance to the item which currently is closest to the eye. By first clearing the z-buffer to the maximum z value and then rendering all primitives using the zbuffer algorithm, an image including only the nearest surfaces to the eye is produced. Mapping Transformed Z to Screen Z --------------------------------- Mathematically, z coordinates are treated just like x and y coordinates. After transformation, clipping, and perspective division, they occupy the range -1.0 through 1.0. Just as you specify a viewport transformation to map x and y from this range to a window's boundaries, so must you specify a mapping of z coordinates. Because the 24-bit z-buffer on the GT and GTX graphics systems is unsigned, it supports the range OxOOOOOO through Oxffffff. Only values in the range OxOOOOOO through Ox7fffff are correctly iterated during rendering, however, so only 23 of the 24 z-buffer bits typically are used. (A use for the 24th bit will be demonstrated later in this article.) By default, GT and GTX graphics systems map those pixels nearest the eye (i.e. the ones at the near clip plane) to OxOOOOOO, while the pixels farthest from the eye (i.e., those at the far clip plane) are mapped to Ox7fffff. This can be changed with the lsetdepth command: lsetdepth(OxOOOOOO,Ox3fffff); Called like this. the mapping will be reduced to use only half of the hardware range. Recall also that each z-buffer location must be initialized to farthest prior to rendering. Application performance is increased if the z-buffer and the framebuffer are initialized at the same time. To accomplish this, replace the code sequence: cpack(Oxffffff); clear(); zclear(); /*clears z-buffer to Oxffffff*/ with: czclear(Oxffffff,Oxffffff); On GT and GTX hardware, czclear operates on the framebuffer and the z-buffer simultaneously only if the color argument (first) and the depth argument (second) are the same (see the czclear man page for details). This example has a white background and the z-buffer has been cleared to its maximum value. The fact that this value is greater than the greatest rendered value (Ox7fffff) has no effect on the rendering operation. It is also possible to achieve simultaneous clears with a black background, like so: czclear(OxOOOOOO,OxOOOOOO); For this to provide correct results, however, both the z mapping and the z comparison must be reversed: lsetdepth(Ox7fffff,0xOOOOOO); zfunction(ZF_GEQUAL); This mapping gives nearer pixels greater z-buffer values than farther pixels, with pixels at the near plane mapped to Ox7fffff, and those at the far plane mapped to OxOOOOOO (the value the z-buffer was cleared to). In order to correctly select the nearest pixel, the comparison function is simply reversed to select the pixel with the greater z value. (The default zfunction is ZF_LEQUAL.) It was previously asserted that a z-buffer value, in effect, specifies the distance from pixel to eye. While this is true, the relationship between distance and z is linear only in an orthographic projection. In the case of a true perspective projection, such as: perspective(fovy,aspect,near,far); the relationship is non-linear, sometimes very much so. The degree of non-linearity is controlled by the ratio of far to near in the perspective call. The greater the ratio, the greater the non-linearity. Figure 1 shows the equations relating screen z to eye z as a function of the ratio far/near in the perspective call. ------------------------------------------------------------------------------ When the projection matrix is defined by perspective (fovy, aspect, near, far); and the z viewport transformation is defined by lsetdepth (near ,far ); vp vp then z and z are related by the following equations: eye screen -- -- -- -- | | |far - near | far + near |far + near 2 far near | | vp vp| vp vp z = |---------- + -----------------| |--------------| + -------------- screen |far - near z (far - near)| | 2 | 2 | eye | | | -- -- -- -- far near(far - near ) vp vp ------------------------ far - near z = ------------------------------------------------------------------ eye (far + near) (far - near ) far + near vp vp vp vp z - ----------------------------- - -------------- screen 2 (far - near) 2 ------------------------------------------------------------------------------ Figure 1. The equations relating screen z to eye z. In practice, non-linearity increases z-buffer precision in a small range adjacent to the near clipping plane and reduces precision throughout the rest of the viewing volume. While some precision increase near the viewer can be desirable, the effect of substantial non-linearity is to defeat z-buffer operation throughout much of the viewing volume. Experience shows that ratios greater than 1000 have this undesired result. The ratio of far to near is most easily controlled by simply moving the near clipping plane away from the eye position. Note that changing near in the perspective call has no effect on the projection of x and y and so has little effect on the resulting image. Instead, its effect is limited to the position of the near clipping plane and the projection of z values. Because of this, you should always move the near plane as far from the eye as possible. Z-Buffered Decals ----------------- Because of the limitations of z-buffer precision and because the precision that exists is lost due to non-linear mapping, the IRIS z-buffer has difficulty in computing the correct intersection of nearly coplanar objects. As a result, objects intended to be coplanar, such as a stripe on a runway, or a marking on an airplane wing, are rendered very poorly when nothing more than the standard z-buffer algorithm is used (e.g. a runway shows through a stripe on it or a wing shows through a marking on it). This problem is referred to as the decal problem. GL commands writemask and zwritemask support a simple solution to the decal problem. In effect, they allow the use of a painter's algorithm (the last object written overwrites) among coplanar polygons, and yet they use the z- buffer algorithm to integrate coplanar polygons into the scene. The following pseudo-code sequence implements the algorithm (the GL commands designate real code). The GrayMaterial object is the surface that the RedMaterial object is drawn onto: zwritemask(OxOOOOOO); lmbind(MATERIAL,GrayMaterial); draw the underlying object lmbind(MATERIAL,RedMaterial); draw the overwriting object zwritemask(Oxffffff); wmpack(OxOOOOOOOO); /*RGB version of writemask*/ draw the underlying object again wmpack(Oxffffffff); Note that material does not matter during the second drawing of the GrayMaterial object because framebuffer colors are not modified. The writemask is returned to Oxffffffff when done to ensure that subsequent z-buffer operation will be normal. Outlined Polygons and Hidden Lines ---------------------------------- Now consider what's involved in outlining a polygon. The problem seems similar to rendering decals, except in this instance an outline segment shared between two (typically non-coplanar) polygons must be taken into account. The decal algorithm fails when a single decal is shared among multiple, non-coplanar polygons. The decal problem was solved by working around the inaccuracies of z projection and iteration. Assume now that the z-buffer works perfectly, meaning that coplanar objects match values pixel for pixel during rendering. In this case, the painting effect could be had simply by selecting the appropriate zfunction, thus avoiding the need for writemask tricks. For example, selecting the zfunction ZF_LEQUAL (pass if less than or equal) causes the second coplanar polygon to completely overwrite the first, because the z- values of the coplanar polygons are equal at each pixel where they coincide and equality passes the z test. Likewise, if zfunction ZF_LESS is chosen, the second coplanar polygon will be completely ignored, because the equal z values will never pass the test. This demonstrates that it is possible to accurately composite coplanar objects if their pixels match z for z. All that remains is to postulate an outline method that ensures matched z values. The method exists, and is known as hollow polygons. (Definition: A hollow polygon fills a subset of the pixels that would have been filled had the polygon been drawn normally. This subset is comprised of the pixels adjacent to the polygon perimeter. All filled pixels have color and values identical to their counterpart pixels in the filled polygon.) When a filled polygon is composited with its hollow counterpart, zfunction can be used to accurately control the results because the z values of shared pixels are identical. We can, for example, draw a gray solid object with each polygon outlined in red using the following code sequence: zbuffer(TRUE); zfunction(ZF_LEQUAL); /*this is the default*/ lmbind(MATERIAL,GrayMaterial); draw all polygons -- filled lmbind(MATERIAL,RedMaterial); draw all polygons -- hollow Changing the zfunction to ZF_LESS will arrive at same result by first drawing all the polygons hollow, and then drawing them filled: zbuffer(TRUE); zfunction(ZF_LESS); lmbind(MATERIAL,RedMaterial); draw all polygons -- hollow lmbind(MATERIAL,GrayMaterial); draw all polygons -- filled In both cases, all hidden surfaces are correctly removed and all outlines are drawn without pixel errors. A hollow polygon primitive is available in Silicon Graphics' new PowerVision. However, until you have PowerVision, you'll have to generate the hollow polygons yourself. This is best done using the 24th bit of the z-buffer as a stencil bit to control whether a pixel is writable or not. By doing this independently of the contents of the 23 depth bits, it's possible to stencil and z-buffer simultaneously. (WARNING: This algorithm operates correctly only on GT and GTX graphics systems.) The algorithm for hollow polygon generation is substantially more complex than any of the algorithms previously discussed. It will be described here one step at a time, first explaining what will happen, and then providing a pseudo code implementation. First, the z-buffer must be set up with a reverse mapping: zbuffer(TRUE); lsetdepth(Ox7fffff,0xOOOOOO); zfunction(ZF_GEQUAL); czclear(OxOOOOOOOO,OxOOOOOO); Then, to draw a single hollow polygon, first disable (for drawing purposes) all of the pixels in the polygon. Do this by setting the 24th bit of each pixel's z value, effectively making all values nearer than Ox7fffff, the mapping of the near plane: zbuffer(FALSE); backbuffer(FALSE); zdraw(TRUE); wmpack(Ox800000); cpack(Ox800000); fill the polygon Now enable only those pixels on the perimeter of the polygon. Do this by drawing a width-2 line around the perimeter, clearing the 24th z-buffer bit at each pixel drawn: cpack(OxOOOOOO); outline the polygon with a double-width line At this point, pixels on the perimeter of the polygon will have their original z values. Those in the interior will have values nearer than any generated during rendering and are therefore effectively masked. Now, we simply fill the polygon using normal z-buffer operation, which in fact fills only perimeter pixels -- creating a hollow polygon: zbuffer(TRUE); backbuffer(TRUE); zdraw(FALSE); wmpack(Oxffffffff); cpack(color); fill the polygon -- changing only perimeter pixel values The 24th bit of all z-buffer pixels that still can be set now must be cleared to ensure that future hollow polygons are not corrupted: zbuffer(FALSE); backbuffer(FALSE); zdraw(TRUE); wmpack(Ox800000); cpack(OxOOOOOO); fill the polygon Finally, all drawing states should be returned to reasonable values: zbuffer(TRUE); backbuffer(TRUE); zdraw(FALSE); wmpack(Oxffffffff); When hollow polygons are drawn back-to-back, many of the mode changes in the first and last steps can be skipped, resulting in improved performance. You may draw any solid as a line drawing with hidden lines removed by simply filling the hollow polygons with background color rather than with surface color. Conclusion ---------- The GT/GTX z-buffer is a powerful tool for use with applications -- beyond simple hidden-surface removal. In addition to the examples provided, the z- buffer has been used in programs to perform constructive solid geometry, shadow casting, and more. This article was reprinted with permission from Issue Number 11 of the IRIS Universe, a quarterly magazine of visual processing published by Silicon Graphics. To subscribe to the magazine, call (415) 962-3320. --PART-BOUNDARY=.19604170900.ZM22097.reading.sgi.com-- From guest Wed Apr 17 11:34:50 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA06179; Wed, 17 Apr 1996 11:28:58 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA06176; Wed, 17 Apr 1996 11:28:58 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA07883; Wed, 17 Apr 96 11:28:52 -0700 Received: from barney.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id LAA08525; Wed, 17 Apr 1996 11:28:42 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id RAA00927; Wed, 17 Apr 1996 17:19:58 +0100 From: "Rob Jenkins" Message-Id: <9604171719.ZM925@barney.reading.sgi.com> Date: Wed, 17 Apr 1996 17:19:57 +0100 In-Reply-To: william_marinelli@ntsc.navy.mil "Re: Proceedings of SIGGRAPH'93" (Apr 17, 10:50am) References: <9603178297.AA829763513@CCMAIL.NTSC.NAVY.MIL> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: william_marinelli@ntsc.navy.mil, info-performer@sgi.sgi.com Subject: Re: Proceedings of SIGGRAPH'93 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19604171719.ZM925.reading.sgi.com" Status: O -- --PART-BOUNDARY=.19604171719.ZM925.reading.sgi.com Content-Type: text/plain; charset=us-ascii On Apr 17, 10:50am, william_marinelli@ntsc.navy.mil wrote: > Subject: Re: Proceedings of SIGGRAPH'93 > > On page 110 we are told that there is frame buffer memory > allocated to support 256 bits per pixel, which sounds very impressive. I > think it's a misprint because in my mind I can only account for 56. > Please confirm/refute. > >-- End of excerpt from william_marinelli@ntsc.navy.mil you're forgetting the multisample buffers I think. 256 is the minimum ( with 1 RM4 board ) 1 RM board: 1280x1024x256 deep , 48 bit FB,BB, 32bit Z, WIDs, CIDs etc,but no multisamples 2 RM boards: 1280x1024x512 deep , 48 bit FB,BB and up to 8 multisamples 4 RM boards: 1280x1024x1024 deep, 48 bit FB,BB and up to 16 multisamples and you're right - pretty impressive. I've attached a good Pipeline article 'Calculating RealityEngine Pixel Depth' Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. Forum 1, Station Road, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, --PART-BOUNDARY=.19604171719.ZM925.reading.sgi.com X-Zm-Content-Name: repixeldepthcalc Content-Description: Text Content-Type: text/plain ; name="repixeldepthcalc" ; charset=us-ascii Calculating RealityEngine Pixel Depth In September 1992, Silicon Graphics released another high performance graphics system known as RealityEngine. This graphics subsystem can be installed into DieHard or rack systems and is useable with both the R3000 and R4000 cpu family lines. During the design phase of the RealityEngine, two considerations were paramount: 1) antialiasing without penalty and 2) increased texture capabilities. This article will primarily address the topic of pixel depth, which impacts multi-sampling, RealityEngine's method of antialising. In addition to these two items, other features have been added or enhanced. With the RealityEngine it is possible to have stereo on a per window basis. Another feature of this system is 12 bits per component of RGBA. In addition to increased textured performance, many capabilities have been added to the texture mapping set of functions, including three dimensional textures, fast hardware shadow algortihms and an increased number of texture filtering functions. There are also methods of sharpening textures for extreme magnification. Detail Texture is another method for looking at polygons up close. Texture lookup tables are available for greater control of the final output. For more information on texture mapping, see chapter 18 of the Graphics Library Programming Manual. In the past, framebuffer* size and configurations have been fairly static. (*The term "framebuffer is often used inconsistently. It is best to think of each of the available bitplane sets as a seperate framebuffer, for example, overlay, underlay, popup, zbuffer, etc. The multisample buffer is another buffer assosciated with the normal buffer. For the purposes of this article, "framebuffer will refer to the normal buffer.) With the advent of the VGX, came increased flexibility in configuration. A bank of memory could be either used for accumulation buffering or additional texture memory. The RealityEngine introduces a framebuffer that is very flexible in attainable configurations. The GL programmer has more flexibility in making ordered and reasonable requests to the GL such that all requests will be honored. To fully utilize this flexibility, one must first understand the underlying concepts. (For a discussion on the multisample API, see the GL Programmers Guide, and the manual pages for mssize and multisample. Also see the Crimson and POWER Series technical reports for detailed information about the RE architecture. Also figure 1 below.) Upon consulting these sources, you will notice that on occasion a requested configuration may not be granted. This is due to the amount GL resources that may be requested in contrast with the amount of hardware that is installed. When more resources are requested than are available, the GL will determine which requests will be honored. RealityEngine supports one, two, or four Raster Memory (RM) boards. Each RM board contains roughly 40MB of memory for framebuffer configurations. The final configuration of the framebuffer is determined by the video output Format (VOF) and GL resources such as multisampling, accumulation buffer, stencil, z-buffer, high resolution color, and buffer modes (single, double, stereo). ----------------------------------------- | GE Board | | | | ---- | | |-| |-| | | | | |--| | | | | MPG CP |-| |-| | T | | ___ ___ | |--| | | | |-->| |-->| |-->|-| |-|--->| | | --- --- | |--| | | B | | |-| |-| | U | | | |--| | | S | | |-| |-| | | | | |--| | | | | -| |- | | | ---- | | | | / \ | | / \ | | / \ | | / \ | | / \ | | | | ----------------------------- | | | --------- | | | | | i860XP | | | | | --------- -------- | | | | ^ | 2MB | | | | | |<------->| DRAM | | | | | | -------- | | | | v | | | | ------- | | | | | GEF | | | | | ------- | | | | | | | ----------------------------- | | Close-up of the GE | | | ----------------------------------------- Figure 1a. Reality Engine Architecture (GE Board) ---------------------------------------------- | RM Board | | | | | ----------------- | | | | | |-----| #--| | | | | |-->| #-#-#-#--| | |--->| | | T| | #--| | | P | | | ----------------- | | | B| | | B | | U| S 20 Spans | U | | S| | | S | | | ----------------- | | | | | |-----| #--| | | | | |-->| #-#-#-#--| | |--->| | | | | #--| | | | | | ----------------- | | | | | / \ | | / \ | | / \ | | / \ | | / \ | | --------------------------------------- | | | -------- | | | | ------------------- |IMP 0 |-->| | | | | | | -------- | | | | | --- --- --- --- | | | | | | |PG|--|TA|--|TD|--|IB|--> | | | | | --- --- --- --- | | | | | | | | | | | | | ------------ | | | | | | | 4MB DRAM | | | | | | ------------ | | | | | | ------- | | | | | |IMP 15|-->| | | | | ------- | | | --------------------------------------- | | Close-up of one span | | | ---------------------------------------------- Figure 1b. Reality Engine Architecture (RM Board) ---------------------------------------------------- | DG Board | | | | | ------- ------ | | | |--->| XMAP |--->| LUT |---> | ------- | | | -------- ------- |--|DAC's|====> | | | | | | |====> | | P| | ------- | | | | 10 XMAPS | --------- | | B| | |Digital| | | U| | |--| Video |--> | | S| | --------- | | | | | | | | -------- ------- | -------- | | |--->| XMAP |--->| LUT |---> |--|Comp. |---> | | | -------- ------- | |video | | | | -------- | | | ---------------------------------------------------- Figure 1c. Reality Engine Architecture (DG Board) The ability of the GL to meet the requested modes is based upon the "depth" of its pixels, that is, the number of words that are available. To relate pixel depth to the ability to honor mode requests, consider the following example. If a framebuffer is 8 bit RGB, 8 bits times 3 channels is 24 bits, or 1.5 words. The normal buffer requires the use of 2 words whereas each multisample will actually only require the computed 1.5 words. If the framebuffer is double buffered, then 4 words are being utilized. RealityEngine provides for 12 bits per component as well. Using 12 bits per component, a single buffered RGB window requires 48 bits or 3 words. Putting the same window into double buffer mode now takes 6 words. Similarly the accumulation buffer can be configured to be either 12 or 24 bits per component, requiring 3 or 6 words respectively. The RealityEngine zbuffer is 32 bits- 2 more words. The stencil buffer requires an additional 1/2 word. When adding the total number of words, add 4 words for overhead (overlays, underlays, etc.). -------------------------------------------------- | 8 Bit RGB, DBL Buf, 8 LoRes samples+ HW accbuf | | | | Add Words | | | | 4 w. overhead | | 2 w. Front Buffer | | 2 w. Back Buffer | | (1.5w.) 8 samples (color) | | (2 w.) 8 samples (Z) | | ____________________ | | 36 words (no room for HW accbub) | | | | * assume 1024x1280 | | | -------------------------------------------------- Figure 2. Word Requirement example Using similar computations, the amount of memory required for multi-sampling can be computed. The multisample buffer can be configured to do 0, 4, 8, or 16 samples per pixel. To calculate the number of words per pixel for multisampling, multiply the number of samples requested by the number of words computed in the preceeding paragraph. To do 4 multisamples for a 12 bit RGB window requires 4 * (3 words RGBA + 2 words Z) + 3 words RGB normal buffer = 23 words. Add 3 more words if the window is doublebuffered. Similarly, an 8 bit RGB window requires 17 words for singlebuffer and 19 for doublebuffer. (Keep in mind the 4 words for overhead.) Notice in these examples no allocation of memory for stencil or accumulation buffers has been made. After calculating the number of words required, round up to 16, 32, or 64, as these are the number of words that are supported for pixel depths of small, medium, and large. Using Tiles to Calculate Pixel Depth for VOF The preceeding information shows how to calculate the pixel depth that is required for a group of GL mode requests. To determine how deep pixels can be for different VOFs, calculate the depth of the current VOF, by running /usr/gfx/gfxinfo which will return the current pixel depth. This depth can be altered by changing the VOF. The underlying mechanisms of adding depth to a pixel by changing the VOF have to do with the way the screen is tiled. A tile is a segment of screen space that is 80 pixels wide by 8 pixels high. Thus the default VOF of 1280x1024 is a screen that is 16x128 tiles. Putting the monitor into NTSC mode changes the screen resolution to 646x485, or 9x61 tiles. Notice that 646/80 = 8.075. Since all pixels must be covered and tiles come in integer quantities, we need to step up to get 9 tiles wide. Similarly PAL format is 768 x 575 (10 x 72 tiles) and HD TV is 1600 x 1200 (20 x 150 tiles). --------------------------------- /| /| / | / | /__|____________________________/ | ^ | | | | | | | | | Width of VOF/80 * | | | | | X | | | | | Height of VOF/8 * Height | | |<- 80 -> | | | | |________ ^ | | | | / /| | 8 | | | | /|______/_|_V_________________|__| | |/_______/ / | / / | | / | / |/ 16 v |/_______|/_____________________/ / * Round up to nearest integer <-------------------------------> Width Figure 3. Tiles required by VOF In addition to computing the number of tiles utilized by a given VOF, it is also necessary to compute how the memory from the RM boards can be distributed among the tiles, i.e., compute pixel depth. (For the purposes of this article and these computations, one word is 16 bits.) It is important to consider that you may be requesting more GL resources than are available, and how the VOF effects the request. For each RM board there are 12 80x1024X16 words. Using the default VOF of 1280x1024, with 1 RM board, there are only 16 words per pixel available. This is not enough memory to do the simple multisample example above. Either add an additional RM board to bring the total t o 32 words per pixel or we must change the VOF. ------------------------------------------------------------ | 12 bit RGBA (48 bits) 8 bit RGB (24 bits) | |Color Buffer 3 w (48 bits) 2 w (24 bits) | |Zbuffer 2 w (32 bits) 2 w (32 bits) | |Stencil 1 w ( 8 bits) 0.5 w (8 bits) | |AccBuf 3/6 w | |MS Color 3 w/sample 1.5 w/sample | |MSZ 2 w/sample 1 bit.sample | |Stencil .5 w/sample 1 bit.sample | | | |Overhead* 4 w 4 w | | | |* Overhead: WIDs, CIDs, PUP, Overlay, Underlay | | | ------------------------------------------------------------ Figure 4. HW Configuration Example It may seem odd that changing the VOF could also change pixel depth. The previous tile examples showed how to compute the number of, tiles utilized by each VOF. In some of the examples, such as NTSC and PAL, fewer tiles are needed than are available. These extra tiles are then available to add to the pixel depth of the tiles that are used. The use of the extra tiles must be uniformly distributed over the screen area used, i.e. pixel depth for a given VOF must be uniformly 16, 32, or 64. To see if changing the VOF will increase pixel depth, take.the ratio of the total number of tiles (2048 per RM) to tiles required by the new VOF. Since this number must be 1, 2, or 4 (remember the GL only supports pixel depths of 16, 32 or 64), you need to floor the ratio to these numbers. Using the example of 1 RM board, the VOF can be changed to NTSC. Previously we calculated the number of tiles required by NTSC to be 549 tiles. The computed ratio is then 3.73. We must take the next lowest allowable integer value 2 to arrive at a pixel depth of 2*16, or 32 words per pixel. This is then sufficient to do the previous multisample example. Choosing a VOF that quartered the screen tiles exactly, would give a ratio 4. This would give a pixel depth of 4*16 or 64 words deep. Such a format could be 640x512 (8x64 tiles). Similarly, HDTV requires 3000 tiles. The ratio 2048/3000 < 1, hence HDTV can not be supported on a 1 RM system. To predetermine whether your configuration request will be possible, do the following: 1) Use table 1 to calculate the number of words required by your application (ke ep in mind the 4 words of overhead). 2) Compute the available depth in words: | # RMs * 2048 | floor(1,2,4) | ______________| * 16 | tiles in VOF | 3) Subtract the result of step 1 from step 2. 4) A positive result from step 3 is favorable. If the result is negative, you mu st: A) back off on requested features (use getgconfig();) B) add an RM board (or two) C) lower VOF resolution even further. There may be some configurations which will never be honored. This is the case anytime the required word count exceeds 64. Calculating RealityEngine Pixel Depth In September 1992, Silicon Graphics released another high performance graphics system known as RealityEngine. This graphics subsystem can be installed into DieHard or rack systems and is useable with both the R3000 and R4000 cpu family lines. During the design phase of the RealityEngine, two considerations were paramount: 1) antialiasing without penalty and 2) increased texture capabilities. This article will primarily address the topic of pixel depth, which impacts multi-sampling, RealityEngine's method of antialising. In addition to these two items, other features have been added or enhanced. With the RealityEngine it is possible to have stereo on a per window basis. Another feature of this system is 12 bits per component of RGBA. In addition to increased textured performance, many capabilities have been added to the texture mapping set of functions, including three dimensional textures, fast hardware shadow algortihms and an increased number of texture filtering functions. There are also methods of sharpening textures for extreme magnification. Detail Texture is another method for looking at polygons up close. Texture lookup tables are available for greater control of the final output. For more information on texture mapping, see chapter 18 of the Graphics Library Programming Manual. In the past, framebuffer* size and configurations have been fairly static. (*The term "framebuffer is often used inconsistently. It is best to think of each of the available bitplane sets as a seperate framebuffer, for example, overlay, underlay, popup, zbuffer, etc. The multisample buffer is another buffer assosciated with the normal buffer. For the purposes of this article, "framebuffer will refer to the normal buffer.) With the advent of the VGX, came increased flexibility in configuration. A bank of memory could be either used for accumulation buffering or additional texture memory. The RealityEngine introduces a framebuffer that is very flexible in attainable configurations. The GL programmer has more flexibility in making ordered and reasonable requests to the GL such that all requests will be honored. To fully utilize this flexibility, one must first understand the underlying concepts. (For a discussion on the multisample API, see the GL Programmers Guide, and the manual pages for mssize and multisample. Also see the Crimson and POWER Series technical reports for detailed information about the RE architecture. Also figure 1 below.) Upon consulting these sources, you will notice that on occasion a requested configuration may not be granted. This is due to the amount GL resources that may be requested in contrast with the amount of hardware that is installed. When more resources are requested than are available, the GL will determine which requests will be honored. RealityEngine supports one, two, or four Raster Memory (RM) boards. Each RM board contains roughly 40MB of memory for framebuffer configurations. The final configuration of the framebuffer is determined by the video output Format (VOF) and GL resources such as multisampling, accumulation buffer, stencil, z-buffer, high resolution color, and buffer modes (single, double, stereo). ----------------------------------------- | GE Board | | | | ---- | | |-| |-| | | | | |--| | | | | MPG CP |-| |-| | T | | ___ ___ | |--| | | | |-->| |-->| |-->|-| |-|--->| | | --- --- | |--| | | B | | |-| |-| | U | | | |--| | | S | | |-| |-| | | | | |--| | | | | -| |- | | | ---- | | | | / \ | | / \ | | / \ | | / \ | | / \ | | | | ----------------------------- | | | --------- | | | | | i860XP | | | | | --------- -------- | | | | ^ | 2MB | | | | | |<------->| DRAM | | | | | | -------- | | | | v | | | | ------- | | | | | GEF | | | | | ------- | | | | | | | ----------------------------- | | Close-up of the GE | | | ----------------------------------------- Figure 1a. Reality Engine Architecture (GE Board) ---------------------------------------------- | RM Board | | | | | ----------------- | | | | | |-----| #--| | | | | |-->| #-#-#-#--| | |--->| | | T| | #--| | | P | | | ----------------- | | | B| | | B | | U| S 20 Spans | U | | S| | | S | | | ----------------- | | | | | |-----| #--| | | | | |-->| #-#-#-#--| | |--->| | | | | #--| | | | | | ----------------- | | | | | / \ | | / \ | | / \ | | / \ | | / \ | | --------------------------------------- | | | -------- | | | | ------------------- |IMP 0 |-->| | | | | | | -------- | | | | | --- --- --- --- | | | | | | |PG|--|TA|--|TD|--|IB|--> | | | | | --- --- --- --- | | | | | | | | | | | | | ------------ | | | | | | | 4MB DRAM | | | | | | ------------ | | | | | | ------- | | | | | |IMP 15|-->| | | | | ------- | | | --------------------------------------- | | Close-up of one span | | | ---------------------------------------------- Figure 1b. Reality Engine Architecture (RM Board) ---------------------------------------------------- | DG Board | | | | | ------- ------ | | | |--->| XMAP |--->| LUT |---> | ------- | | | -------- ------- |--|DAC's|====> | | | | | | |====> | | P| | ------- | | | | 10 XMAPS | --------- | | B| | |Digital| | | U| | |--| Video |--> | | S| | --------- | | | | | | | | -------- ------- | -------- | | |--->| XMAP |--->| LUT |---> |--|Comp. |---> | | | -------- ------- | |video | | | | -------- | | | ---------------------------------------------------- Figure 1c. Reality Engine Architecture (DG Board) The ability of the GL to meet the requested modes is based upon the "depth" of its pixels, that is, the number of words that are available. To relate pixel depth to the ability to honor mode requests, consider the following example. If a framebuffer is 8 bit RGB, 8 bits times 3 channels is 24 bits, or 1.5 words. The normal buffer requires the use of 2 words whereas each multisample will actually only require the computed 1.5 words. If the framebuffer is double buffered, then 4 words are being utilized. RealityEngine provides for 12 bits per component as well. Using 12 bits per component, a single buffered RGB window requires 48 bits or 3 words. Putting the same window into double buffer mode now takes 6 words. Similarly the accumulation buffer can be configured to be either 12 or 24 bits per component, requiring 3 or 6 words respectively. The RealityEngine zbuffer is 32 bits- 2 more words. The stencil buffer requires an additional 1/2 word. When adding the total number of words, add 4 words for overhead (overlays, underlays, etc.). -------------------------------------------------- | 8 Bit RGB, DBL Buf, 8 LoRes samples+ HW accbuf | | | | Add Words | | | | 4 w. overhead | | 2 w. Front Buffer | | 2 w. Back Buffer | | (1.5w.) 8 samples (color) | | (2 w.) 8 samples (Z) | | ____________________ | | 36 words (no room for HW accbub) | | | | * assume 1024x1280 | | | -------------------------------------------------- Figure 2. Word Requirement example Using similar computations, the amount of memory required for multi-sampling can be computed. The multisample buffer can be configured to do 0, 4, 8, or 16 samples per pixel. To calculate the number of words per pixel for multisampling, multiply the number of samples requested by the number of words computed in the preceeding paragraph. To do 4 multisamples for a 12 bit RGB window requires 4 * (3 words RGBA + 2 words Z) + 3 words RGB normal buffer = 23 words. Add 3 more words if the window is doublebuffered. Similarly, an 8 bit RGB window requires 17 words for singlebuffer and 19 for doublebuffer. (Keep in mind the 4 words for overhead.) Notice in these examples no allocation of memory for stencil or accumulation buffers has been made. After calculating the number of words required, round up to 16, 32, or 64, as these are the number of words that are supported for pixel depths of small, medium, and large. Using Tiles to Calculate Pixel Depth for VOF The preceeding information shows how to calculate the pixel depth that is required for a group of GL mode requests. To determine how deep pixels can be for different VOFs, calculate the depth of the current VOF, by running /usr/gfx/gfxinfo which will return the current pixel depth. This depth can be altered by changing the VOF. The underlying mechanisms of adding depth to a pixel by changing the VOF have to do with the way the screen is tiled. A tile is a segment of screen space that is 80 pixels wide by 8 pixels high. Thus the default VOF of 1280x1024 is a screen that is 16x128 tiles. Putting the monitor into NTSC mode changes the screen resolution to 646x485, or 9x61 tiles. Notice that 646/80 = 8.075. Since all pixels must be covered and tiles come in integer quantities, we need to step up to get 9 tiles wide. Similarly PAL format is 768 x 575 (10 x 72 tiles) and HD TV is 1600 x 1200 (20 x 150 tiles). --------------------------------- /| /| / | / | /__|____________________________/ | ^ | | | | | | | | | Width of VOF/80 * | | | | | X | | | | | Height of VOF/8 * Height | | |<- 80 -> | | | | |________ ^ | | | | / /| | 8 | | | | /|______/_|_V_________________|__| | |/_______/ / | / / | | / | / |/ 16 v |/_______|/_____________________/ / * Round up to nearest integer <-------------------------------> Width Figure 3. Tiles required by VOF In addition to computing the number of tiles utilized by a given VOF, it is also necessary to compute how the memory from the RM boards can be distributed among the tiles, i.e., compute pixel depth. (For the purposes of this article and these computations, one word is 16 bits.) It is important to consider that you may be requesting more GL resources than are available, and how the VOF effects the request. For each RM board there are 12 80x1024X16 words. Using the default VOF of 1280x1024, with 1 RM board, there are only 16 words per pixel available. This is not enough memory to do the simple multisample example above. Either add an additional RM board to bring the total t o 32 words per pixel or we must change the VOF. ------------------------------------------------------------ | 12 bit RGBA (48 bits) 8 bit RGB (24 bits) | |Color Buffer 3 w (48 bits) 2 w (24 bits) | |Zbuffer 2 w (32 bits) 2 w (32 bits) | |Stencil 1 w ( 8 bits) 0.5 w (8 bits) | |AccBuf 3/6 w | |MS Color 3 w/sample 1.5 w/sample | |MSZ 2 w/sample 1 bit.sample | |Stencil .5 w/sample 1 bit.sample | | | |Overhead* 4 w 4 w | | | |* Overhead: WIDs, CIDs, PUP, Overlay, Underlay | | | ------------------------------------------------------------ Figure 4. HW Configuration Example It may seem odd that changing the VOF could also change pixel depth. The previous tile examples showed how to compute the number of, tiles utilized by each VOF. In some of the examples, such as NTSC and PAL, fewer tiles are needed than are available. These extra tiles are then available to add to the pixel depth of the tiles that are used. The use of the extra tiles must be uniformly distributed over the screen area used, i.e. pixel depth for a given VOF must be uniformly 16, 32, or 64. To see if changing the VOF will increase pixel depth, take.the ratio of the total number of tiles (2048 per RM) to tiles required by the new VOF. Since this number must be 1, 2, or 4 (remember the GL only supports pixel depths of 16, 32 or 64), you need to floor the ratio to these numbers. Using the example of 1 RM board, the VOF can be changed to NTSC. Previously we calculated the number of tiles required by NTSC to be 549 tiles. The computed ratio is then 3.73. We must take the next lowest allowable integer value 2 to arrive at a pixel depth of 2*16, or 32 words per pixel. This is then sufficient to do the previous multisample example. Choosing a VOF that quartered the screen tiles exactly, would give a ratio 4. This would give a pixel depth of 4*16 or 64 words deep. Such a format could be 640x512 (8x64 tiles). Similarly, HDTV requires 3000 tiles. The ratio 2048/3000 < 1, hence HDTV can not be supported on a 1 RM system. To predetermine whether your configuration request will be possible, do the following: 1) Use table 1 to calculate the number of words required by your application (ke ep in mind the 4 words of overhead). 2) Compute the available depth in words: | # RMs * 2048 | floor(1,2,4) | ______________| * 16 | tiles in VOF | 3) Subtract the result of step 1 from step 2. 4) A positive result from step 3 is favorable. If the result is negative, you mu st: A) back off on requested features (use getgconfig();) B) add an RM board (or two) C) lower VOF resolution even further. There may be some configurations which will never be honored. This is the case anytime the required word count exceeds 64. --PART-BOUNDARY=.19604171719.ZM925.reading.sgi.com-- From guest Wed Apr 17 12:14:04 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA06444; Wed, 17 Apr 1996 12:07:37 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA06441; Wed, 17 Apr 1996 12:07:36 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA09967; Wed, 17 Apr 96 12:07:32 -0700 Received: from server1.ctc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA11574; Wed, 17 Apr 1996 12:07:10 -0700 Received: by server1.ctc.com (5.65/DEC-Ultrix/4.3) id AA05951; Wed, 17 Apr 1996 13:58:08 -0400 Received: by sgi84.ctc.com (940816.SGI.8.6.9/930416.SGI.AUTO) id NAA12127; Wed, 17 Apr 1996 13:58:05 -0400 Date: Wed, 17 Apr 1996 13:58:05 -0400 From: koopman@ctc.com (Michael G. Koopman) Message-Id: <199604171758.NAA12127@sgi84.ctc.com> To: info-performer@sgi.sgi.com In-Reply-To: Gazza's message of Wed, 17 Apr 1996 14:03:01 +0100 () Subject: multi-lobed inverse billboard like grand viewing Status: O Dear Performer Users, Is anyone familiar with methods to support coordination of a twining and pairing plane cleavage 3-view, (para-iso)metric scaling but with potential support for asymmetry in twining planes? Robust assurity of bi-quartic modal assemblability is not necessary, though simple 2nd order inverse gear rigid kinematics applications applied to panels of such a structured network would be preferred. (No, rapid animation of mushroom plumes is not the final intention [but injectors on ST lines might be an interesting non-affine demo].) Thanks for any pointers (esp. sinh quarternion blob-like), Michael G. Koopman, Comp. Sys. Specialist | CTC (Concurrent Technologies Corp.) | +1 814.269.2637 1450 Scalp Ave., Johnstown PA 15904 | facsimile x2666 -- P.S. no Grape Circle gimbals need reply, sans sharp retort in ordering. From guest Wed Apr 17 12:16:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA06495; Wed, 17 Apr 1996 12:10:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA06492; Wed, 17 Apr 1996 12:10:58 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA10289; Wed, 17 Apr 96 12:10:40 -0700 Received: from goggins.bath.ac.uk by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA12661; Wed, 17 Apr 1996 12:10:35 -0700 Received: from bath.ac.uk (actually host ss1.bath.ac.uk) by goggins.bath.ac.uk with SMTP (PP); Wed, 17 Apr 1996 18:16:11 +0100 Received: from gazza.bath.ac.uk by ss1.bath.ac.uk id ab24886; 17 Apr 96 18:16 BST Date: Wed, 17 Apr 1996 18:16:07 +0100 () From: Gazza To: "Michael T. Jones" Cc: Performer list Subject: Re: Performer 2.0 and 3DS file In-Reply-To: <9604170949.ZM9141@babar.asd.sgi.com> Message-Id: X-Sender: absgh@mail.bath.ac.uk Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Wed, 17 Apr 1996, Michael T. Jones wrote: > On Apr 17, 2:03pm, Gazza wrote: > > > Just got our new Max Impact with Performer 2.0. I'm completely new to > > Performer and I'm not a programmer (yet... that's the next step!). > > Anyway, I've noticed in this list archive of the last few months that > > other people have had the same problem loading 3DStudio files into perfly. > > > > What I haven't noticed, however, are any answers that are helpful to me, > > perhaps people have been answering via private email. Anyway, if anyone > > has any ideas as to how to get it working, I'd be more than pleased to > > find out, as we have a number of 3ds files that we want to view. > > IRIS Performer's 3DStudio loader uses the SGI ImageVision Library (IL) > to load the 3DS file's textures. Due to this, when we compiled the 3DS > loader, we specified that it needed the IL libraries (-lil -lcil) at > runtime. When people have problems with 3DS file, it seems that it's > due to that fact that they did not load the "il_eoe" subsystem from > their IRIX CD. Load this subsystem, and you should be fine. > > Michael Jones Michael. Just checked, and we definately have il_eoe loaded on the system. Not all of it, but the following: il_eoe.man.il il_eoe.man.relnotes il_eoe.sw.c++ il_eoe.sw.fit il_eoe.sw.gif il_eoe.sw.jfif il_eoe.sw.photocd il_eoe.sw.sgi il_eoe.sw.tiff I assume there is some other problem then? THe error message I get is as follows: smack:absgh:/usr/share/Performer/data>perfly crater.3ds PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "3ds" PF Info: All 1 processors available on this machine. PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "3ds" PF Warning: pfdLoadFile() - Unable to load file crater.3ds because of problem finding pfdLoadFile_3ds PF Notice: WARNING: could not load "crater.3ds" Now, I have checked, and there are certainly the following files on the machine: smack:absgh:/usr/share/Performer/data>find / -name "*3ds*" -mount -print /usr/lib/libpfdb/libpf3ds.so /usr/lib/libpfdb/libpf3ds_igl.so /usr/lib/libpfdb/libpf3ds_ogl.so /usr/lib/libpfdb/libpf3ds_igl.so.2 /usr/lib/libpfdb/libpf3ds_ogl.so.2 /usr/lib/Performer/Debug/libpfdb/libpf3ds_igl.so /usr/lib/Performer/Debug/libpfdb/libpf3ds_ogl.so /usr/lib/Performer/Debug/libpfdb/libpf3ds_igl.so.2 /usr/lib/Performer/Debug/libpfdb/libpf3ds_ogl.so.2 /usr/share/Performer/data/crater.3ds /usr/share/Performer/src/lib/libpfdb/libpf3ds /usr/share/Performer/src/lib/libpfdb/libpf3ds/3dsftk /usr/share/Performer/src/lib/libpfdb/libpf3ds/3dsftk/3dsftk.a /usr/share/Performer/src/lib/libpfdb/libpf3ds/libpf3ds /usr/share/Performer/src/lib/libpfdb/libpf3ds/libpf3ds/3dsftk.h /usr/share/Performer/src/lib/libpfdb/libpf3ds/libpf3ds/pf3ds.c Which have '3ds' somewhere in their name. So, anything else that has gone hideously wrong? THanks for any help Gary From guest Wed Apr 17 13:00:30 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA07008; Wed, 17 Apr 1996 12:54:52 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA07005; Wed, 17 Apr 1996 12:54:51 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA13204; Wed, 17 Apr 96 12:54:47 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA22412; Wed, 17 Apr 1996 12:54:47 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for id JAA07453; Wed, 17 Apr 1996 09:49:50 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA02803; Wed, 17 Apr 96 09:49:48 -0700 Received: by babar.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id JAA09143; Wed, 17 Apr 1996 09:49:47 -0700 From: "Michael T. Jones" Message-Id: <9604170949.ZM9141@babar.asd.sgi.com> Date: Wed, 17 Apr 1996 09:49:47 -0700 In-Reply-To: Gazza "Performer 2.0 and 3DS files" (Apr 17, 2:03pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Gazza , Performer list Subject: Re: Performer 2.0 and 3DS files Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 17, 2:03pm, Gazza wrote: > Subject: Performer 2.0 and 3DS files > Just got our new Max Impact with Performer 2.0. I'm completely new to > Performer and I'm not a programmer (yet... that's the next step!). > Anyway, I've noticed in this list archive of the last few months that > other people have had the same problem loading 3DStudio files into perfly. > > What I haven't noticed, however, are any answers that are helpful to me, > perhaps people have been answering via private email. Anyway, if anyone > has any ideas as to how to get it working, I'd be more than pleased to > find out, as we have a number of 3ds files that we want to view. IRIS Performer's 3DStudio loader uses the SGI ImageVision Library (IL) to load the 3DS file's textures. Due to this, when we compiled the 3DS loader, we specified that it needed the IL libraries (-lil -lcil) at runtime. When people have problems with 3DS file, it seems that it's due to that fact that they did not load the "il_eoe" subsystem from their IRIX CD. Load this subsystem, and you should be fine. Michael Jones From guest Wed Apr 17 13:13:16 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA07246; Wed, 17 Apr 1996 13:07:45 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA07243; Wed, 17 Apr 1996 13:07:44 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA14275; Wed, 17 Apr 96 13:07:40 -0700 Received: from gemtech.gemtech.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA24963; Wed, 17 Apr 1996 13:07:31 -0700 Received: from mac-server.gemtech.com by gemtech.gemtech.com via SMTP (950911.SGI.8.6.12.PATCH825/940406.SGI) id NAA25916; Wed, 17 Apr 1996 13:08:21 -0700 Message-Id: <199604172008.NAA25916@gemtech.gemtech.com> Date: 17 Apr 1996 13:18:52 -0800 From: "John Archdeacon" Subject: OpenGVS Cross Platform API To: "Performer News" Status: O REGARDING OpenGVS Cross Platform API 4/17/96 10:58 AM email from: john_archdeacon@gemtech.com Tel: 714.727.1980 Fax: 714.727.3066 Gemini Technology * Irvine, CA * USA * http://www.gemtech.com Howdy all... Luke Hoffman of COLSA recently wrote on the Performer news group: > How do we compare offerings from other vendors with SG equipment. > Another vendor offering a Vis/Sim solution will almost certainly use > OpenGL. OpenGL is fine, but it ain't Performer... Gemini has had a paper entitled "RealWorld Benchmarks for Workstation and PC Computer Image Generation Systems" accepted at the upcoming Image Society meeting in June (Arizona) which largely addresses this issue. Gemini has proposed a new benchmark system for computer image generation (CIG) application developers which will allow end users to compare the relative performance of 3-D graphics systems under identical "realworld" application and database workload (on or off SGI systems). The OpenGVS test suite environment makes this possible as it runs on top of OpenGL (like Performer does) as well as other low level rendering engines (e.g., Direct3D). The test suite as proposed will include a flight simulation stress test, a race car test, and a tank simulation environment test. The paper itself will shortly be published on the WEB at http://www.gemtech.com. Gemini has received favorable comments from some hardware manufacturers who are interested in officially endorsing the test suite. I have incorporate d good commments as well from SGI (Judith Pafford). The results of tests will be published in June or July on our WEB site. Don Tidrow at TAACOM wrote in reply to Luke: > Before Performer was widely available (1.2), we used Gemini > Technology's GVS software for all our image generation software needs. > They now have an OpenGL version that runs on other platforms > (PC's, ..., prob. any other OpenGL platform you want...). It had > basically everything Performer had... First, let me say that Performer is a great productivity product, and so is OpenGVS. As Don pointed out, OpenGVS is a computer image generation API with "basically everything Performer has" but unlike Performer, OpenGVS is intended (by design and focus) to be FULLY cross platform compatible at the end user application level while still delivering ALL of the underlying graphics hardware performance to the end user. OpenGVS is available for SGI IRIX 5.x and 6.x for any SGI system running with OpenGL (including the new InfiniteReality). OpenGVS is also available NOW for Windows 95, Windows NT, UNIX, and even DOS with 32-bit extenders for developers that aren't yet ready to make the leap to Windows. The largest difference between OpenGVS and Performer is the target hardware environment; we wrote GVS to be operating system AND graphics system independent. Don was right, OpenGVS supports virtually ANY OpenGL environment under Windows NT, Windows 95, IRIX, DEC-UNIX, HP-UNIX, and (in planning with a customer) Sun's Solaris. So, write your visual simulation application once and you're a recompile and relink away from running your CIG application and databases on different hardware systems (even the makefiles are fully portable across OS). Don probably didn't know this, but OpenGVS not only runs on top of OpenGL systems, but also with Microsoft Direct3D accelerators. When neither OpenGL or Direct3D are available from the hardware manufacturer, OpenGVS includes a hardware abstraction layer which we call SGL (subset OpenGL); this would include hardware accelerators from 3DFX, subsystems from Lockheed Martin Real3D (Pro 1000 series), and others. Generally, CIG applications written with OpenGVS run everywhere that the user would want. You can read more about OpenGVS at our web site: http://www.gemtech.com. Don further wrote: > My take on all this is that Sun and HP don't seem to be targeting the > top-end SGI's, instead they are targeting the mid-range (Impact) area. > The top-end SGI's really compete in the vis/sim arena with ESIG's and > other dedicated image generators... Gemini plans to continue supporting all of SGI's excellent graphics hardware (we've used 'em for years too!) including the new and very exciting InfiniteReality line. We do now support the HP-UX line now (in alpha test) and expect to be soon supporting the Solaris environment using OpenGL. We also support DEC-UNIX with OpenGL there as well (e.g., E&S Freedom series). From guest Wed Apr 17 14:21:33 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA07873; Wed, 17 Apr 1996 14:15:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA07870; Wed, 17 Apr 1996 14:15:34 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA18010; Wed, 17 Apr 96 14:15:29 -0700 Received: from ht.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA08800; Wed, 17 Apr 1996 14:15:22 -0700 Received: from [206.40.192.25] by ht.com (940816.SGI.8.6.9/3.1.090690-High Techsplanations) id RAA02323; Wed, 17 Apr 1996 17:09:29 -0400 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Apr 1996 16:20:37 -0400 To: info-performer@sgi.sgi.com From: dwight@ht.com (Dwight Meglan) Subject: using pfdSpatialize in libpfdu Status: O I wrote a little test program last night to try to break up a scenegraph into octrees using pfdSpatialize. Unfortunately, it only succeeds in being killed after running for a while. It is my guess that it is recursing too far and dying -- the source code for it (pfdSpatialize that is) shows that the implementation is recursive. My next step is to add debug statements to the source for pfdSpatialize and watch it do its magic -- I just linked to libpfdu.so for my quick test last night. Before I go and figure out how to do this: Has anyone used pfdSpatialize and could you point out what I am doing wrong in the following code snippet ? --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- #include #include #include #include #include #include #include int main (int argc, char *argv[]) { pfInit(); pfMultiprocess(PFMP_APPCULLDRAW); pfdInitConverter(argv[1]); pfConfig(); pfNotifyLevel(PFNFY_FATAL | PFNFY_DEBUG); pfScene *scene = new pfScene(); scene->addChild(pfdLoadFile(argv[1])); int ndiv= 100; if (argc > 3) ndiv= atoi(argv[3]); int ngset= 2; if (argc > 4) ngset= atoi(argv[4]); pfSphere bsphere; scene->getBound(&bsphere); float tol= bsphere.radius/ndiv; fprintf(stderr,"Spatializing with max Geode size of %f and max numGeosets/Geode of %d into %s\n", tol,ngset,argv[2]); pfGroup* newScene= pfdSpatialize((pfGroup*)scene,tol,ngset); pfdStoreFile(newScene,argv[2]); pfExit(); return 0; } --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- --snip-- I have tried the above with many permutations including the following which should generate a minimal octree: breakup biggeoset.iv lotsogeosets.iv 2 10 I still get the process being killed -- usually by all the swap space being consumed which makes me suspect that pfdSpatialize is recursing to oblivion. Thanks in advance for advice on this, --dwight ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dwight Meglan, PhD | Developers of complete surgery simulation Engineering Coordinator | training systems and surgery simulation High Techsplanations, Inc. | creation software tools 6001 Montrose Rd., Suite 902 | Rockville, MD 20852-4874 | "Witty, yet erudite saying goes here..." 301 984 3706 x38 | 301 984 2104 : FAX | dwight@ht.com | http://www.ht.com From guest Wed Apr 17 12:56:13 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA06939; Wed, 17 Apr 1996 12:50:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA06936; Wed, 17 Apr 1996 12:50:14 -0700 Received: from deliverator.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA12888; Wed, 17 Apr 96 12:50:09 -0700 Received: from ht.com by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id MAA14845; Wed, 17 Apr 1996 12:50:08 -0700 Received: from [206.40.192.25] by ht.com (940816.SGI.8.6.9/3.1.090690-High Techsplanations) id PAA01867; Wed, 17 Apr 1996 15:43:00 -0400 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Apr 1996 14:54:04 -0400 To: info-performer@sgi.com From: dwight@ht.com (Dwight Meglan) Subject: fast isect when inside geometry Status: O I would like to get comment on the best way to quickly do intersection testing for moving about inside of a large chunk of geometry. By large I mean around 50,000 polygons. By moving around I mean that I want to steer the camera about at 15-30 Hz (preferably on an Impact but I can fallback to an Onyx) and be constrained to within the boundaries of the geometry. Originally the geometry was a couple of giant geosets. We have the tools at hand to slice and dice them-- Alias as well as Designer's Workbench. My first inclination is to break the data up into hierarchically arranged zones like octrees but since I know the geometry (which is not equally distributed in space) I can manually, though laborously, group it more efficiently than that. There are passageways between sections of the geometry also but the geometry is not planar so the pfPortals package won't help me here. We'll probably try using fog to move the far clip in and limit extra drawing. My reasoning for this arrangement is that if I understand properly how Performer's intersect routines for a pfSegSet work, then I will quickly find the geoset(s) that are candidates for an intersection by Performer doing bounding volume checks hierarchically (I will have nested groups). Once the few small bounding volumes down at the bottom of the hierarchy are found polygon intersection checks will be done to find the actual contact point(s). I am assuming that this is the fastest possible way to do intersects for this situation because: 1. Checking bounding volumes is much faster than polygons -- Performer does as much bounding volumes as it can before dropping to polygon checks. 2. Performer is automatically smart about working its way down through a hierarchy of bounding volumes -- look at the top level hierarchy bounding volume, if a segment touches it check its children's bounding volumes and continue on only those that touch the segment then check their children's bounding volumes, etc. until a list of the geoset bounding volumes touching the segment is constructed. 3. Performer will not do polygon intersections until the list of bounding volume geosets has been selected in a "first pass" by Performer. I am curious what the tradeoff between nesting and number of polygons in a geoset should be... should I shoot for 10 polygons in a geoset ? 5? 20? 50? Will drawing speed become more of a limiting factor than intersections at some point because of inefficient tristrips ? The final complication is that my camera actual has a long cord behind it (think of snaking a cable through an irregular maze) which must be continuously checked against the geometry for intersections. This means that there are a number of segments that must be check. The question here is: Is it better, in terms of intersection calculation efficiency, for the above geometry to check: 1. one pfSegSet with all the segments for all the joints of the cord in it against the entire scenegraph 2. check each segment individually with its own pfSegSet against the entire scenegraph 3. use on pfSegSet with all the segments but mask it for each segment a check once for each segment against the scenegraph I don't want to write code to do frame-to-frame coherence yet-- that comes later if I find that the straight forward approach of ignoring the previous frame's results is too slow. Thanks in advance for advice on this. BTW, I did a large collision implementation under Performer a couple months back and ended up doing my own isects because I could use a segment to cylinder intersect for that situation. It was probably 10x faster than the Performer polygon-based isect. But I cannot do such tricks this time-- the geometry is too irregular. --dwight ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dwight Meglan, PhD | Developers of complete surgery simulation Engineering Coordinator | training systems and surgery simulation High Techsplanations, Inc. | creation software tools 6001 Montrose Rd., Suite 902 | Rockville, MD 20852-4874 | "Witty, yet erudite saying goes here..." 301 984 3706 x38 | 301 984 2104 : FAX | dwight@ht.com | http://www.ht.com From guest Wed Apr 17 15:18:19 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA08265; Wed, 17 Apr 1996 15:08:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA08262; Wed, 17 Apr 1996 15:08:17 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA21151; Wed, 17 Apr 96 15:08:10 -0700 Received: from jeeves.icemt.iastate.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA17539; Wed, 17 Apr 1996 15:05:35 -0700 Received: from helser75.res.iastate.edu (helser75.res.iastate.edu [129.186.76.75]) by jeeves.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) with SMTP id RAA27861 for ; Wed, 17 Apr 1996 17:05:24 -0500 Received: by helser75.res.iastate.edu with Microsoft Mail id <01BB2C80.07A7E3E0@helser75.res.iastate.edu>; Wed, 17 Apr 1996 17:05:07 -0500 Message-Id: <01BB2C80.07A7E3E0@helser75.res.iastate.edu> From: Allen Bierbaum To: "'Performer List'" Subject: Inventor DSO loaders for n32 or 64 Date: Wed, 17 Apr 1996 17:05:02 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: O Are there Performer loaders for inventor when running n32 or 64 bit code??? I looked in the library directories, and could find none. Are they supposed to be there?? -Allen allenb@iastate.edu ISU CAVE RA - Carolina Cruz-Neira From guest Wed Apr 17 18:55:35 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA09511; Wed, 17 Apr 1996 18:49:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA09508; Wed, 17 Apr 1996 18:49:11 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA03811; Wed, 17 Apr 96 18:49:00 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id SAA17575; Wed, 17 Apr 1996 18:49:09 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA03806; Wed, 17 Apr 96 18:48:57 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id SAA25694; Wed, 17 Apr 1996 18:48:55 -0700 Message-Id: <199604180148.SAA25694@surreal.asd.sgi.com> To: Allen Bierbaum Cc: "'Performer List'" , vince@surreal.asd.sgi.com Subject: Re: Tele source In-Reply-To: Your message of "Tue, 16 Apr 96 18:50:30 CDT." <01BB2BC5.9EA22A00@helser75.res.iastate.edu> Date: Wed, 17 Apr 96 18:48:54 -0700 From: Jim Helman Status: O > Who do I contact to get this source???? Try: ftp://sgigate.sgi.com/pub/Performer/src/pf1.2/tele-jan95.tar.Z This version has not been ported to Performer 2.0, so it doesn't use any of the built in video texturing capabilities in 2.0, but it may still be useful for ideas. rgds, -jim helman jimh@surreal.asd.sgi.com IRIS Performer/Cosmo3D Java Library 415/933-1151 From guest Wed Apr 17 18:51:41 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA09506; Wed, 17 Apr 1996 18:45:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA09503; Wed, 17 Apr 1996 18:45:47 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA03682; Wed, 17 Apr 96 18:45:36 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id SAA17311; Wed, 17 Apr 1996 18:45:44 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA03671; Wed, 17 Apr 96 18:45:33 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id SAA25685; Wed, 17 Apr 1996 18:45:31 -0700 Message-Id: <199604180145.SAA25685@surreal.asd.sgi.com> To: "Thomas M. Miller" Cc: info-performer@sgi.sgi.com Subject: Re: Inheritance off pfObjects. In-Reply-To: Your message of "Mon, 15 Apr 96 15:31:32 EDT." Date: Wed, 17 Apr 96 18:45:30 -0700 From: Jim Helman Status: O 1) Subclassing should work as expected single processed, i.e. APPCULLDRAW. 2) Always use pfDelete() on Performer objects derived from pfObject. 3) If you multiprocess, things get more complicated. Your subclassed object will only exist in the APP process. The corresponding object in the CULL and DRAW processes will still be the native Performer class. If you haven't already, read the C++ chapter in the programming guide. rgds, -jim helman jimh@surreal.asd.sgi.com IRIS Performer/Cosmo3D Java Library 415/933-1151 From guest Thu Apr 18 03:01:40 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA11524; Thu, 18 Apr 1996 02:56:08 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA11521; Thu, 18 Apr 1996 02:56:07 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA14083; Thu, 18 Apr 96 02:55:46 -0700 Received: from vsl-fw.vsl.co.jp by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA22147; Thu, 18 Apr 1996 02:56:00 -0700 Received: from athens.vsl.co.jp (athens.vsl.co.jp [172.20.100.1]) by vsl-fw.vsl.co.jp (8.7.5/3.4W2MX) with SMTP id SAA20151 for ; Thu, 18 Apr 1996 18:55:56 +0900 (JST) Received: from easter by athens.vsl.co.jp (5.65/3.3W9-uucp) id AA20149; Thu, 18 Apr 1996 18:55:56 +0900 Message-Id: <9604180954.AA00120@rydeen.vsl.co.jp> Date: Thu, 18 Apr 1996 18:54:51 +0900 From: Takayuki Kondo To: info-performer@sgi.sgi.com Subject: Subscribe X-Mailer: AL-Mail 1.12 Status: O From guest Thu Apr 18 06:31:11 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA11757; Thu, 18 Apr 1996 06:25:28 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA11754; Thu, 18 Apr 1996 06:25:27 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA17153; Thu, 18 Apr 96 06:24:55 -0700 Received: from nvl.client by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA07575; Thu, 18 Apr 1996 06:25:23 -0700 Received: by nvl.client (Smail3.1.28.1 #5) id m0u9ti4-0001u2C; Thu, 18 Apr 96 09:25 EDT Message-Id: From: lu@nvl.army.mil (Young Lu) Subject: search for docs To: info-performer@sgi.sgi.com (PF2.0) Date: Thu, 18 Apr 96 9:25:19 EDT X-Mailer: ELM [version 2.3 PL11] Status: O Hi, can someone be so kind to point to site where I can download Performer 2.0 manuals ? Thanks. -- Young T. Lu lu@nvl.army.mil From guest Thu Apr 18 06:53:01 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA11776; Thu, 18 Apr 1996 06:47:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA11773; Thu, 18 Apr 1996 06:47:30 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA17521; Thu, 18 Apr 96 06:46:56 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA09931; Thu, 18 Apr 1996 06:47:26 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA16727; Thu, 18 Apr 1996 09:37:45 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id JAA28228; Thu, 18 Apr 1996 09:36:41 -0400 From: "Bernard Leclerc" Message-Id: <9604180936.ZM28226@eagle.cae.ca> Date: Thu, 18 Apr 1996 09:36:36 -0400 In-Reply-To: "Thomas M. Miller" "Inheritance off pfObjects." (Apr 15, 3:31pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Thomas M. Miller" , info-performer@sgi.sgi.com Subject: Re: Inheritance off pfObjects. Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19604180936.ZM28226.cae.ca" Status: O -- --PART-BOUNDARY=.19604180936.ZM28226.cae.ca Content-Type: text/plain; charset=us-ascii On Apr 15, 3:31pm, Thomas M. Miller wrote: > Are there problems with inheritance off performer objects? No. The Performer Programmer's Guide, chapter 14 explains how it should be done. > For example if I was to implement a class in the following manner would > it cause any problems? > > class DCS_ListElm : public pfDCS > { > public: > DCS_ListElm *next, *prev; > > DCS_ListElm( void ) : pfDCS() > { > next = prev = NULL; > } > > ~DCS_ListElm( void ) > { > if( next ) > next->prev = prev; > if( prev ) > prev->next = next; > } > }; > > Please forgive the crudness of my example class. > > Would there be mal effects upon the deletion of an object of this class? > > In what manner should an object of this class be delete anyway, > using the delete operator or pfDelete? > I've attached a modified version of simple.C illustrating how a derived DCS could be implemented. See by yourself... Bernard. -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 --PART-BOUNDARY=.19604180936.ZM28226.cae.ca X-Zm-Content-Name: newAppDCS.C Content-Description: Text Content-Type: text/plain ; name="newAppDCS.C" ; charset=us-ascii // // Copyright 1995, Silicon Graphics, Inc. // ALL RIGHTS RESERVED // // UNPUBLISHED -- Rights reserved under the copyright laws of the United // States. Use of a copyright notice is precautionary only and does not // imply publication or disclosure. // // U.S. GOVERNMENT RESTRICTED RIGHTS LEGEND: // Use, duplication or disclosure by the Government is subject to restrictions // as set forth in FAR 52.227.19(c)(2) or subparagraph (c)(1)(ii) of the Rights // in Technical Data and Computer Software clause at DFARS 252.227-7013 and/or // in similar or successor clauses in the FAR, or the DOD or NASA FAR // Supplement. Contractor/manufacturer is Silicon Graphics, Inc., // 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311. // // Permission to use, copy, modify, distribute, and sell this software // and its documentation for any purpose is hereby granted without // fee, provided that (i) the above copyright notices and this // permission notice appear in all copies of the software and related // documentation, and (ii) the name of Silicon Graphics may not be // used in any advertising or publicity relating to the software // without the specific, prior written permission of Silicon Graphics. // // THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, // EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY // WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. // // IN NO EVENT SHALL SILICON GRAPHICS BE LIABLE FOR ANY SPECIAL, // INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY // DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, // WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY // THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE // OR PERFORMANCE OF THIS SOFTWARE. // // // simpleC.C: simple Performer program for programmer's guide // // $Revision: 1.10 $ // $Date: 1995/11/22 14:35:21 $ // #include #include #include #include #include #include #include #include #include #include // application specific class derived from a Performer DCS node. // // The virtual function app() simply counts the number of time // the function is called. class appDCS : public pfDCS { public: int count; appDCS() {count = 0;} virtual int app(pfTraverser* trav) { count++; return pfDCS::app(trav); } virtual int needsApp() { return TRUE; } static void init(); static pfType* getClassType() { return classType; } private: static pfType* classType; }; pfType *appDCS::classType = NULL; void appDCS::init() { if (classType == NULL) { pfDCS::init(); classType = new pfType ( pfDCS::getClassType(), "appDCS"); } } // // Usage() -- print usage advice and exit. This // procedure is executed in the application process. // static void Usage (void) { pfNotify(PFNFY_FATAL, PFNFY_USAGE, "Usage: simpleC file.ext ...\n"); exit(1); } // // Application Callback used by channel groups // static void AppCallback( pfChannel *, void * ) { pfApp(); } // // Main program // int main (int argc, char *argv[]) { float t = 0.0f; if (argc < 2) Usage(); // Initialize Performer pfInit(); // Initialize derived classes appDCS::init(); // Use default multiprocessing mode based on number of // processors. // pfMultiprocess( PFMP_DEFAULT ); // Load all loader DSO's before pfConfig() forks pfdInitConverter(argv[1]); // initiate multi-processing mode set in pfMultiprocess call // FORKs for Performer processes, CULL and DRAW, etc. happen here. // pfConfig(); // Append to Performer search path, PFPATH, files in // /usr/share/Performer/data */ pfFilePath(".:/usr/share/Performer/data"); pfNode *root = pfdLoadFile(argv[1]); if (root == NULL) { pfExit(); exit(-1); } // Attach the loaded file to a new appDCS appDCS* dcs = new appDCS; dcs->addChild(root); // Attach the appDCS to a new pfScene pfScene *scene = new pfScene; scene->addChild(dcs); // Create a pfLightSource and attach it to scene scene->addChild(new pfLightSource); // Configure and open GL window pfPipe *p = pfGetPipe(0); pfPipeWindow *pw = new pfPipeWindow(p); pw->setWinType(PFPWIN_TYPE_X); pw->setName("IRIS Performer"); pw->setOriginSize(0,0,640,480); pw->open(); // Create and configure 2 channels. pfChannel *chan1 = new pfChannel(p); pfChannel *chan2 = new pfChannel(p); chan1->attach(chan2); chan1->setScene(scene); chan1->setFOV(45.0f, 0.0f); chan2->setViewport(0.333333f,0.666666f,0.7f,0.9f); chan1->setTravFunc( PFTRAV_APP, AppCallback ); // determine extent of scene's geometry pfSphere bsphere; root->getBound(&bsphere); chan1->setNearFar(1.0f, 10.0f * bsphere.radius); // Simulate for twenty seconds. int frames; while (t < 20.0f) { pfCoord view; float s, c; // Go to sleep until next frame time. pfSync(); // Initiate cull/draw for this frame. frames = pfFrame(); // Compute new view position. t = pfGetTime(); pfSinCos(45.0f*t, &s, &c); view.hpr.set(45.0f*t, -10.0f, 0); view.xyz.set(2.0f * bsphere.radius * s, -2.0f * bsphere.radius *c, 0.5f * bsphere.radius); chan1->setView(view.xyz, view.hpr); } printf("num frames: %d\n", frames); printf("appDCS count: %d\n", dcs->count); // Terminate parallel processes and exit pfExit(); return 0; } --PART-BOUNDARY=.19604180936.ZM28226.cae.ca-- From guest Thu Apr 18 07:07:20 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA11819; Thu, 18 Apr 1996 07:01:53 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA11816; Thu, 18 Apr 1996 07:01:52 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA17812; Thu, 18 Apr 96 07:01:17 -0700 Received: from mail.eecs.uic.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA11342; Thu, 18 Apr 1996 07:01:49 -0700 Received: from marvin.eecs.uic.edu (marvin.eecs.uic.edu [128.248.214.126]) by mail.eecs.uic.edu (8.6.11/8.6.10) with SMTP id JAA03234; Thu, 18 Apr 1996 09:02:29 -0500 Sender: rsteven@eecs.uic.edu Message-Id: <31764B79.794B@eecs.uic.edu> Date: Thu, 18 Apr 1996 09:02:33 -0500 From: Rob Stevenson X-Mailer: Mozilla 3.0b2 (X11; I; IRIX 5.3 IP22) Mime-Version: 1.0 To: Young Lu Cc: "PF2.0" Subject: Re: search for docs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O The Performer 2.0 manuals are located at: http://www.sgi.com/Technology/TechPubs/ On the same note, does anyone know how much it costs to buy the manuals from SGI? Thanks! -Rob Stevenson rstevens@eecs.uic.edu From guest Thu Apr 18 07:32:35 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA11972; Thu, 18 Apr 1996 07:27:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA11965; Thu, 18 Apr 1996 07:27:09 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA18310; Thu, 18 Apr 96 07:26:33 -0700 Received: from mail.eecs.uic.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA14250; Thu, 18 Apr 1996 07:27:05 -0700 Received: from marvin.eecs.uic.edu (marvin.eecs.uic.edu [128.248.214.126]) by mail.eecs.uic.edu (8.6.11/8.6.10) with SMTP id JAA03814 for ; Thu, 18 Apr 1996 09:27:48 -0500 Sender: rsteven@eecs.uic.edu Message-Id: <31765168.59E2@eecs.uic.edu> Date: Thu, 18 Apr 1996 09:27:52 -0500 From: Rob Stevenson X-Mailer: Mozilla 3.0b2 (X11; I; IRIX 5.3 IP22) Mime-Version: 1.0 To: info-performer Subject: Cost of Performer2.0 Manuals.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O I went to the URL that I sent out and they now have the price listed( which I don't remember seeing when this site was created). Anyhoo, the price of the Performer 2.0 Manual Kit (Programming Guide, C Ref. Pages, C++ Ref. Pages) is $230!!! Too rich for my student budget. Thanks to SGI for the .ps version though! -Rob Stevenson rstevens@eecs.uic.edu From guest Thu Apr 18 07:35:04 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA11981; Thu, 18 Apr 1996 07:29:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA11978; Thu, 18 Apr 1996 07:29:36 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA18377; Thu, 18 Apr 96 07:29:00 -0700 Received: from macgyver.detroit.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA14496; Thu, 18 Apr 1996 07:29:32 -0700 Received: by macgyver.detroit.sgi.com (940816.SGI.8.6.9/940406.SGI) id KAA09189; Thu, 18 Apr 1996 10:08:51 -0400 From: "ted jordan" Message-Id: <9604181008.ZM9187@macgyver.detroit.sgi.com> Date: Thu, 18 Apr 1996 10:08:50 -0400 In-Reply-To: lu@nvl.army.mil (Young Lu) "search for docs" (Apr 18, 9:25am) References: X-Face: j;kCV?eS+]ChRWl;VY/JLQw'A6B/%I(w,LT|3G9"H+!pjDW>%3s#S|I\}Fbs;ZH_d]GTE26H"ZAW_;)h6J,&\kX/%fmo'O?lmwvZ<9vaKm=(TuGBlm0/w-a~E/iwtvSGJw3/7g|IaG9D0npq,l>vkt:zK:rm,u%>O%aw=0&]@HgHWG[K=MO3 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: lu@nvl.army.mil (Young Lu), info-performer@sgi.sgi.com (PF2.0) Subject: Re: search for docs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O see http://www.sgi.com/Technology/TechPubs/ check out http://www.sgi.com/Technology/TechPubs/lib/makepage.cgi?007-1680-030 ted On Apr 18, 9:25am, Young Lu wrote: > Subject: search for docs > Hi, can someone be so kind to point to site where I can download Performer > 2.0 manuals ? Thanks. > > -- > Young T. Lu lu@nvl.army.mil > > >-- End of excerpt from Young Lu -- theodore p jordan silicon graphics, inc detroit, michigan tjordan@detroit.sgi.com http://reality.sgi.com/employees/tjordan_detroit "Tact is the art of making a point without making an enemy" Monthly Spelling Aid: tried - past tense of try; tryed - not a word From guest Thu Apr 18 07:49:34 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA12132; Thu, 18 Apr 1996 07:43:49 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA12129; Thu, 18 Apr 1996 07:43:48 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA18726; Thu, 18 Apr 96 07:43:12 -0700 Received: from alexandra.mtl.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA16191; Thu, 18 Apr 1996 07:43:44 -0700 Received: from max (max.mtl.com [192.148.246.59]) by alexandra.mtl.com (8.7.5/8.7.3) with SMTP id KAA11530; Thu, 18 Apr 1996 10:44:17 -0400 (EDT) Received: by max (940816.SGI.8.6.9/Spike-2.0) id KAA01821; Sat, 20 Apr 1996 10:42:35 -0400 From: "John Collier" Message-Id: <9604201042.ZM1819@max.mtl.com> Date: Sat, 20 Apr 1996 10:42:35 -0400 In-Reply-To: Rob Stevenson "Re: search for docs" (Apr 18, 9:02am) References: <31764B79.794B@eecs.uic.edu> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Rob Stevenson Subject: Re: search for docs Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I called my rep and they said they are about $250.00 That seems a little steep. John From guest Thu Apr 18 08:53:45 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA12557; Thu, 18 Apr 1996 08:47:43 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA12554; Thu, 18 Apr 1996 08:47:42 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA20925; Thu, 18 Apr 96 08:47:02 -0700 Received: from nvl.client by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA24570; Thu, 18 Apr 1996 08:47:40 -0700 Received: by nvl.client (Smail3.1.28.1 #5) id m0u9vvk-0001u2C; Thu, 18 Apr 96 11:47 EDT Message-Id: From: lu@nvl.army.mil (Young Lu) Subject: tapping on `make' experts... To: info-performer@sgi.sgi.com (PF2.0) Date: Thu, 18 Apr 96 11:47:32 EDT X-Mailer: ELM [version 2.3 PL11] Status: O Hi there, What do I need to do if a `make' does not pick up the changes in any of its files once it was compiled once ? In another word, if I modify my one of the files and compile with `make', it simply ignores the changes and declares that the executable is up-to-date, thus no need for compiling. I wonder if any environmental variable need some attention here. I appreciate any help. Thanks. -- Young T. Lu lu@nvl.army.mil From guest Thu Apr 18 09:00:25 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA12565; Thu, 18 Apr 1996 08:54:53 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA12562; Thu, 18 Apr 1996 08:54:53 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA21204; Thu, 18 Apr 96 08:54:13 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA25589; Thu, 18 Apr 1996 08:54:49 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA21194; Thu, 18 Apr 96 08:54:08 -0700 Received: by babar.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id IAA02901; Thu, 18 Apr 1996 08:54:46 -0700 From: "Michael T. Jones" Message-Id: <9604180854.ZM2899@babar.asd.sgi.com> Date: Thu, 18 Apr 1996 08:54:46 -0700 In-Reply-To: Rob Stevenson "Cost of Performer2.0 Manuals.." (Apr 18, 9:27am) References: <31765168.59E2@eecs.uic.edu> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Rob Stevenson , info-performer Subject: Re: Cost of Performer2.0 Manuals.. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 18, 9:27am, Rob Stevenson wrote: > Subject: Cost of Performer2.0 Manuals.. > I went to the URL that I sent out and they now have the price listed( > which I don't remember seeing when this site was created). Anyhoo, the > price of the Performer 2.0 Manual Kit (Programming Guide, C Ref. Pages, > C++ Ref. Pages) is $230!!! Too rich for my student budget. Thanks to SGI > for the .ps version though! As far as wholesale .vs retail price markups go, the Performer manuals are at an amazingly low price: 2100 pages of documentation in three volumes, professionally printed, bound in nice "Stay-Flat" bindings rather than el-cheapo wire or plastic rings, pretty pictures, and similar factors make our cost very close to that of the sale price. (In fact, if you accounted for the factory's overhead in handling shipments, postage, etc., we probably loose money on each set that we sell. Maybe if the old-guard image generator companies figure this out, they'll order thousands of copies of the books and drive SGI out of business ;-) That notwithstanding the value of the books and the economy of their pricing, they are clearly not inexpensive. We wanted everyone to have access to the documentation, so that is why all of it is available on-line and via the web. Michael "Tired-fingers-from-typing-manpages" Jones From guest Thu Apr 18 10:23:46 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA12915; Thu, 18 Apr 1996 10:17:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA12912; Thu, 18 Apr 1996 10:17:58 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA25613; Thu, 18 Apr 96 10:17:13 -0700 Received: from artemis.rus.uni-stuttgart.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA10790; Thu, 18 Apr 1996 10:17:39 -0700 Received: from awssg6.rus.uni-stuttgart.de (awssg6-fd.rus.uni-stuttgart.de [129.69.18.56]) by artemis.rus.uni-stuttgart.de with ESMTP id TAA03623 (8.6.13/IDA-1.6); Thu, 18 Apr 1996 19:17:29 +0200 Received: by awssg6.rus.uni-stuttgart.de (950911.SGI.8.6.12.PATCH825/930416.SGI/BelWue-1.1) id TAA14501; Thu, 18 Apr 1996 19:16:40 +0200 From: "Daniela Rainer (Hiwi U. Lang)" Message-Id: <9604181916.ZM14499@awssg6.rus.uni-stuttgart.de> Date: Thu, 18 Apr 1996 19:16:39 +0000 In-Reply-To: fred@virtual.me.uic.edu (Fred Dech) "pfiInputXform question." (Apr 16, 1:17pm) References: <199604161817.NAA28219@virtual.me.uic.edu> Reply-To: rainer@RUS.Uni-Stuttgart.DE X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: fred@virtual.me.uic.edu (Fred Dech) Subject: Re: pfiInputXform question. Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Fred, I had the same problem with pfiXformerMat. It never sets the matrix of the xformer. I think pfiXformerMat calls pfiInputXformTrackball::setMat(). Regards Daniela -- Daniela Rainer rainer@rus.uni-stuttgart.de From guest Thu Apr 18 10:32:05 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA12936; Thu, 18 Apr 1996 10:26:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA12933; Thu, 18 Apr 1996 10:26:38 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA26194; Thu, 18 Apr 96 10:25:52 -0700 Received: from jeeves.icemt.iastate.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA12289; Thu, 18 Apr 1996 10:26:28 -0700 Received: from kahuna.icemt.iastate.edu (kahuna.icemt.iastate.edu [129.186.232.36]) by jeeves.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) with ESMTP id MAA10424 for ; Thu, 18 Apr 1996 12:26:27 -0500 Received: (from allenb@localhost) by kahuna.icemt.iastate.edu (950413.SGI.8.6.12/8.6.12) id MAA01471 for info-performer@sgi.sgi.com; Thu, 18 Apr 1996 12:26:27 -0500 From: " Allen Bierbaum" Message-Id: <9604181226.ZM1469@kahuna.icemt.iastate.edu> Date: Thu, 18 Apr 1996 12:26:27 -0500 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Inventor Loaders Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O When I complie a Performer 2.0 app as N32, I get the following error.... PF Debug: pfdFindConverterDSO() - DSO search path is: PF ".:" PF ":" PF ":" PF "/usr/lib32/libpfdb:" PF "/usr/share/Performer/lib/libpfdb" PF Debug: pfdFindConverterDSO() - version of libpfdu.so is sgi2.0 PF Debug: pfdFindConverterDSO() - Did not find optimized DSO "libpfiv20.so" PF Debug: pfdFindConverterDSO() - Did not find debug DSO "libpfiv20-g.so" PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "iv20" PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "iv" I then looked in /usr/lib32/libpfdb and I could not find the inventor loader either. I also looked in all the libpfdb directories under lib32 and lib64. I could not find an inventor loader in any of these directories although all the other loaders seemed to be there. My program works fine when loading obj, lsa, and flt, but not iv. Do these loaders exist, but I just can't find them??? Second: Has anyone been able to compile the libpfiv1.1 code. Whenever I try to compile 32 bit, I get the following error. This is with no changes to the makefile. ld: WARNING 84: /usr/lib64/libInventor.so is not used for resolving any symbol. ld: FATAL 12: Expecting 64-bit objects: pfstoreiv.o is o32. *** Error code 1 If I change it to try to compile for N32 or 64 bit code, I get errors from the compiler. I am wondering if anyone has gotten these to compile either. Thanks, Allen Bierbaum allenb@iastate.edu ISU CAVE RA - Carolina Cruz-Neira -- Allen Bierbaum From guest Thu Apr 18 10:36:22 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA12959; Thu, 18 Apr 1996 10:30:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA12956; Thu, 18 Apr 1996 10:30:35 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA26393; Thu, 18 Apr 96 10:29:50 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA12948; Thu, 18 Apr 1996 10:30:31 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA07898; Thu, 18 Apr 1996 13:21:22 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id NAA28709; Thu, 18 Apr 1996 13:20:00 -0400 From: "Bernard Leclerc" Message-Id: <9604181319.ZM28707@eagle.cae.ca> Date: Thu, 18 Apr 1996 13:19:55 -0400 In-Reply-To: lu@bongo.nvl.army.mil (Young Lu) "tapping on `make' experts..." (Apr 18, 11:47am) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: lu@bongo.nvl.army.mil (Young Lu), info-performer@sgi.sgi.com (PF2.0) Subject: Re: tapping on `make' experts... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19604181319.ZM28707.cae.ca" Status: O -- --PART-BOUNDARY=.19604181319.ZM28707.cae.ca Content-Type: text/plain; charset=us-ascii On Apr 18, 11:47am, Young Lu wrote: > What do I need to do if a `make' does not pick up the changes in any of its > files once it was compiled once ? In another word, if I modify my one of the > files and compile with `make', it simply ignores the changes and declares > that the executable is up-to-date, thus no need for compiling. > > I wonder if any environmental variable need some attention here. Young, Makefiles are no magic. Take the time to read the man page on pmake (which I prefer over the standard make) as well as the system default make rules in /usr/include/make/system.mk. You'll learn a lot from them. However I do not suggest to learn Makefiles by reading the Performer 2.0 Makefile. It's too complicated. As an example, attached is a simple makefile I use to compile Performer 2.0 test programs such as simple.C, shadows.C, etc. Note that this Makefile is for C++ program, I'll leave it to you to adapt it for C program. Good luck... P.S. To compile simple.C with this Makefile, simply type "make simple" Isn't it simple? ;) -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 --PART-BOUNDARY=.19604181319.ZM28707.cae.ca X-Zm-Content-Name: Makefile Content-Description: Text Content-Type: text/plain ; name="Makefile" ; charset=us-ascii #!pmake C++FLAGS = -DIRISGL -g +w +pp -mips2 -MDupdate Makedepend -woff 3259 LDFLAGS = -lpfdu_igl -lpfutil_igl -lpf_igl -limage -lgl -lm -lfpe -lfm -lmalloc sinclude Makedepend --PART-BOUNDARY=.19604181319.ZM28707.cae.ca-- From guest Thu Apr 18 10:36:23 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA12964; Thu, 18 Apr 1996 10:30:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA12961; Thu, 18 Apr 1996 10:30:50 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA26410; Thu, 18 Apr 96 10:30:04 -0700 Received: from evl.eecs.uic.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA12990; Thu, 18 Apr 1996 10:30:46 -0700 Received: from zbox.eecs.uic.edu by evl.eecs.uic.edu via ESMTP (950215.SGI.8.6.10/940406.SGI.AUTO) for id MAA17854; Thu, 18 Apr 1996 12:30:45 -0500 Received: (swami@localhost) by zbox.eecs.uic.edu (8.6.12/8.6.4) id RAA23745; Thu, 18 Apr 1996 17:30:44 GMT Date: Thu, 18 Apr 1996 12:30:44 -0500 (CDT) From: Swaminathan To: info-performer@sgi.sgi.com Subject: Re: Cost of Performer2.0 Manuals.. In-Reply-To: <9604180854.ZM2899@babar.asd.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O This is definitely not a flame, but I noticed a conspicuous absence of OpenInventor and OpenGL manuals in postscript form. Perhaps they are so "Open", the royalty accruing from selling the manuals cannot be ignored? Swami <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< v Swaminathan Narayanan ^ v swami@evl.eecs.uic.edu ^ v Office: 996-3002 ^ v Home: 850-3725 ^ v Fax: 413-0447 ^ v http://www.eecs.uic.edu/~snarayan ^ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From guest Thu Apr 18 11:20:48 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA13317; Thu, 18 Apr 1996 11:05:52 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA13314; Thu, 18 Apr 1996 11:05:51 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA28559; Thu, 18 Apr 96 11:05:04 -0700 Received: from listserv.gmd.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA19519; Thu, 18 Apr 1996 11:05:38 -0700 Received: from mailer.mpib-tuebingen.mpg.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <1.DCBD2481@listserv.gmd.de>; Thu, 18 Apr 1996 20:05:32 +0200 Received: from bogart.mpib-tuebingen.mpg.de by mailer.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0912AM) id AA03665; Thu, 18 Apr 1996 18:50:50 +0100 Received: from squash.mpik-tueb.mpg.de by bogart.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0442PM) id AA04086; Thu, 18 Apr 1996 19:13:36 +0100 Received: by squash (940816.SGI.8.6.9/940406.SGI) id TAA20359; Thu, 18 Apr 1996 19:12:46 +0200 From: "Dietrich Opitz" Message-Id: <9604181912.ZM20357@squash.mpik-tueb.mpg.de> Date: Thu, 18 Apr 1996 19:12:44 +0000 In-Reply-To: lu@bongo.nvl.army.mil (Young Lu) "tapping on `make' experts..." (Apr 18, 11:47am) References: X-Face: ,78BGR^:N$.'76:g~S1U^5[;4H@V1KZvxT0W&ugiSX!CO}A((fKEnL2;vdw~RdA'C}Snv2n/1pB3cZjiFbN{Q}nXx}2cd* X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: lu@bongo.nvl.army.mil (Young Lu) Subject: Re: tapping on `make' experts... Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, Quick fix, remove the executable, or just type 'make clean' which removes the .o files. One way to fool 'make' is if your system time and date is screwed, so that your sourcefiles are always older than the executable. Dietrich Opitz -- -- Dietrich Opitz MPI fuer biologische Kybernetik Spemannstr. 38 72076 Tuebingen GERMANY Tel: ++49(7071) 601 606 FAX: ++49(7071) 601 575 e-mail: dio@mpik-tueb.mpg.de From guest Thu Apr 18 11:27:12 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA13439; Thu, 18 Apr 1996 11:15:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA13436; Thu, 18 Apr 1996 11:14:59 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA29223; Thu, 18 Apr 96 11:14:12 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA21191; Thu, 18 Apr 1996 11:14:57 -0700 Received: from proxima.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA29215; Thu, 18 Apr 96 11:14:08 -0700 Received: by proxima.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA00344; Thu, 18 Apr 1996 11:14:53 -0700 From: "Tom McReynolds" Message-Id: <9604181114.ZM342@proxima.asd.sgi.com> Date: Thu, 18 Apr 1996 11:14:53 -0700 In-Reply-To: Swaminathan "Re: Cost of Performer2.0 Manuals.." (Apr 18, 12:30pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Swaminathan , info-performer@sgi.sgi.com Subject: Re: Cost of Performer2.0 Manuals.. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Would you settle for the specification and man pages in html format? The man pages can also be downloaded as a single tar'ed or zip'ed file. http://www.sgi.com/Technology/openGL/spec.html -Tom P.S. http://www.sgi.com/Technology/openGL/opengl.html Is a good place to start for all sorts of OpenGL info... From guest Thu Apr 18 11:29:58 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA13503; Thu, 18 Apr 1996 11:23:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA13500; Thu, 18 Apr 1996 11:23:37 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA29767; Thu, 18 Apr 96 11:22:49 -0700 Received: from virtual.me.uic.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA22593; Thu, 18 Apr 1996 11:23:28 -0700 Received: by virtual.me.uic.edu (940816.SGI.8.6.9/930416.SGI.AUTO) id NAA04605; Thu, 18 Apr 1996 13:23:25 -0500 From: fred@virtual.me.uic.edu (Fred Dech) Message-Id: <199604181823.NAA04605@virtual.me.uic.edu> Subject: Re: pfiInputXform question. To: rainer@RUS.Uni-Stuttgart.DE Date: Thu, 18 Apr 1996 13:23:16 -0500 (CDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <9604181916.ZM14499@awssg6.rus.uni-stuttgart.de> from "Daniela Rainer" at Apr 18, 96 07:16:39 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 957 Status: O Daniela Rainer wrote: > > Hi Fred, > > I had the same problem with pfiXformerMat. It never sets the matrix of the > xformer. I think pfiXformerMat calls pfiInputXformTrackball::setMat(). > > Regards > Daniela > > -- > Daniela Rainer > rainer@rus.uni-stuttgart.de > yes. thanks Daniela. actually, after sending out that message, i eventually tracked down the libpfui source code (kinda ass-backwards, sorry list), and it appears that things are just a bit more complex than i originally thought they were. pfiInputXformTrackball::setMat() doesn't actually do anything to the pfiInputXform matrix. and that's how it is supposed to work. the same holds true for such things as setResetCoord, setMotionCoord. for an explanation on the intricacies of what is actually going on here, get back to me in about a week. or maybe someone who knows will explain it;.> --fred -- Fred Dech fred@virtual.me.uic.edu (312) 413-3619 Fax: (312) 413-0447 From guest Thu Apr 18 12:16:48 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA13872; Thu, 18 Apr 1996 12:07:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA13869; Thu, 18 Apr 1996 12:07:29 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA02835; Thu, 18 Apr 96 12:06:39 -0700 Received: from MAPS.CS.CMU.EDU by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA29694; Thu, 18 Apr 1996 12:07:22 -0700 From: Stephen_Gifford@MAPS.CS.CMU.EDU Received: from MAPS.CS.CMU.EDU by MAPS.CS.CMU.EDU id aa01670; 18 Apr 96 15:07:01 EDT To: info-performer@sgi.sgi.com Subject: Memory management question Date: Thu, 18 Apr 96 15:06:56 -0400 Message-Id: <1667.829854416@MAPS.CS.CMU.EDU> Status: O We have a Performer program that basically does the following iteratively: Read geometry into Performer structures Rebuild each geoset with the GeoBuilder Free the old geoset Write the new geometry pfDelete() the hierarchy Everything is allocated with pfNew* or pfMalloc (geoset arrays). We got what looks to be a massive core leak, so we tried the following: Read geometry into Performer structures Write geometry back out pfDelete() the hierarchy And we still have massive core leaks. So we decided to try deleting the hierarchy ourselves, thinking that perhaps geosets arrays were being leaked. Here we explicitly pfFree()'ed all the geoset arrays, and pfDelete()'ed all the pfNodes. And still have massive core leak problems. Has anyone else had similar problems and managed to solve them? -thanks Steve Gifford Digital Mapping Laboratory School of Computer Science Carnegie Mellon University From guest Thu Apr 18 12:51:16 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA14060; Thu, 18 Apr 1996 12:42:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA14057; Thu, 18 Apr 1996 12:42:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA04587; Thu, 18 Apr 96 12:41:07 -0700 Received: from smtp-gw01.ny.us.ibm.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA04724; Thu, 18 Apr 1996 12:41:51 -0700 Received: (from uucp@localhost) by smtp-gw01.ny.us.ibm.net (8.6.9/8.6.9) id TAA75429 for ; Thu, 18 Apr 1996 19:41:46 GMT Date: Thu, 18 Apr 1996 19:41:46 GMT Message-Id: <199604181941.TAA75429@smtp-gw01.ny.us.ibm.net> Received: from slip139-92-18-55.pt.uk.ibm.net(139.92.18.55) by smtp-gw01.ny.us.ibm.net via smap (V1.3mjr) id sma3IgDmb; Thu Apr 18 19:41:29 1996 X-Sender: juanj@pop03.ca.us.ibm.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: juanj@ibm.net (Juan J. Gonzalez) Subject: Texture problem on RE with PF2.0 X-Mailer: Status: O Hello. I have a visual simulator developed on an Indigo2 High Impact with Performer 2.0 compiled with OpenGL libraries. Now i want to run same executable on a Onyx RE, it runs fine, but textures apears with all colors changed, like RGBA components was swaped or something like this. All frames appears like they was on false colors. I want to know if i must compile my simulator with IRIS GL, or there is another solution with actual OpenGL makefile. Indigo2 is an High Impact with TRAM option. Onyx RE is an Reality Station with 2 RMs. All running IRIX 5.3 and Performer 2.0. Thank you, ----------------------------------------------------- Juan J. Gonzalez - juanj@ibm.net Division de Desarrollo. SAIS. (Oviedo / Spain). ----------------------------------------------------- From guest Thu Apr 18 15:38:17 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA15083; Thu, 18 Apr 1996 15:23:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA15080; Thu, 18 Apr 1996 15:23:09 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA14139; Thu, 18 Apr 96 15:22:54 -0700 Received: from amelnx.advmar.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA00671; Thu, 18 Apr 1996 15:22:33 -0700 From: Hill_Brian@amelnx.advmar.com Received: from cc:Mail by amelnx.advmar.com id AA829877066; Thu, 18 Apr 96 18:21:37 EST Date: Thu, 18 Apr 96 18:21:37 EST Message-Id: <9603188298.AA829877066@amelnx.advmar.com> To: info-performer@sgi.sgi.com Subject: (???) multi-lobed inverse billboard like grand viewing Status: O What did he say???? :) ______________________________ Forward Header __________________________________ Subject: multi-lobed inverse billboard like grand viewing Author: koopman@ctc.com (Michael G. Koopman) at Internet Date: 4/17/96 3:26 PM Dear Performer Users, Is anyone familiar with methods to support coordination of a twining and pairing plane cleavage 3-view, (para-iso)metric scaling but with potential support for asymmetry in twining planes? Robust assurity of bi-quartic modal assemblability is not necessary, though simple 2nd order inverse gear rigid kinematics applications applied to panels of such a structured network would be preferred. (No, rapid animation of mushroom plumes is not the final intention [but injectors on ST lines might be an interesting non-affine demo].) Thanks for any pointers (esp. sinh quarternion blob-like), Michael G. Koopman, Comp. Sys. Specialist | CTC (Concurrent Technologies Corp.) | +1 814.269.2637 1450 Scalp Ave., Johnstown PA 15904 | facsimile x2666 -- P.S. no Grape Circle gimbals need reply, sans sharp retort in ordering. From guest Thu Apr 18 16:19:54 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id QAA15407; Thu, 18 Apr 1996 16:12:02 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id QAA15404; Thu, 18 Apr 1996 16:12:02 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA16968; Thu, 18 Apr 96 16:11:57 -0700 Received: from relay5.UU.NET by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA08079; Thu, 18 Apr 1996 16:11:56 -0700 Received: from uucp5.UU.NET by relay5.UU.NET with SMTP id QQamam04541; Thu, 18 Apr 1996 19:12:03 -0400 (EDT) Received: from ds9.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Thu, 18 Apr 1996 19:12:32 -0400 Received: from cavalier.cambridge.com by cambridge.com (4.1/SMI-4.1-SWS) id AA08641; Thu, 18 Apr 96 18:58:48 EDT Received: by cavalier.cambridge.com (940816.SGI.8.6.9/SMI-4.1-rbj) id SAA00792; Thu, 18 Apr 1996 18:58:48 -0400 From: "Gan Wang" Message-Id: <9604181858.ZM790@cavalier> Date: Thu, 18 Apr 1996 18:58:47 -0400 In-Reply-To: uunet!MAPS.CS.CMU.EDU!Stephen_Gifford "Memory management question" (Apr 18, 3:06pm) References: <1667.829854416@MAPS.CS.CMU.EDU> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: uunet.uu.net!uunet!MAPS.CS.CMU.EDU!Stephen_Gifford Subject: Re: Memory management question Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 18, 3:06pm, uunet!MAPS.CS.CMU.EDU!Stephen_Gifford wrote: > Subject: Memory management question > > We have a Performer program that basically does the following > iteratively: > > Read geometry into Performer structures > Rebuild each geoset with the GeoBuilder > Free the old geoset > Write the new geometry > pfDelete() the hierarchy > > Everything is allocated with pfNew* or pfMalloc (geoset arrays). > We got what looks to be a massive core leak, so we tried the > following: > > Read geometry into Performer structures > Write geometry back out > pfDelete() the hierarchy > > And we still have massive core leaks. > So we decided to try deleting the hierarchy ourselves, thinking that > perhaps geosets arrays were being leaked. Here we explicitly > pfFree()'ed all the geoset arrays, and pfDelete()'ed all the pfNodes. > And still have massive core leak problems. > > Has anyone else had similar problems and managed to solve them? > > -thanks > Steve Gifford > Digital Mapping Laboratory > School of Computer Science > Carnegie Mellon University > > > >-- End of excerpt from uunet!MAPS.CS.CMU.EDU!Stephen_Gifford Is it possible that you have configured a pfMultiprocess mode such as PFMP_APP_CULL_DRAW and, at the same time, when you do "Free the old geoset" you used pfFree() instead of pfDelete()? If that is the case, you may be destroying gsets that pfDraw() would still expect to draw in the next frame time, and it gets upset with corrupted memory and dumpts core. PfFree is heavy-handed and does not honor the reference counts. You can confirm this is true by changing the mode to PFMP_APPCULLDRAW. If you have to "Free the old geoset" on the fly in multiprocess mode, you may have to find a way not to delete/free the gsets until after the draw process is done with them, such as frame stamping them. Hope it helps. Gan -- Gan Wang Cambridge Research Associates Office: 703-790-0505/703-917-5731 1430 Spring Hill Road, Suite 200 Fax: 703-790-0370 McLean, VA 22102 Internet: gan@cambridge.com From guest Thu Apr 18 17:03:07 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id QAA15729; Thu, 18 Apr 1996 16:51:04 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id QAA15726; Thu, 18 Apr 1996 16:51:00 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA19139; Thu, 18 Apr 96 16:50:53 -0700 Received: from holodeck.csd.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA13617; Thu, 18 Apr 1996 16:50:48 -0700 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id QAA15715; Thu, 18 Apr 1996 16:50:45 -0700 From: aschaffe (Allan Schaffer) Message-Id: <9604181650.ZM15713@holodeck.csd.sgi.com> Date: Thu, 18 Apr 1996 16:50:45 -0700 In-Reply-To: kanou@ddd.co.jp (Y.Kanou) "IR video format" (Apr 17, 4:43pm) References: <19960417074321646.AAA133@[202.230.84.102]> X-Mailer: Z-Mail-SGI (3.2S.1 10apr95 MediaMail) To: kanou@ddd.co.jp (Y.Kanou), info-performer@sgi.sgi.com Subject: Re: IR video format Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 17, 4:43pm, Y.Kanou wrote: > I heard that InfiniteReality can output 2 channel without MCO. > Does anyone know what kind of video format? There's quite a few, here's the list of the ones shipped on the IRIX 6.2 CD: 1024x768_60 1024x768_96s 1080x809_30i 1200x900_72 1280x1024_120s 1280x1024_25r2 1280x1024_25r3 1280x1024_30r2 1280x1024_50 1280x1024_60 1280x1024_72 1280x959_30i 1500x1200_60 1600x1200_60 1760x1100_60 1920x1035_30i 1920x1080_72 1920x1200_66 640x480_120s 640x480_180q 640x480_60 640x486_30i 646x486_30i 646x486_30if 768x576_25i 768x576_25if 800x600_60 960x680_60 CCIR601_525 CCIR601_625 [any per-channel combination of the above can be used, and they can also be resized using /usr/gfx/ircombine] Allan -- Allan Schaffer aschaffe@sgi.com Silicon Graphics http://reality.sgi.com/aschaffe From guest Thu Apr 18 17:12:21 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA15781; Thu, 18 Apr 1996 17:01:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA15778; Thu, 18 Apr 1996 17:01:31 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA19962; Thu, 18 Apr 96 17:01:24 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id RAA15171; Thu, 18 Apr 1996 17:01:20 -0700 Received: from precious.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA19939; Thu, 18 Apr 96 17:01:10 -0700 Received: (from nemec@localhost) by precious.asd.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA11640; Thu, 18 Apr 1996 17:00:22 -0700 From: "Philip Nemec" Message-Id: <9604181700.ZM11638@precious.asd.sgi.com> Date: Thu, 18 Apr 1996 17:00:22 -0700 In-Reply-To: "Dietrich Opitz" "Re: tapping on `make' experts..." (Apr 18, 7:12pm) References: <9604181912.ZM20357@squash.mpik-tueb.mpg.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Dietrich Opitz" , lu@bongo.nvl.army.mil (Young Lu) Subject: Re: tapping on `make' experts... Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Rather than changing the system time: touch *.C *.c *.h Much cleaner - and a much more local scope. ------ And a longer answer - there is an option for the compiler (both cc and CC) to automatically update the dependencies in a file... So adding "-MDupdate Makefile" updates the Makefile so that next time the Makefile has the new dependencies. From guest Thu Apr 18 17:52:26 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA16228; Thu, 18 Apr 1996 17:45:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA16225; Thu, 18 Apr 1996 17:45:31 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA22622; Thu, 18 Apr 96 17:45:22 -0700 Received: from dub-img-1.compuserve.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA21304; Thu, 18 Apr 1996 17:45:21 -0700 Received: by dub-img-1.compuserve.com (8.6.10/5.950515) id UAA00563; Thu, 18 Apr 1996 20:45:18 -0400 Date: 18 Apr 96 20:44:01 EDT From: Gerhard Empl <100535.3606@CompuServe.COM> To: Subject: Performer Live-video sirius problem Message-Id: <960419004401_100535.3606_JHB69-1@CompuServe.COM> Status: O Hello, we've the task to incorporate live video into a performer application from a Sirius board. It went quite well with 2 exceptions: (1) the texture "leaks out" (is applied to) other polygons as well unless it is loaded as last one (thats a problem we can live with but might be the reason for others). (2) the frame rate drops down from 50 to 25 (or 60 to 30) when applying the video. We then set the texture loading to be done only once via performer and loaded the frame at the end of the drawing loop via vl. Surprisingly this call only took a very short time, so the Sirius board seems to synchronize itself with the video input blocking the raster engine during that period. here another formulation of our problems: Problem 1: Hardware: Onyx RE2 / 4 RM5 / Sirius Option Library: Performer 2.0 Display: 50 Hz Problem: We need to get a rendered scene with a live video-input at 50hz framerate. What we do have now: We got a stable framerate of 50 hz, but as soon as we turn on the live video-input and drain it to the RM, the framerate drops to appr. 25 hz. We use SIR_TEX_PACK_RGB_5 packing for the tex drain. What we tried: We tried to draw only the Live-Video Texture --> still appr. 25 hz framerate. We tried interleaved and non-interleaved --> no effect We tried PFTEX_LIST_APPLY and PFTEX_BASE_AUTO_SUBLOAD We tried to reduce the texture size from 1024*1024 to 512*512 --> the machine crashed. Question: Is there a way of getting Live-Video- input to texture memory with a 50 frames/sec? It seems to us that the video-transfer blocks the rendering completely, because the sirius option has to wait until it gets a complete frame. We could also live with a quality penalty of the live input, but our framerate has to be stable 50 hz. Problem 2: Hardware: Onyx RE2 / 4 RM5 / Sirius Option Library: Performer 2.0 Display: 50 Hz Problem: How do we get a texture on a loaded graphic e.g: .obj ? Problem 3: Hardware: Onyx RE2 / 4 RM5 / Sirius Option Library: Performer 2.0 Display: 50 Hz Problem: As soon as our Live-video-texture gets into view, it sometimes happens that the video-input is drained to the wrong textures. It seems that the sirius board sometimes writes into the wrong texture memory adress. Thank you very much for your help, Gerhard Empl, R2 E-Mail: 100535.3606@compuserve.com E-mail from: Gerhard Empl, 19-Apr-1996 From guest Thu Apr 18 21:24:10 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id VAA16612; Thu, 18 Apr 1996 21:15:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id VAA16609; Thu, 18 Apr 1996 21:15:47 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA00571; Thu, 18 Apr 96 21:15:28 -0700 Received: from mred.bgm.link.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id VAA10749; Thu, 18 Apr 1996 21:15:19 -0700 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA24721; Thu, 18 Apr 96 23:12:57 -0500 Date: Thu, 18 Apr 96 23:12:57 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9604190412.AA24721@mred.bgm.link.com> To: info-performer@sgi.sgi.com Subject: subtexload error message!?! Status: O I noticed this in my SYSLOG file for today :- Apr 19 22:02:07 2A:sutcliffe unix: subtexload ioctl: Changing page sizes NOT allowed Apr 19 22:03:16 2A:sutcliffe last message repeated 1343 times Apr 19 22:03:16 2A:sutcliffe unix: subtexload ioctl: Changing page sizes NOT allowed Apr 19 22:03:17 2A:sutcliffe last message repeated 36 times (We are talking RE2, IRIX 5.3, Perf 2.0 here) I was running my usual Performer-based application at about the time the messages were logged - so I presume it's something I or Performer have done. Notice the *insane* numbers of repititions of each message - this presumably means that the message is being spewed out to the SYSLOG about once a frame (if you divide the time between messages into the number of repetitions, you get something like 19Hz as the result - which is a figure I could believe). I'm a little puzzled by this because I don't call 'subtexload' anywhere in my code - although I *do* call fbsubtexload once per frame. My program *seemed* to be running correctly and GL didn't spew messages to stdout/stderr - only into the SYSLOG file! Could some IrisGL guru out there suggest what on earth "Changing page sizes NOT allowed" means? There doesn't appear to be any reference to it in the man pages for subtexload or fbsubtexload. HELP!!!! Steve Baker Steve Baker 817-323-1361 (Vox-Lab) Hughes Training Inc. 817-695-8776 (Vox-Office/vMail) 2200 Arlington Downs Road 817-695-4028 (Fax) Arlington, Texas. TX 76005-6171 steve@mred.bgm.link.com (eMail) From guest Thu Apr 18 23:43:59 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA16857; Thu, 18 Apr 1996 23:37:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA16854; Thu, 18 Apr 1996 23:37:42 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA03559; Thu, 18 Apr 96 23:37:16 -0700 Received: from newton.ncsa.uiuc.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id XAA20165; Thu, 18 Apr 1996 23:37:39 -0700 Received: from space.ncsa.uiuc.edu (space.ncsa.uiuc.edu [141.142.4.10]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with ESMTP id BAA05730; Fri, 19 Apr 1996 01:37:20 -0500 Received: (from wsherman@localhost) by space.ncsa.uiuc.edu (8.6.11/8.6.11) id BAA24438; Fri, 19 Apr 1996 01:37:08 -0500 Date: Fri, 19 Apr 1996 01:37:08 -0500 From: William Sherman -Visualization Message-Id: <199604190637.BAA24438@space.ncsa.uiuc.edu> To: aschaffe, info-performer@sgi.sgi.com, kanou@ddd.co.jp Subject: Re: IR video format Cc: wsherman@space.ncsa.uiuc.edu Status: O > From: aschaffe@holodeck.csd.sgi.com (Allan Schaffer) > > On Apr 17, 4:43pm, Y.Kanou wrote: > > I heard that InfiniteReality can output 2 channel without MCO. > > Does anyone know what kind of video format? > > There's quite a few, here's the list of the ones shipped on the > IRIX 6.2 CD: > > 1024x768_96s > 1280x1024_120s > 640x480_120s Since stereo vof's were missing from the RE2-MCO, I'm glad to see that this is built in to the IR (re3) system. However, I've heard rumors that the left/right eyes were switched in the IMPACTS, and I've had some problems syncing stereo between multiple pipes on a RE2 system running 5.3 w/ patch 918, so I hope some effort is spent to make sure all this will run when the stuff starts shipping. > [any per-channel combination of the above can be used, and > they can also be resized using /usr/gfx/ircombine] Cool. > Allan Bill From guest Fri Apr 19 00:21:00 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id AAA16931; Fri, 19 Apr 1996 00:13:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA16928; Fri, 19 Apr 1996 00:13:08 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA04772; Fri, 19 Apr 96 00:12:40 -0700 Received: from listserv.gmd.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id AAA22427; Fri, 19 Apr 1996 00:13:05 -0700 Received: from mailer.mpib-tuebingen.mpg.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <8.D9C49B68@listserv.gmd.de>; Fri, 19 Apr 1996 9:12:52 +0200 Received: from bogart.mpib-tuebingen.mpg.de by mailer.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0912AM) id AA05056; Fri, 19 Apr 1996 08:49:46 +0100 Received: from squash.mpik-tueb.mpg.de by bogart.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0442PM) id AA05327; Fri, 19 Apr 1996 09:13:37 +0100 Received: by squash (940816.SGI.8.6.9/940406.SGI) id JAA21056; Fri, 19 Apr 1996 09:12:46 +0200 From: "Dietrich Opitz" Message-Id: <9604190912.ZM21054@squash.mpik-tueb.mpg.de> Date: Fri, 19 Apr 1996 09:12:45 +0000 In-Reply-To: "Philip Nemec" "Re: tapping on `make' experts..." (Apr 18, 5:00pm) References: <9604181912.ZM20357@squash.mpik-tueb.mpg.de> <9604181700.ZM11638@precious.asd.sgi.com> X-Face: ,78BGR^:N$.'76:g~S1U^5[;4H@V1KZvxT0W&ugiSX!CO}A((fKEnL2;vdw~RdA'C}Snv2n/1pB3cZjiFbN{Q}nXx}2cd* X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Philip Nemec" Subject: Re: tapping on `make' experts... Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, i don't recommended to change system time. It happened to me once, that 'make' did not recompile changed source files. It was found out that because of powerfail the system clock was set to last year (time was ok.) So all new files where dated backwards in time and so 'make' always found younger .o and exe files. Reseting the clock fixed it.... Cheers Dietrich From guest Fri Apr 19 00:44:54 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id AAA17024; Fri, 19 Apr 1996 00:37:25 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA17021; Fri, 19 Apr 1996 00:37:24 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA05574; Fri, 19 Apr 96 00:36:54 -0700 Received: from barney.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id AAA23923; Fri, 19 Apr 1996 00:37:20 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id IAA05482; Fri, 19 Apr 1996 08:37:07 +0100 From: "Rob Jenkins" Message-Id: <9604190837.ZM5480@barney.reading.sgi.com> Date: Fri, 19 Apr 1996 08:37:07 +0100 In-Reply-To: Swaminathan "Re: Cost of Performer2.0 Manuals.." (Apr 18, 12:30pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Swaminathan , info-performer@sgi.sgi.com Subject: Re: Cost of Performer2.0 Manuals.. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 18, 12:30pm, Swaminathan wrote: > Subject: Re: Cost of Performer2.0 Manuals.. > > This is definitely not a flame, but I noticed a conspicuous absence of > OpenInventor and OpenGL manuals in postscript form. Perhaps they are so > "Open", the royalty accruing from selling the manuals cannot be ignored? > > Swami > >-- End of excerpt from Swaminathan don't forget they are online as Insight books. You can install them from: gl_dev.books.OpenGL_PG OpenGL Programming Guide gl_dev.books.OpenGL_Porting OpenGL Porting Guide gl_dev.books.OpenGL_RM OpenGL Reference Manual inventor_dev.books.Mentor Insight Book : Inventor Mentor inventor_dev.books.PortAndPerf Insight Book : Inventor 2.1 Porting and Performance Tips inventor_dev.books.Toolmaker Insight Book : Inventor Toolmaker If you don't have them. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. Forum 1, Station Road, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Fri Apr 19 05:58:14 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA17465; Fri, 19 Apr 1996 05:48:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA17462; Fri, 19 Apr 1996 05:48:31 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA10431; Fri, 19 Apr 96 05:47:45 -0700 Received: from mothra.csi-east.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA11984; Fri, 19 Apr 1996 05:48:26 -0700 Received: by mothra.csi-east.com (940816.SGI.8.6.9/940406.SGI.AUTO) id IAA24091; Fri, 19 Apr 1996 08:48:18 -0400 From: "Christopher Cressy" Message-Id: <9604190847.ZM24089@mothra.csi-east.com> Date: Fri, 19 Apr 1996 08:47:21 -0400 In-Reply-To: Hill_Brian@amelnx.advmar.com "(???) multi-lobed inverse billboard like grand viewing" (Apr 18, 6:21pm) References: <9603188298.AA829877066@amelnx.advmar.com> Reply-To: cressy@coryphaeus.com X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Hill_Brian@amelnx.advmar.com, info-performer@sgi.sgi.com Subject: Re: (???) multi-lobed inverse billboard like grand viewing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 18, 6:21pm, Hill_Brian@amelnx.advmar.com wrote: > Subject: (???) multi-lobed inverse billboard like grand viewing > What did he say???? :) Perhaps he's asking for pick-up lines to use while networking in 3-view virtual chat rooms to pick up twin (twining?) women with asymmetric, blob-like cleavage. __________________________________ > Subject: multi-lobed inverse billboard like grand viewing > Author: koopman@ctc.com (Michael G. Koopman) at Internet > Date: 4/17/96 3:26 PM > > > Dear Performer Users, > > Is anyone familiar with methods to support coordination of a twining > and pairing plane cleavage 3-view, (para-iso)metric scaling but with > potential support for asymmetry in twining planes? Robust assurity of > bi-quartic modal assemblability is not necessary, though simple 2nd > order inverse gear rigid kinematics applications applied to panels of > such a structured network would be preferred. (No, rapid animation of > mushroom plumes is not the final intention [but injectors on ST lines > might be an interesting non-affine demo].) > > Thanks for any pointers (esp. sinh quarternion blob-like), > > Michael G. Koopman, Comp. Sys. Specialist | > CTC (Concurrent Technologies Corp.) | +1 814.269.2637 > 1450 Scalp Ave., Johnstown PA 15904 | facsimile x2666 > > -- > P.S. no Grape Circle gimbals need reply, sans sharp retort in ordering. > >-- End of excerpt from Hill_Brian@amelnx.advmar.com From guest Fri Apr 19 08:05:02 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA17660; Fri, 19 Apr 1996 07:55:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA17657; Fri, 19 Apr 1996 07:55:33 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA13449; Fri, 19 Apr 96 07:55:32 -0700 Received: from huey.ntsc.navy.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA23736; Fri, 19 Apr 1996 07:55:29 -0700 From: william_marinelli@ntsc.navy.mil Received: from CCMAIL.NTSC.NAVY.MIL ([192.44.253.30]) by huey.ntsc.navy.mil (4.1/SMI-4.1) id AA00317; Fri, 19 Apr 96 10:55:32 EDT Received: from ccMail by CCMAIL.NTSC.NAVY.MIL (SMTPLINK V2.11) id AA829936541; Fri, 19 Apr 96 10:50:39 EST Date: Fri, 19 Apr 96 10:50:39 EST Message-Id: <9603198299.AA829936541@CCMAIL.NTSC.NAVY.MIL> To: info-performer@sgi.sgi.com Subject: We be doin some polytopin, Boass! Status: O Starting with a rectangular room which is axially aligned in multigen, we want our "bounding box" to be aligned with the model regardless of weather the model is axially aligned or not wrt the viewpoint in the app. So scratch the traditional pfBox. We are able to take the multigen xyz(max) and xyz(min) and make planes with pfMakePts (I'm skipping some trivial steps here) and then make a polytope with pfPtopeFacet. Complaint number 1: Wouldn't it be nice if we could map a box to a polytope with one function call? Complaint number 1a: When you use points to make a plane and then make the polytope, the order of the three points is not important so that the plane normal is pointing out - that is - so the order of the three points that go into pfMakePts is important. Worked it out thru trial and error - am sure that there's a more robust way. Another reason I prefer that the function call which I mentioned above was available. After making a polytope with xyzmin = (000) and xyzmax = (111), when I did a check of the box center (0.5 0.5 0.5) with pfPolytopeContainsPt all I got was a PFIS_MAYBE. Does that make sense? Dave Luebke, if you're out there, this concerns portals,FYI. Have a good weekend. __,-~~/~ `---. _/_,---( , ) __ / < / ) \___ - ------===;;;'====------------------===;;;===----- - - \/ ~"~"~"~"~"~\~"~)~"/ (_ ( \ ( > \) \_( _ < >_>' ~ `-M' ::>|--" M;|.|.| M;|.|.| M;|.|.| Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA17973; Fri, 19 Apr 1996 10:25:46 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA20327; Fri, 19 Apr 96 10:25:45 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA16136; Fri, 19 Apr 1996 10:25:42 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA25354; Fri, 19 Apr 1996 18:25:26 +0100 From: "Angus Dorbie" Message-Id: <9604191825.ZM25352@bitch.reading.sgi.com> Date: Fri, 19 Apr 1996 18:25:25 +0100 In-Reply-To: "John Archdeacon" "OpenGVS Cross Platform API" (Apr 17, 1:18pm) References: <199604172008.NAA25916@gemtech.gemtech.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "John Archdeacon" , "Performer News" Subject: Re: OpenGVS Cross Platform API Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I've heard about OpenGVS & it sounds like a worthwhile goal but my main concern is that it cannot keep pace with innovative hardware and OpenGL extensions on Silicon Graphics platforms, which has a considerable technology lead over other suppliers. I'm not saying it doesn't, I'm just saying this is a concern I have, could you please comment. I'd also like to add that some of the suppliers mentioned by others earlier in this thread seem to be completely uncommitted to the Visual Simulation market. They're not even making a half hearted attempt to tackle the difficult problems we all face. There is competition out there but HP & SUN in Vis Sim? Rgds, Angus. > First, let me say that Performer is a great productivity product, and so is OpenGVS. As Don pointed out, OpenGVS is a computer image generation API with "basically everything Performer has" but unlike Performer, OpenGVS is intended (by design and focus) to be FULLY cross platform compatible at the end user application level while still delivering ALL of the underlying graphics hardware performance to the end user. > >-- End of excerpt from John Archdeacon -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Fri Apr 19 10:08:09 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA17882; Fri, 19 Apr 1996 09:39:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA17879; Fri, 19 Apr 1996 09:39:42 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA17601; Fri, 19 Apr 96 09:39:34 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA08398; Fri, 19 Apr 1996 09:39:27 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) id JAA18408; Fri, 19 Apr 1996 09:38:40 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA04913; Fri, 19 Apr 1996 09:37:47 -0700 From: "AnitaKishore" Message-Id: <9604190937.ZM4911@lee.electrogig.com> Date: Fri, 19 Apr 1996 09:37:46 -0700 In-Reply-To: ROY RUDDLE "Loading textures on an RE" (Apr 16, 12:48pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Ruddle@cardiff.ac.uk, info-performer@sgi.sgi.com Subject: Re: Loading textures on an RE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 16, 12:48pm, ROY RUDDLE wrote: > Subject: Loading textures on an RE > This must have a simple answer, but I can't find it anywhere: > > As I'm running a small DB I want to force all textures to be loaded into > the RE's texture memory while (or just after) the DB is loaded. I've got > plenty of texture memory. At the moment (ie. by default) textures are > being paged in when they first get displayed. > > Does anyone know the answer? > > > cheers > > roy >-- End of excerpt from ROY RUDDLE You can take a look at perfly code. This does what you want. Also the man page of pfuMakeTexList will be helpful. -anita From guest Fri Apr 19 10:10:53 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA17900; Fri, 19 Apr 1996 09:54:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA17897; Fri, 19 Apr 1996 09:54:15 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA18267; Fri, 19 Apr 96 09:54:14 -0700 Received: from relay2.eunet.fr by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA10780; Fri, 19 Apr 1996 09:53:59 -0700 Received: from syseca.syseca.fr (syseca.syseca.fr) by relay2.eunet.fr (5.65c8d/96.04.04) via EUnet-France id AA18380; Fri, 19 Apr 1996 18:53:55 +0200 (MET) Received: from anna by syseca.syseca.fr (4.1/SMU-4.0 22/11/92 Syseca) id AA27292; Fri, 19 Apr 96 18:56:39 +0200 Received: by anna (940816.SGI.8.6.9/930416.SGI) for info-performer@sgi.com id SAA26920; Fri, 19 Apr 1996 18:45:13 +0200 From: "Laurent Ach" Message-Id: <9604191845.ZM26918@anna.reality> Date: Fri, 19 Apr 1996 18:45:13 -0600 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: meshes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hello I have to generate meshes from any type of pfGeoSet with Performer 2.0 and I tried to use pfdMeshGSet. But this function doesn't work with any type of pfGeoSet and often returns NULL. Would any one know in which case it can be used and what other means are available for making triangle meshes using Performer 2.0 Thank you, Laurent Ach Email: ach@syseca.fr From guest Fri Apr 19 10:14:08 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA17909; Fri, 19 Apr 1996 10:03:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA17906; Fri, 19 Apr 1996 10:03:14 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA18801; Fri, 19 Apr 96 10:03:12 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA12293; Fri, 19 Apr 1996 10:03:01 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (950215.SGI.8.6.10/940406.SGI) id KAA18463; Fri, 19 Apr 1996 10:02:12 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA04990; Fri, 19 Apr 1996 10:00:59 -0700 From: "AnitaKishore" Message-Id: <9604191000.ZM4988@lee.electrogig.com> Date: Fri, 19 Apr 1996 10:00:58 -0700 In-Reply-To: lu@bongo.nvl.army.mil (Young Lu) "tapping on `make' experts..." (Apr 18, 11:47am) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: lu@bongo.nvl.army.mil (Young Lu), info-performer@sgi.sgi.com (PF2.0) Subject: Re: tapping on `make' experts... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 18, 11:47am, Young Lu wrote: > Subject: tapping on `make' experts... > Hi there, > > What do I need to do if a `make' does not pick up the changes in any of its > files once it was compiled once ? In another word, if I modify my one of the > files and compile with `make', it simply ignores the changes and declares > that the executable is up-to-date, thus no need for compiling. > > I wonder if any environmental variable need some attention here. > > I appreciate any help. Thanks. > -- > Young T. Lu lu@nvl.army.mil > > >-- End of excerpt from Young Lu Check the date and time on the .o files. Sometimes if the clock had gone bad at the time when you compiled first, and if the time stamp it put on the files were greater than the right time, then your files will never compile again unless your current time is greater than the .o files time. It happens to us very often on the Onyx, so this might be woth checking out. -anita From guest Fri Apr 19 14:27:57 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA18821; Fri, 19 Apr 1996 14:19:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA18818; Fri, 19 Apr 1996 14:19:35 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA02768; Fri, 19 Apr 96 14:19:33 -0700 Received: from physics.ucla.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA26027; Fri, 19 Apr 1996 14:19:07 -0700 Received: from scotch.physics.ucla.edu by physics.ucla.edu (SMI-8.6/SMI-SVR4) id MAA05467; Fri, 19 Apr 1996 12:49:52 -0700 Received: by scotch.physics.ucla.edu (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.sgi.com id MAA05601; Fri, 19 Apr 1996 12:32:25 -0700 Date: Fri, 19 Apr 1996 12:32:25 -0700 From: chris@scotch.physics.ucla.edu (chris) Message-Id: <199604191932.MAA05601@scotch.physics.ucla.edu> To: info-performer@sgi.sgi.com Subject: Colors and Colortables Status: O Hi, I am using performer to model isosurfaces, and I would like to assign color values on a per-primitive basis according to posistion of the primitive in space. It seems like this should be easy, but there is very little useful info on pfColortables and pfGSetAttr in the manuals. If I choose not to use a color table, and I assign pfGSetAttr PER_PRIMITIVE, what are the connection rules for the ushort *list argument? Vertex connections are well explained in chapter 10 of PG, but Color connections are ignored. What are the indexing rules if I use the colortable? Are they per Geoset? If so, it would seem that I must make each polygon an independent geoset to have independent coloring. I really hope that's not true. Chris //////////////////////////////////////////////////// //Chris Mitchell -- // //Institute of Plasma and Fusion Research (IPFR) // //UCLA Physics Department 310-206-1772 // //mitchell@physics.ucla.edu // //chris@scotch.physics.ucla.edu // // // //"Self Reliance, the height and perfection of // // man, is reliance on God." // // --Ralph Waldo Emmerson // //////////////////////////////////////////////////// From guest Fri Apr 19 15:36:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA19241; Fri, 19 Apr 1996 15:27:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA19238; Fri, 19 Apr 1996 15:27:54 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA08232; Fri, 19 Apr 96 15:27:52 -0700 Received: from MAPS.CS.CMU.EDU by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA07376; Fri, 19 Apr 1996 15:27:20 -0700 From: Stephen_Gifford@MAPS.CS.CMU.EDU Received: from MAPS.CS.CMU.EDU by MAPS.CS.CMU.EDU id aa06095; 19 Apr 96 16:26:56 EDT To: info-performer@sgi.sgi.com Subject: Re: Memory management question In-Reply-To: Your message of "Thu, 18 Apr 96 18:58:47 EDT." <9604181858.ZM790@cavalier> Date: Fri, 19 Apr 96 16:26:49 -0400 Message-Id: <6093.829945609@MAPS.CS.CMU.EDU> Status: O > Is it possible that you have configured a pfMultiprocess mode such as > PFMP_APP_CULL_DRAW and, at the same time, when you do "Free the old geoset" you > used pfFree() instead of pfDelete()? If that is the case, you may be > destroying gsets that pfDraw() would still expect to draw in the next frame > time, and it gets upset with corrupted memory and dumpts core. PfFree is > heavy-handed and does not honor the reference counts. You can confirm this is > true by changing the mode to PFMP_APPCULLDRAW. The pfMultiprocess mode has been PFMP_APPCULLDRAW (0) through all of these attempts. Since we're not actually drawing the geometry, only using pf functions to manipulate it, pfDraw is never being called. The program is simply running out of shared memory after growing larger and larger in a linear fashion. This looks to me like a core leak of some kind. I'm curious if anyone else has had success with similar work: processing 200+MB of data in a piece by piece fashion (iterating over a rectangular grid of load modules read in from disk, for example). In particular, anything where a Performer related core leak would cause a real problem. -thanks Steve Gifford Digital Mapping Laboratory School of Computer Science Carnegie Mellon University From guest Fri Apr 19 15:31:22 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA19207; Fri, 19 Apr 1996 15:21:11 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA19204; Fri, 19 Apr 1996 15:21:10 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA07779; Fri, 19 Apr 96 15:21:09 -0700 Received: from ht.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA06322; Fri, 19 Apr 1996 15:20:26 -0700 Received: from er.ht.com by ht.com (940816.SGI.8.6.9/3.1.090690-High Techsplanations) id SAA13479; Fri, 19 Apr 1996 18:12:42 -0400 Received: by er.ht.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id SAA08539; Fri, 19 Apr 1996 18:12:37 -0400 From: scott@er.ht.com (Scott McMillan) Message-Id: <199604192212.SAA08539@er.ht.com> Subject: Old monthly archives To: info-performer@sgi.sgi.com Date: Fri, 19 Apr 1996 18:12:37 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 377 Status: O I need to get at some postings about intersection testing that happened in Feb and March. Does anybody store these up? If not, any idea when they will appear at sgigate.sgi.com. scott -- Scott McMillan / scott@ht.com / (301)984-3706 x250 / FAX (301)984-2104 High Techsplanations Inc. 6001 Montrose Road, Suite 902 / Rockville, MD 20852-4874 From guest Fri Apr 19 15:31:15 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA19202; Fri, 19 Apr 1996 15:20:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA19199; Fri, 19 Apr 1996 15:20:30 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA07734; Fri, 19 Apr 96 15:20:29 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA06241; Fri, 19 Apr 1996 15:20:03 -0700 Received: from bitch.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for id KAA03636; Fri, 19 Apr 1996 10:47:33 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id SAA25390; Fri, 19 Apr 1996 18:47:24 +0100 From: "Angus Dorbie" Message-Id: <9604191847.ZM25388@bitch.reading.sgi.com> Date: Fri, 19 Apr 1996 18:47:24 +0100 In-Reply-To: William Sherman -Visualization "Re: IR video format" (Apr 19, 1:37am) References: <199604190637.BAA24438@space.ncsa.uiuc.edu> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: William Sherman -Visualization , aschaffe, info-performer@sgi.sgi.com, kanou@ddd.co.jp Subject: Re: IR video format Cc: wsherman@space.ncsa.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 19, 1:37am, William Sherman -Visualization wrote: > However, I've heard rumors that the left/right eyes were > switched in the IMPACTS, and I've had some problems syncing > stereo between multiple pipes on a RE2 system running 5.3 > w/ patch 918, so I hope some effort is spent to make sure > all this will run when the stuff starts shipping. You mean 'I hope some effort was spent to make sure all this was running before the stuff shipped.' > Bill > >-- End of excerpt from William Sherman -Visualization From guest Fri Apr 19 17:37:42 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA20502; Fri, 19 Apr 1996 17:27:04 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA20499; Fri, 19 Apr 1996 17:27:03 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA15301; Fri, 19 Apr 96 17:27:01 -0700 Received: from evl.eecs.uic.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA23815; Fri, 19 Apr 1996 17:26:59 -0700 Received: from zbox.eecs.uic.edu by evl.eecs.uic.edu via ESMTP (950215.SGI.8.6.10/940406.SGI.AUTO) id TAA09294; Fri, 19 Apr 1996 19:27:04 -0500 Received: (pape@localhost) by zbox.eecs.uic.edu (8.6.12/8.6.4) id AAA02139; Sat, 20 Apr 1996 00:27:03 GMT From: "Dave Pape" Message-Id: <9604191927.ZM2137@zbox.eecs.uic.edu> Date: Fri, 19 Apr 1996 19:27:03 -0500 In-Reply-To: William Sherman -Visualization "Re: IR video format" (Apr 19, 1:37am) References: <199604190637.BAA24438@space.ncsa.uiuc.edu> Reply-To: pape@evl.eecs.uic.edu X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: William Sherman -Visualization , info-performer@sgi.sgi.com Subject: Re: IR video format Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 19, 1:37am, William Sherman -Visualization wrote: > Since stereo vof's were missing from the RE2-MCO, I'm glad to > see that this is built in to the IR (re3) system. > > However, I've heard rumors that the left/right eyes were > switched in the IMPACTS, and I've had some problems syncing > stereo between multiple pipes on a RE2 system running 5.3 > w/ patch 918, so I hope some effort is spent to make sure > all this will run when the stuff starts shipping. Well, as it so happens, our first IR just arrived yesterday, and the left/right phase is in fact backwards in two of the stereo formats (1280x1024_120s & 1024x768_96s). We haven't tested stereo genlock yet. -Dave -- --------------------------------------------------------------------------- Dave Pape Electronic Visualization Laboratory, UIC pape@evl.eecs.uic.edu http://evlweb.eecs.uic.edu/pape/ From guest Fri Apr 19 18:30:26 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA21134; Fri, 19 Apr 1996 18:21:19 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA21131; Fri, 19 Apr 1996 18:21:18 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA17791; Fri, 19 Apr 96 18:21:17 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id SAA00194; Fri, 19 Apr 1996 18:21:11 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA17784; Fri, 19 Apr 96 18:21:09 -0700 Received: by babar.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id SAA12495; Fri, 19 Apr 1996 18:21:07 -0700 From: "Michael T. Jones" Message-Id: <9604191821.ZM12493@babar.asd.sgi.com> Date: Fri, 19 Apr 1996 18:20:59 -0700 In-Reply-To: Stephen_Gifford@MAPS.CS.CMU.EDU "Re: Memory management question" (Apr 19, 4:26pm) References: <6093.829945609@MAPS.CS.CMU.EDU> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Stephen_Gifford@MAPS.CS.CMU.EDU, info-performer@sgi.sgi.com Subject: Re: Memory management question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 19, 4:26pm, Stephen_Gifford@MAPS.CS.CMU.EDU wrote: > Subject: Re: Memory management question > The pfMultiprocess mode has been PFMP_APPCULLDRAW (0) through > all of these attempts. Since we're not actually drawing the geometry, > only using pf functions to manipulate it, pfDraw is never being > called. The program is simply running out of shared memory after > growing larger and larger in a linear fashion. Have you tried libdmalloc as a diagnostic approach? > This looks to me like a core leak of some kind. I'm curious > if anyone else has had success with similar work: processing 200+MB > of data in a piece by piece fashion (iterating over a rectangular grid > of load modules read in from disk, for example). In particular, > anything where a Performer related core leak would cause a real > problem. We don't have known memory leaks, so there is no quick answer of the "just get patch nnn and it will be ok" type. We have done extensive testing and feel that this should not be a leakage situation from in the Performer libraries themselves. Have you examined the loaders that you use for possible memory leaks? If nothing else, run in single process mode, make wrappers for the allocation functions and print out info about each allocation and free with a running total. Just about everyone has some version of this approach in their toolbox and it should help you narrow down the search for the leaky spot if there is such. It may just be that your memory is ref()'ed and this not subject to deletion. Michael Jones -- Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Sun Apr 21 21:29:34 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id VAA25249; Sun, 21 Apr 1996 21:25:28 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id VAA25246; Sun, 21 Apr 1996 21:25:27 -0700 Received: from giraffe.asd.sgi.com by rock.csd.sgi.com via SMTP (950413.SGI.8.6.12/910805.SGI) for id VAA21824; Sun, 21 Apr 1996 21:25:27 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@csd.sgi.com id AA06658; Sun, 21 Apr 96 21:25:26 -0700 Received: from mail0.nk-exa.co.jp by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id VAA10647; Sun, 21 Apr 1996 21:25:22 -0700 Received: from mail1.nk-exa.co.jp by mail0.nk-exa.co.jp (8.6.12+2.4W/3.3W-exa02) with ESMTP id NAA08533; Mon, 22 Apr 1996 13:25:15 +0900 Received: from exagw.nk-exa.co.jp (exagw.nk-exa.co.jp [160.14.254.1]) by mail1.nk-exa.co.jp (8.6.12+2.4W/3.4WEXA05) with ESMTP id NAA02882 for ; Mon, 22 Apr 1996 13:25:16 +0900 Received: from dimwit.dst.nk-exa.co.jp by exagw.nk-exa.co.jp (8.6.12+2.4W/3.4W2/1.4) with SMTP id NAA16684; Mon, 22 Apr 1996 13:18:32 +0900 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 AA01305; Mon, 22 Apr 96 13:23:32 +0900 To: info-performer@sgi.sgi.com Subject: Perf1.2 on IRIX6.2 Date: Mon, 22 Apr 1996 13:23:23 +0900 Message-Id: <1301.830147003@dimwit.dst.nk-exa.co.jp> From: YAMANAKA MASAHIKO Status: O Hello, I believe IRIX6.2forAllPlatform is comming up soon,(or already MRed?) and then, should Perf1.2 work on IMPACT/IRIX6.2 ? I know it's not good idea to use Perf1.2(IrisGL) on IMPACT. But, one of our customers has already developped an application on Extreame. They think, for the time being, to use Perf1.2 and port it to Perf2.0 later. # The application contains some IrisGL calls, so that porting doesn't seem so # easy. Does anyone use Perf1.2/IRIX6.2 ? # I don't think there are, but if someone exists, it will be veryvery appreciated ! Thanks, -- M.Y. From guest Sun Apr 21 22:18:01 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id WAA25360; Sun, 21 Apr 1996 22:13:52 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id WAA25357; Sun, 21 Apr 1996 22:13:52 -0700 Received: from giraffe.asd.sgi.com by rock.csd.sgi.com via SMTP (950413.SGI.8.6.12/910805.SGI) for id WAA23160; Sun, 21 Apr 1996 22:13:51 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@csd.sgi.com id AA07559; Sun, 21 Apr 96 22:13:49 -0700 Received: from gatekeeper.bvr.co.il by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA14074; Sun, 21 Apr 1996 22:13:46 -0700 Received: (from uucp@localhost) by gatekeeper.bvr.co.il (8.6.12/8.6.9) id FAA14311; Mon, 22 Apr 1996 05:14:10 GMT Received: from unknown(192.114.85.105) by gatekeeper.bvr.co.il via smap (V1.3) id sma014309; Mon Apr 22 08:14:08 1996 Received: by genie.bvr.co.il (940816.SGI.8.6.9/931108.SGI.AUTO.ANONFTP) id IAA05069; Mon, 22 Apr 1996 08:14:08 +0300 From: "Ran Yakir" Message-Id: <9604220814.ZM5067@genie.bvr.co.il> Date: Mon, 22 Apr 1996 08:14:07 +0000 In-Reply-To: YAMANAKA MASAHIKO "Perf1.2 on IRIX6.2" (Apr 22, 1:23pm) References: <1301.830147003@dimwit.dst.nk-exa.co.jp> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: YAMANAKA MASAHIKO Subject: Re: Perf1.2 on IRIX6.2 Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I suppose you can install Performer 1.2 on Irix 6.2, BUT, there is a better way. Performer 2.0.1 and 2.1 have compatibility libraries for Performer 1.2. That means that your 1.2 and IrisGL code, will run on Performer 2.0.1 on your IMPACT, so you don't have to take any risk (other than the risk of low IrisGL performance on IMPACT). Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | From guest Mon Apr 22 09:09:33 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA25861; Mon, 22 Apr 1996 08:54:32 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA25856; Mon, 22 Apr 1996 08:54:28 -0700 Received: from giraffe.asd.sgi.com by rock.csd.sgi.com via SMTP (950413.SGI.8.6.12/910805.SGI) for id IAA01422; Mon, 22 Apr 1996 08:54:27 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@csd.sgi.com id AA12655; Mon, 22 Apr 96 03:34:20 -0700 Received: from tcsernet.tcs.ernet.in by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA03755; Mon, 22 Apr 1996 03:31:48 -0700 From: deepa@tcsernet.tcs.ernet.in Message-Id: <9604221609.AA01133@tcsernet.tcs.ernet.in> Subject: pfuFollowPath To: info-performer@sgi.sgi.com Date: Mon, 22 Apr 96 16:06:56 EDT Content-Length: 356 Content-Type: text X-Mailer: ELM [version 2.3 PL2] Status: O Dear Performer users, I have a problem with pfuFollowPath. I am trying to define a path but I have no idea what the parameters of this function mean. There seems to be no man page. Is there anybody who has used it who can tell me what the function does and what the parameters mean? Deepa Krishnan Tata Consultancy Services deepa@tcsernet.tcs.ernet.in From guest Mon Apr 22 09:09:32 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA25864; Mon, 22 Apr 1996 08:54:34 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA25858; Mon, 22 Apr 1996 08:54:29 -0700 Received: from giraffe.asd.sgi.com by rock.csd.sgi.com via SMTP (950413.SGI.8.6.12/910805.SGI) for id IAA01430; Mon, 22 Apr 1996 08:54:28 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@csd.sgi.com id AA12527; Mon, 22 Apr 96 03:24:31 -0700 Received: from sun4nl.NL.net by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA03318; Mon, 22 Apr 1996 03:24:28 -0700 Received: from alley.fel.tno.nl by sun4nl.NL.net with SMTP id AA13492 (5.65b/CWI-3.3); Mon, 22 Apr 1996 12:20:05 +0200 Received: from s00sn1.fel.tno.nl (s00sn1 [134.203.8.207]) by alley.fel.tno.nl (8.6.12/8.6.12) with ESMTP id MAA03240; Mon, 22 Apr 1996 12:17:39 +0200 Received: (from rioj7@localhost) by s00sn1.fel.tno.nl (8.7.3/8.7.3) id MAA23277; Mon, 22 Apr 1996 12:17:49 +0200 (MET DST) From: Veraart Message-Id: <199604221017.MAA23277@s00sn1.fel.tno.nl> Subject: Re: Texture problem on RE with PF2.0 To: juanj@ibm.net (Juan J. Gonzalez) Date: Mon, 22 Apr 1996 12:17:49 +0200 (MET DST) Cc: info-performer@sgi.sgi.com In-Reply-To: <199604181941.TAA75429@smtp-gw01.ny.us.ibm.net> from "Juan J. Gonzalez" at Apr 18, 96 07:41:46 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Status: O > I have a visual simulator developed on an Indigo2 High Impact with > Performer 2.0 compiled with OpenGL libraries. Now i want to run same > executable on a Onyx RE, it runs fine, but textures apears with all colors > changed, like RGBA components was swaped or something like this. All frames > appears like they was on false colors. > > I want to know if i must compile my simulator with IRIS GL, or there > is another solution with actual OpenGL makefile. You must recompile with the IRISGL libraries. Take a look at the makefile of the example programs like simple and complex. OpenGL uses a different color component order than IRISGL. Mario From guest Mon Apr 22 10:05:06 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA25983; Mon, 22 Apr 1996 09:50:24 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA25980; Mon, 22 Apr 1996 09:50:23 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA22839; Mon, 22 Apr 96 09:50:22 -0700 Received: from flipper.pvv.unit.no by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA13363; Mon, 22 Apr 1996 09:50:19 -0700 Received: from datter.pvv.unit.no (20118@datter.pvv.unit.no [129.241.210.204]) by flipper.pvv.unit.no (8.6.12/8.6.12) with SMTP id SAA08827 for ; Mon, 22 Apr 1996 18:50:16 +0200 Received: by datter.pvv.unit.no ; Mon, 22 Apr 1996 18:50:11 +0200 Date: Mon, 22 Apr 1996 18:50:09 +0200 (MET DST) From: Morten Eriksen To: info-performer@sgi.sgi.com Subject: Mousebutton interrupts? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi, I just wanted to hear if anyone on the list have some code (or ideas) on how to set up an interrupt catching mousebutton presses in a Performer application? I need an interrupt routine because polling won't be fast enough if the frame rate drops a bit (I've got a small handweapon connected to one of the mousebuttons for detecting trigging of shots, and the "button down" period of the gun is rather short). Regards, Morten From guest Mon Apr 22 10:44:12 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA26238; Mon, 22 Apr 1996 10:30:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA26235; Mon, 22 Apr 1996 10:30:35 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA26403; Mon, 22 Apr 96 10:30:34 -0700 Received: from ht.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA22266; Mon, 22 Apr 1996 10:30:21 -0700 Received: from er.ht.com by ht.com (940816.SGI.8.6.9/3.1.090690-High Techsplanations) id NAA25574; Mon, 22 Apr 1996 13:20:23 -0400 Received: by er.ht.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id NAA11527; Mon, 22 Apr 1996 13:20:23 -0400 From: scott@er.ht.com (Scott McMillan) Message-Id: <199604221720.NAA11527@er.ht.com> Subject: Retrieving geode isected with. To: info-performer@sgi.sgi.com Date: Mon, 22 Apr 1996 13:20:22 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1587 Status: O I am trying to get a _pointer_ to the pfGeode in my scene graph that I have detected an intersection with. This would be used to limit the isect() on the next pass through the APP to checking against this geode first rather than on the entire scene graph. I am using IRIX5.3/Performer2.0... I have tried using pfGeode *node; if (scene->isect(&seg_set, hits)) { static int flags; hits[0][0]->query(PFQHIT_FLAGS, &flags); if (flags & PFHIT_POINT) { hits[0][0]->query(PFQHIT_NODE, node); but this last line bombs because it seems to expect a node with its own instance already allocated as follows; pfGeode node; : : hits[0][0]->query(PFQHIT_NODE, &node); This does not crash but subsequent node.isect() calls yield no intersections when in fact there should be. I don't think I would want this anyway because, at best, part of the scene graph would be copied into my node anyway which is unwanted overhead....and what about the underlying pfGeoSets? The next try was to use the pfPath: pfPath *prev_geometry_path = new pfPath(); // done once in the constructor : : hits[0][0]->query(PFQHIT_PATH, prev_geometry_path); But this returns a path with zero length....what happened to the path the isect took to get a valid intersection??? Can anybody out there help me get a handle on this? Thanks in advance, scott -- Scott McMillan / scott@ht.com / (301)984-3706 x250 / FAX (301)984-2104 High Techsplanations Inc. 6001 Montrose Road, Suite 902 / Rockville, MD 20852-4874 From guest Mon Apr 22 11:41:22 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA26564; Mon, 22 Apr 1996 11:29:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA26561; Mon, 22 Apr 1996 11:29:19 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA00158; Mon, 22 Apr 96 11:29:17 -0700 Received: from buggy.coryphaeus.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA03764; Mon, 22 Apr 1996 11:29:16 -0700 Received: by buggy.coryphaeus.com (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA25969; Mon, 22 Apr 1996 11:19:24 -0700 Date: Mon, 22 Apr 1996 11:19:24 -0700 From: kowsik@coryphaeus.com (Kowsik Guruswamy) Message-Id: <9604221119.ZM25967@buggy.coryphaeus.com> In-Reply-To: scott@er.ht.com (Scott McMillan) "Retrieving geode isected with." (Apr 22, 1:20pm) References: <199604221720.NAA11527@er.ht.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: scott@er.ht.com (Scott McMillan), info-performer@sgi.sgi.com Subject: Re: Retrieving geode isected with. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 22, 1:20pm, Scott McMillan wrote: > Subject: Retrieving geode isected with. > I am trying to get a _pointer_ to the pfGeode in my scene graph that I have > detected an intersection with. This would be used to limit the isect() on > the next pass through the APP to checking against this geode first rather > than on the entire scene graph. I am using IRIX5.3/Performer2.0... [snip] > pfGeode node; > : > : > hits[0][0]->query(PFQHIT_NODE, &node); > > This does not crash but subsequent node.isect() calls yield no intersections > when in fact there should be. I don't think I would want this anyway > because, at best, part of the scene graph would be copied into my node anyway > which is unwanted overhead....and what about the underlying pfGeoSets? How about pfGeode *node; hits[0][0]->query (PFQHIT_NODE, &node); That should get a pointer to the pfGeode... > The next try was to use the pfPath: > > pfPath *prev_geometry_path = new pfPath(); // done once in the constructor > : > : > hits[0][0]->query(PFQHIT_PATH, prev_geometry_path); > > But this returns a path with zero length....what happened to the path the > isect took to get a valid intersection??? First of all, you have to tell performer to build the pfPath while it's doing the intersection. You need to OR PFTRAV_IS_PATH with the 'mode' field in the pfSegSet, before calling node->isect(...); To get the path... pfPath *prev_geometry_path; ... hits[0][0]->query (PFQHIT_PATH, &prev_geometry_path); The path returned by Performer [If I remember correctly] is reused in the next call to node->isect(). Make sure you copy that into your own path. Also read the man pages for pfNode. It's got tons of info, thanks to Performer 'tired of typing' team. *smile* K. -- kowsik@coryphaeus.com | pirts suiboM a hguorht neeb sah txet sihT http://www.coryphaeus.com | | You are not you, you are me! - arnie work: (408)-395-4537 e201 | From guest Mon Apr 22 11:55:12 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA26598; Mon, 22 Apr 1996 11:40:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA26595; Mon, 22 Apr 1996 11:40:34 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA00890; Mon, 22 Apr 96 11:40:32 -0700 Received: from jeeves.icemt.iastate.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA05849; Mon, 22 Apr 1996 11:39:59 -0700 Received: from denali.icemt.iastate.edu (denali.icemt.iastate.edu [129.186.232.32]) by jeeves.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) with ESMTP id NAA21536 for ; Mon, 22 Apr 1996 13:39:58 -0500 Received: (from uli@localhost) by denali.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) id NAA10803 for info-performer@sgi.sgi.com; Mon, 22 Apr 1996 13:39:57 -0500 From: "Uli Lechner" Message-Id: <9604221339.ZM10801@denali.icemt.iastate.edu> Date: Mon, 22 Apr 1996 13:39:57 -0500 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Texture-Problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi! In order to get rid of a strange Moire effect that I had with my flt database using Performer 2.0.1 (ogl) I forced PFTEX_MIPMAP_TRILINEAR for my textures via pfTexFilter(tex, PFTEX_MINFILTER, PFTEX_MIPMAP_TRILINEAR); This takes care of the Moire effect but now I have vertical lines on my screen at a specific distance. This happens on an RE2 with 2RM5 but not on our RE2 with 2RM4. Any ideas? Uli :-) From guest Mon Apr 22 12:46:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA26897; Mon, 22 Apr 1996 12:32:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA26894; Mon, 22 Apr 1996 12:32:31 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA03749; Mon, 22 Apr 96 12:32:30 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA15104; Mon, 22 Apr 1996 12:32:28 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA15771; Mon, 22 Apr 1996 15:24:54 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id PAA03896; Mon, 22 Apr 1996 15:23:11 -0400 From: "Bernard Leclerc" Message-Id: <9604221523.ZM3894@eagle.cae.ca> Date: Mon, 22 Apr 1996 15:23:07 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: SVR4 or BSD4.3 Signal Handling Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Dear pfUsers, Our Performer-based application interfaces with another simulation process. Upon termination, the simulation will send us a SIGTERM signal (signal 15). I'd like to know which is best: use SVR4 signal handling functions or the BSD 4.3 version? Both seems to work but I'd like to know which is better to coexist peacefully with Performer. Thanks... -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Mon Apr 22 13:17:47 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA27000; Mon, 22 Apr 1996 13:06:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA26997; Mon, 22 Apr 1996 13:06:53 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA05419; Mon, 22 Apr 96 13:06:51 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA20657; Mon, 22 Apr 1996 13:06:49 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA05413; Mon, 22 Apr 96 13:06:47 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id NAA18110; Mon, 22 Apr 1996 13:06:46 -0700 From: "Sharon Clay" Message-Id: <9604221306.ZM18108@rose.asd.sgi.com> Date: Mon, 22 Apr 1996 13:06:45 -0700 In-Reply-To: steve@mred.bgm.link.com (Steve Baker) "subtexload error message!?!" (Apr 18, 11:12pm) References: <9604190412.AA24721@mred.bgm.link.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: steve@mred.bgm.link.com (Steve Baker), info-performer@sgi.sgi.com Subject: Re: subtexload error message!?! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 18, 11:12pm, Steve Baker wrote: > Subject: subtexload error message!?! -> ->I noticed this in my SYSLOG file for today :- -> ->Apr 19 22:02:07 2A:sutcliffe unix: subtexload ioctl: Changing page sizes NOT allowed ->Apr 19 22:03:16 2A:sutcliffe last message repeated 1343 times ->Apr 19 22:03:16 2A:sutcliffe unix: subtexload ioctl: Changing page sizes NOT allowed ->Apr 19 22:03:17 2A:sutcliffe last message repeated 36 times -> ->I'm a little puzzled by this because I don't call 'subtexload' anywhere in ->my code - although I *do* call fbsubtexload once per frame. My program *seemed* When you do fbsubtexload, are you loading the entire texture? ->Could some IrisGL guru out there suggest what on earth "Changing page sizes NOT allowed" ->means? There doesn't appear to be any reference to it in the man pages for subtexload ->or fbsubtexload. Somewhere in your app, or in Performer on your behalf if you have asked for SUBLOAD textures or call pfSubloadTex(), a texture is being subloaded and with a different size than the very _first_ subload. The RE implmentation for subload has some very aggressive optimizations in it, one of which is that the subloading size for a texture becomes fixed after the first time that you do it. You can't reliably change the download size for that texture on future subtexloads. Performer tries to avoid this problem by letting you letting you set the pfTexLoadSize() up front before the texture is ever defined. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Mon Apr 22 16:02:12 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA27490; Mon, 22 Apr 1996 15:49:25 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA27487; Mon, 22 Apr 1996 15:49:24 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA14974; Mon, 22 Apr 96 15:49:21 -0700 Received: from us.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA17818; Mon, 22 Apr 1996 15:49:18 -0700 Received: from d-a-s.com (picard.d-a-s.com [198.240.116.34]) by us.net (8.6.5/8.6.12) with SMTP id SAA17290; Mon, 22 Apr 1996 18:37:14 -0400 X-Provider: US Net - Advanced Internet Services - info@us.net Received: by d-a-s.com (4.1/SMI-4.1) id AA06348; Mon, 22 Apr 96 18:51:06 EDT Date: Mon, 22 Apr 96 18:51:06 EDT From: sslayton@d-a-s.com (Susana B. Slayton (DAS)) Message-Id: <9604222251.AA06348@d-a-s.com> To: info-performer@sgi.sgi.com, scott@er.ht.com Subject: Re: Old monthly archives Status: O Scott, Here's what I have -- hope it helps. -- Susana Susana Slayton sslayton@d-a-s.com Dynamic Animation Systems (DAS) Inc. Burke, VA ####################### >From guest@holodeck.asd.sgi.com Sat Mar 9 14:40:05 1996 From: "Angus Dorbie" Date: Sat, 9 Mar 1996 18:32:31 +0100 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Performer Mailing List" , info-performer@sgi.sgi.com Subject: Re: Intersection questions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 2806 You can transform your intersection vectors to their position in the world by transforming vector through the matrix of the object it's attached to using pfXformVec3. If it's below more than one matrix you could transform it through each in turn (deepest first), or multiply the matrices and transform through the result. You can transform points in a geoset to the position in the world by multiplying the matrices in the nodes above together using pfPreMultMat or pfPostMultMat depending on whether your ascending or descending (both work) then using pfXformPt3 or pfFullXformPt3 depending on the information in the matrix. It would be easier for you to copy the tree of pfDCSs as pfSCSs & use pfFlatten to transform the pfGeode. You _don't_ have to do this to solve your intersection problem. I memory serves me correctly, to get the point of intersection in the scene I've used pfQueryHit to obtain the PFQHIT_POINT & PFQHIT_XFORM then transform the point through the matrix using pfXformPt3 to get the point of intersection in the scene. This worked for intersecting testing with the entire scene graph from the top node you may have to do a little more if you select only a transformed portion of the scene graph for an intersection test. Rgds, Angus. On Mar 8, 12:07pm, Performer Mailing List wrote: > Subject: Intersection questions > I have a question concerning intersections using performer. We are using > Performer in the development of a virtual reality system for design and > evaluation. The system loads parts and assemblies from Pro/E and enables > designers to evaluate and modify the designs for ergononmic considerations. We > use human models linked to tracking devices,etc and HMD's. We have to do > collision detection between the human model and the other models in the > environment. I am aware of the use of segment sets for intersection and the > use of masking and all of that. The problem I have is the fact that to use the > segments that are "attached to" dynamic objects is the fact that you need to > update the position of all of the segments. I have tried using pfNode bounding > boxes set to DYNAMIC but they seem to only give the bounding volume in a local > coordinate system. We have a very detailed scene graph that is composed of a > number of hierarchies of pfDCS's. I was wondering several things. First, what > is the common method of doing intersection testing? Secondly, am I totally off > with regards to the segment sets? And lastly, how can you get the global > position of a small piece of the scene graph, ie a pfGeode, that is very low in > the hierarchy of pfDCS's? Thank you very much for any help. > > Scott Angster > >-- End of excerpt from Performer Mailing List -- Angus Dorbie, Silicon Graphics Ltd, UK dorbie@reading.sgi.com ===== >From guest@holodeck.asd.sgi.com Fri Mar 8 16:01:23 1996 From: "Performer Mailing List" Date: Fri, 8 Mar 1996 12:07:39 -0800 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Intersection questions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 1306 I have a question concerning intersections using performer. We are using Performer in the development of a virtual reality system for design and evaluation. The system loads parts and assemblies from Pro/E and enables designers to evaluate and modify the designs for ergononmic considerations. We use human models linked to tracking devices,etc and HMD's. We have to do collision detection between the human model and the other models in the environment. I am aware of the use of segment sets for intersection and the use of masking and all of that. The problem I have is the fact that to use the segments that are "attached to" dynamic objects is the fact that you need to update the position of all of the segments. I have tried using pfNode bounding boxes set to DYNAMIC but they seem to only give the bounding volume in a local coordinate system. We have a very detailed scene graph that is composed of a number of hierarchies of pfDCS's. I was wondering several things. First, what is the common method of doing intersection testing? Secondly, am I totally off with regards to the segment sets? And lastly, how can you get the global position of a small piece of the scene graph, ie a pfGeode, that is very low in the hierarchy of pfDCS's? Thank you very much for any help. Scott Angster ===== >From guest@holodeck.asd.sgi.com Sat Feb 17 12:52:50 1996 From: "Ulrich J Lechner" Date: Sat, 17 Feb 1996 11:25:46 -0600 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Intersection Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 1097 Hi Performers! I would like to intersect my scene (on PFTRAV_IS_GEODE or PFTRAV_IS_GSET level) with a simple cylinder or a box. What is the standard way to do this? I tried to use a pfSegSet without any lines, a bounding cylinder and a discriminator function (see pguide 186) Result: My disc function is never called. I guess it is because of a missing line segment. Did I do something wrong or is there another way to test any object against a node. Do I have to use pfSphereContainsSphere to test against every bounding volume for every node? Uli > pfNodeTravMask(root, PFTRAV_ISECT, 1, PFTRAV_SELF, PF_SET); ..... > pfSetVec3(cylinder.center, 0, 0, 0); > pfSetVec3(cylinder.axis, 0, 0, 1); > cylinder.halfLength=100; > cylinder.radius=100; > segset.activeMask = 1; (or 0) > segset.isectMask = 0xFFFF; > segset.discFunc = disc; > segset.bound = &cylinder; > segset.mode = PFTRAV_IS_BCYL|PFTRAV_IS_GSET|PFTRAV_IS_GEODE; ..... > isect = pfNodeIsectSegs(root, &segset, hits); > int disc(pfHit *hit) > { > printf("Intersect\n"); > return(PFTRAV_CONT | PFTRAV_IS_CLIP_END); > } ####################### > From guest@holodeck.csd.sgi.com Fri Apr 19 19:24:46 1996 > From: scott@er.ht.com (Scott McMillan) > Subject: Old monthly archives > To: info-performer@sgi.sgi.com > Date: Fri, 19 Apr 1996 18:12:37 -0400 (EDT) > X-Mailer: ELM [version 2.4 PL22] > Content-Type> : > text> > Content-Length: 378 > > I need to get at some postings about intersection testing that > happened in Feb and March. Does anybody store these up? If not, any > idea when they will appear at sgigate.sgi.com. > > scott > > -- > Scott McMillan / scott@ht.com / (301)984-3706 x250 / FAX (301)984-2104 > High Techsplanations Inc. > 6001 Montrose Road, Suite 902 / Rockville, MD 20852-4874 > > From guest Mon Apr 22 17:40:53 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA27852; Mon, 22 Apr 1996 17:30:19 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA27849; Mon, 22 Apr 1996 17:30:19 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA21847; Mon, 22 Apr 96 17:30:17 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA03621; Mon, 22 Apr 1996 17:30:14 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id BAA28861; Tue, 23 Apr 1996 01:29:52 +0100 From: "Angus Dorbie" Message-Id: <9604230129.ZM28859@bitch.reading.sgi.com> Date: Tue, 23 Apr 1996 01:29:52 +0100 In-Reply-To: "Uli Lechner" "Texture-Problem" (Apr 22, 1:39pm) References: <9604221339.ZM10801@denali.icemt.iastate.edu> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Uli Lechner" , info-performer@sgi.sgi.com Subject: Re: Texture-Problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Sounds like you may have a hardware problem with your RMs. On Apr 22, 1:39pm, Uli Lechner wrote: > Subject: Texture-Problem > Hi! > > In order to get rid of a strange Moire effect that I had > with my flt database using Performer 2.0.1 (ogl) I forced > PFTEX_MIPMAP_TRILINEAR for my textures via > pfTexFilter(tex, PFTEX_MINFILTER, PFTEX_MIPMAP_TRILINEAR); > > This takes care of the Moire effect but now I have vertical lines > on my screen at a specific distance. > This happens on an RE2 with 2RM5 but not on our RE2 with 2RM4. > > Any ideas? > > Uli > :-) > >-- End of excerpt from Uli Lechner From guest Mon Apr 22 20:38:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id UAA28243; Mon, 22 Apr 1996 20:26:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id UAA28240; Mon, 22 Apr 1996 20:26:09 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA29812; Mon, 22 Apr 96 20:26:08 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id UAA20589; Mon, 22 Apr 1996 20:26:02 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id NAA20629 (8.7.5/IDA-1.6); Tue, 23 Apr 1996 13:25:12 +1000 (EST) Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA23629 (5.65c/IDA-1.5); Tue, 23 Apr 1996 12:50:30 +1000 Received: from murad (murad [8.0.0.108]) by aggro with SMTP id MAA21976 (8.6.12/IDA-1.6); Tue, 23 Apr 1996 12:53:02 +1000 From: Simon Bennett Received: by murad (5.65) id AA06742; Tue, 23 Apr 1996 12:53:27 +1000 Message-Id: <9604230253.AA06742@murad> Subject: Re: Texture-Problem To: uli@icemt.iastate.edu (Uli Lechner) Date: Tue, 23 Apr 1996 12:53:27 +1000 (EST) Cc: info-performer@sgi.sgi.com In-Reply-To: <9604221339.ZM10801@denali.icemt.iastate.edu> from "Uli Lechner" at Apr 22, 96 01:39:57 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Status: O > Hi! > > In order to get rid of a strange Moire effect that I had > with my flt database using Performer 2.0.1 (ogl) I forced > PFTEX_MIPMAP_TRILINEAR for my textures via > pfTexFilter(tex, PFTEX_MINFILTER, PFTEX_MIPMAP_TRILINEAR); > > This takes care of the Moire effect but now I have vertical lines > on my screen at a specific distance. > This happens on an RE2 with 2RM5 but not on our RE2 with 2RM4. > Any ideas? Errrk! Last time we had vertical lines all over everything it turned out to be a faulty RM board! (On the bright side it was easy to fix --- eventually!) +----------------------------------------------------------------------------+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 9981 0611 (x512) Common Sense doesn't seem to be From guest Mon Apr 22 22:35:10 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id WAA28544; Mon, 22 Apr 1996 22:20:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id WAA28541; Mon, 22 Apr 1996 22:20:17 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA02331; Mon, 22 Apr 96 22:20:16 -0700 Received: from mail.swip.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA28305; Mon, 22 Apr 1996 22:20:14 -0700 Received: from profs1.prosolvia.se by mail.swip.net (8.6.8/3.01) id HAA23140; Tue, 23 Apr 1996 07:20:55 +0200 Received: from gatekeeper.prosolvia.se (gatekeeper.prosolvia.se [193.12.108.252]) by profs1.prosolvia.se (950413.SGI.8.6.12/8.6.11) with ESMTP id HAA21670 for ; Tue, 23 Apr 1996 07:18:56 +0200 Received: from johan.prosolvia.se (pc19.prosolvia.se [193.13.244.51]) by gatekeeper.prosolvia.se (940816.SGI.8.6.9/8.6.11) with SMTP id HAA26300 for ; Tue, 23 Apr 1996 07:18:55 +0200 Message-Id: <199604230518.HAA26300@gatekeeper.prosolvia.se> Date: Tue, 23 Apr 96 07:19:52 0200 From: Johan Isaksson Mime-Version: 1.0 To: info-performer@sgi.sgi.com Subject: Unsubscribe Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Status: O Unsubscribe me please. Thanks. Johan Isaksson ------------------------------------ Prosolvia Clarus AB G=E5rdav=E4gen 1 S-412 50 G=F6teborg Sweden Tel: +46 (0)31 703 5118 Fax: +46 (0)31 703 5120 Email: johan@clarus.se Web: http://www.prosolvia.se, http://www.clarus.s= e From guest Mon Apr 22 23:49:49 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA28749; Mon, 22 Apr 1996 23:38:29 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA28746; Mon, 22 Apr 1996 23:38:28 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA04664; Mon, 22 Apr 96 23:38:27 -0700 Received: from soback.kornet.nm.kr by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id XAA03585; Mon, 22 Apr 1996 23:37:46 -0700 Received: (from sbs01316@localhost) by soback.kornet.nm.kr (8.6.12+hangul/8.6.9) id PAA18665 for info-performer@sgi.com; Tue, 23 Apr 1996 15:41:31 +0900 Date: Tue, 23 Apr 1996 15:41:31 +0900 From: HyukKee Yun (kornet) Message-Id: <199604230641.PAA18665@soback.kornet.nm.kr> To: info-performer@sgi.sgi.com Subject: Unsubscribe Content-Type: text Content-Length: 23 Status: O Unsubscribe me Please. From guest Tue Apr 23 03:44:54 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id DAA29060; Tue, 23 Apr 1996 03:31:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id DAA29057; Tue, 23 Apr 1996 03:31:53 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA10547; Tue, 23 Apr 96 03:31:51 -0700 Received: from flipper.pvv.unit.no by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id DAA18211; Tue, 23 Apr 1996 03:31:46 -0700 Received: from datter.pvv.unit.no (20118@datter.pvv.unit.no [129.241.210.204]) by flipper.pvv.unit.no (8.6.12/8.6.12) with SMTP id MAA23862 for ; Tue, 23 Apr 1996 12:31:42 +0200 Received: by datter.pvv.unit.no ; Tue, 23 Apr 1996 12:31:35 +0200 Date: Tue, 23 Apr 1996 12:31:32 +0200 (MET DST) From: Morten Eriksen To: info-performer@sgi.sgi.com Subject: Re: Mousebutton interrupts? In-Reply-To: <9604221132.ZM6815@lee.electrogig.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Mon, 22 Apr 1996, AnitaKishore wrote: > On Apr 22, 6:50pm, Morten Eriksen wrote: > > Subject: Mousebutton interrupts? > > Hi, > > > > I just wanted to hear if anyone on the list have some code (or ideas) > > on how to set up an interrupt catching mousebutton presses in a > > Performer application? > > > > I need an interrupt routine because polling won't be fast enough if > > the frame rate drops a bit (I've got a small handweapon connected to > > one of the mousebuttons for detecting trigging of shots, and the > > "button down" period of the gun is rather short). > > > > Regards, > > Morten > >-- End of excerpt from Morten Eriksen > > > > Attached below is a sample program in c++ for catching mouse events using > performer utilities functions. Since this is based on X, I think it > will be interrupt driven and not poll based. Hope this helps. > > -anita Thanks for the source. There's two problems though; I'm using a GL window instead of an X window, and I'm using Performer 1.2, not 2.0. I guess I could change the input type from GL to X fairly easy, but I wonder what the equivalent of the following code would be under 1.2: [SNIP] > #include [SNIP] > pfuEventHandlerFuncType eventHandler(int, void *, pfuCustomEvent *); [SNIP] > pfuInitInput(pw, PFUINPUT_X); > pfuInputHandler(eventHandler, ButtonPressMask); [SNIP] > pfuEventHandlerFuncType eventHandler(int dev, void *val, > pfuCustomEvent *pfuevent) > { > > XEvent *event = (XEvent *) val; > > if (event->type == ButtonPress) > { > printf("Hello, World!\n"); > if (event->xbutton.button == Button1) > { > printf("Button1 pressed\n"); > getSharedData(); > } > else if (event->xbutton.button == Button2) > printf("Button2 pressed\n"); > else if (event->xbutton.button == Button3) > printf("Button3 pressed\n"); > } > } [SNIP] ..as some of the data types, some of the functions and the include file does not exist in 1.2. I did also try to simply use the GL 'qdevice' call with 'RIGHTMOUSE' as parameter, and then to check for right mousebutton presses in perfly's processKeybdInput(), but to no avail. Any further help would be greatly appreciated. (And just to clearify my first mail a bit: the purpose of doing this is to be able to catch _all_ individual mousebutton presses with a high level of accuracy (polling is not good enough) - even several mousebutton clicks during the same frame, if possible). Regards, Morten Eriksen From guest Tue Apr 23 05:05:36 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id EAA29149; Tue, 23 Apr 1996 04:18:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id EAA29146; Tue, 23 Apr 1996 04:18:31 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA11177; Tue, 23 Apr 96 04:18:22 -0700 Received: from artcom.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id EAA20398; Tue, 23 Apr 1996 04:17:22 -0700 Received: from hertie by artcom.de with smtp id m0uBg1Q-0000PpC; Tue, 23 Apr 96 13:12 MET DST Sender: crux@artcom.de Message-Id: <317CB8C1.167E@artcom.de> Date: Tue, 23 Apr 1996 13:02:25 +0200 From: Dirk Luesebrink Organization: D-FACTS bv X-Mailer: Mozilla 3.0b2 (X11; I; IRIX 5.3 IP19) Mime-Version: 1.0 To: info-performer@sgi.sgi.com Subject: pfHit/isect/pick: confused by manuals/example Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O confusion with the pfHit datastructure used for picking/intertsection. i wrote to document it for myself and to deconfuse me just be getting it out of my head onto paper/elektrons. I hope its of some use to other. LOCATION: $PFHOME/usr/share/catman/p_man/cat3/Performer_libpf_c++/pfChannel.z i found the declaration for picking in a channel. this is the same like at some other places(eg: Intersection): int pfChannel::pick( int mode, float px, float py, float radius, pfHit **picklist[] ); what im interested in is the pfHit datastructure defining my Hit. because we can have more then one Hit we need an array. as doctumented ::pick will return a pointer to an INTERNAL list of pfHits. LOCATION: $PFHOME/usr/include/Performer/pf/pfIsector.h --- class _pfIsector : public pfTraverser { PFINTERNAL: _pfIsector(); PFINTERNAL: ... pfHit *hits[32]; // array of pointers to hits ... --- this is the declaration where I found the datastructure I get a handle to. In the examples: LOCATION: $PFHOME/usr/share/Performer/src/pguide/libpf/C++/intersect.C --- pfHit **hits[32]; isect = root->isect(&segset, hits); if (isect) { pfVec3 pnt, xpnt; pfMatrix xmat; (*hits[0])->query(PFQHIT_POINT, pnt.vec); ... --- which works ! BUT its plain wrong ! /* hits here */ pfHit** hits[32]; // is identical(a least to some degree) to pfHit*** hits; // isect will contain the number of hits. this example(and most of what i found) is dereferencing always hits[0] for query. when isect > 1 and the application dereferences hits[i > 0] it coredumps. as manuals say we get a pointer to an INTERNAL list os hits. pfHit *hits[32]; // in $PFHOME/usr/include/Performer/pf/pfIsector.h pfChannel::pick( ... ) has to have a place where to store this pointer to an array of pointer to pfHit structures. pfChannel::pick( ... ) is writting exacly one pointer(4 bytes) to the address given as the last parameter. so the last parameter in this call is a: pfHit*** hits; and pfHit **hits[32]; // is such a pointer but this is an array of 32 pointer to pointer to pfHits. and in the very first entry hits[0] will stand the result of the ::pick call. address hit[i > 0] will not be touched by the ::pick(...) call in the implementation of ::pick(...) must ne something like: LOCATION: $SILICON_GRAPHICS: location unkown :-) --- int pfChannel::pick( int mode, float px, float py, float radius, pfHit **picklist[] ) { ... *picklist = _pfIsector::hits; ... } --- which tempted me to implement the following: LOCATION: $DIRK_LUESEBRINK: D-FACTS bv :e-mail crux@artcom.de --- pfHit** hits; long picks = chan->pick(mode, px, py, radius, &hits); for(int i = 0; i < picks ; i++) { pfHit* hit = hits[i]; ... } --- which works well and let me loop over the collection of hits i have. (it saves me 31 * 4 bytes on the stack( hits[1..31]) :-) Dirk Luesebrink 'having serious fun with sirius boards' From guest Tue Apr 23 06:04:47 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA29299; Tue, 23 Apr 1996 05:27:02 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA29296; Tue, 23 Apr 1996 05:27:01 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA12139; Tue, 23 Apr 96 05:26:52 -0700 Received: from mailhost.tue.nl by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA23885; Tue, 23 Apr 1996 05:26:45 -0700 Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.7.4) for id OAA03610 (ESMTP). Tue, 23 Apr 1996 14:26:01 +0200 (MET DST) Received: from rcion@localhost by asterix.urc.tue.nl (8.7.4) for info-performer@sgi.sgi.com id OAA12615. Tue, 23 Apr 1996 14:26:00 +0200 (MDT) From: Ion Barosan Message-Id: <199604231226.OAA12615@asterix.urc.tue.nl> Subject: 3DS-FORMAT To: info-performer@sgi.sgi.com Date: Tue, 23 Apr 1996 14:25:58 +0200 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: O Hi, I would like to load the 3DS file (also with animation) in a Performer application. The 3DS loader, that comes with Performer2.0, can read only 3DS-models (?????) but not also the animation of the camera. Is there a way to get the 3DS file specification ? Thanks, -Ion. From guest Tue Apr 23 06:18:46 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA29373; Tue, 23 Apr 1996 05:42:01 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA29370; Tue, 23 Apr 1996 05:42:01 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA12394; Tue, 23 Apr 96 05:41:43 -0700 Received: from motown.detroit.sgi.com by sgihub.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for id FAA02194; Tue, 23 Apr 1996 05:41:42 -0700 Received: by motown.detroit.sgi.com (950413.SGI.8.6.12/930416.SGI) for info-performer@sgi.com id IAA00145; Tue, 23 Apr 1996 08:32:54 -0400 From: "Scott Young" Message-Id: <9604230832.ZM143@motown.detroit.sgi.com> Date: Tue, 23 Apr 1996 08:32:54 -0400 X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgihub.corp.sgi.com Subject: Unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Unsubscribe me Please. -- < SCOTT YOUNG Systems Engineer-Silicon Graphics (810)615-2166 > From guest Tue Apr 23 07:15:51 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA29517; Tue, 23 Apr 1996 06:35:14 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA29514; Tue, 23 Apr 1996 06:35:13 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA13228; Tue, 23 Apr 96 06:35:08 -0700 Received: from suw3svr01.hisd.harris.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA27642; Tue, 23 Apr 1996 06:34:50 -0700 Received: from suw3isd02 by suw3svr01.hisd.harris.com (SMI-8.6/SMI-SVR4) id JAA26369; Tue, 23 Apr 1996 09:31:46 -0400 From: jgiordan@suw3svr01.hisd.harris.com (John Giordano) Received: by suw3isd02 (5.x) id AA05442; Tue, 23 Apr 1996 09:34:33 -0400 Date: Tue, 23 Apr 1996 09:34:33 -0400 Message-Id: <9604231334.AA05442@suw3isd02> To: info-performer@sgi.sgi.com Subject: gone X-Sun-Charset: US-ASCII Status: O unsubscribe echan@buzz.hisd.harris.com From guest Tue Apr 23 08:01:48 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA29781; Tue, 23 Apr 1996 07:31:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA29778; Tue, 23 Apr 1996 07:31:46 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA14420; Tue, 23 Apr 96 07:31:45 -0700 Received: from flipper.pvv.unit.no by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA01769; Tue, 23 Apr 1996 07:31:40 -0700 Received: from datter.pvv.unit.no (20118@datter.pvv.unit.no [129.241.210.204]) by flipper.pvv.unit.no (8.6.12/8.6.12) with SMTP id QAA27383 for ; Tue, 23 Apr 1996 16:21:37 +0200 Received: by datter.pvv.unit.no ; Tue, 23 Apr 1996 16:21:17 +0200 Date: Tue, 23 Apr 1996 16:21:14 +0200 (MET DST) From: Morten Eriksen To: info-performer@sgi.sgi.com Subject: Alpha information in lrectwrite Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I'm fiddling around with the lrectwrite() function to try to make the alpha component of the color values work correctly. No combination of zfunction(), zwritemask() and zbuffer() seems to work for me, so my question is how should I set the state of GL to make the alpha component work? And how is the alpha component connected to the level of transparency (is 0x00 or 0xff complete transparency?)? What I want to do is basically have a cursor drawn, over the 3D graphics, in PostDraw() with some completely transparent areas. Regards, Morten Eriksen From guest Tue Apr 23 09:02:14 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA00270; Tue, 23 Apr 1996 08:48:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA00267; Tue, 23 Apr 1996 08:48:35 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA16613; Tue, 23 Apr 96 08:48:33 -0700 Received: from jeeves.icemt.iastate.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id IAA08794; Tue, 23 Apr 1996 08:48:32 -0700 Received: from kix.icemt.iastate.edu (kix.icemt.iastate.edu [129.186.232.38]) by jeeves.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) with ESMTP id KAA11469; Tue, 23 Apr 1996 10:48:30 -0500 Received: (from uli@localhost) by kix.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) id KAA24367; Tue, 23 Apr 1996 10:48:30 -0500 From: "Uli Lechner" Message-Id: <9604231048.ZM24365@kix.icemt.iastate.edu> Date: Tue, 23 Apr 1996 10:48:30 -0500 In-Reply-To: "Angus Dorbie" "Re: Texture-Problem" (Apr 23, 1:29am) References: <9604221339.ZM10801@denali.icemt.iastate.edu> <9604230129.ZM28859@bitch.reading.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Angus Dorbie" Subject: Re: Texture-Problem Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi! I'm afraid you are right that we have a hardware problem here since I see the same stripes viewing my database in modelgen; The stripes occur only in the viewing window and not all over the screen. (By the way not all of our textures are square. We saw the problem using IRIX6.2beta and IRIX6.2.) Uli From guest Tue Apr 23 09:06:27 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA00282; Tue, 23 Apr 1996 08:51:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA00279; Tue, 23 Apr 1996 08:51:53 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA16781; Tue, 23 Apr 96 08:51:51 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA09121; Tue, 23 Apr 1996 08:51:46 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id QAA29637; Tue, 23 Apr 1996 16:50:04 +0100 From: "Angus Dorbie" Message-Id: <9604231650.ZM29635@bitch.reading.sgi.com> Date: Tue, 23 Apr 1996 16:50:03 +0100 In-Reply-To: Morten Eriksen "Alpha information in lrectwrite" (Apr 23, 4:21pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Morten Eriksen , info-performer@sgi.sgi.com Subject: Re: Alpha information in lrectwrite Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 23, 4:21pm, Morten Eriksen wrote: > Subject: Alpha information in lrectwrite > I'm fiddling around with the lrectwrite() function to try to make the > alpha component of the color values work correctly. No combination of > zfunction(), zwritemask() and zbuffer() seems to work for me, so my > question is how should I set the state of GL to make the alpha > component work? blendfunction is what you need. > And how is the alpha component connected to the level > of transparency (is 0x00 or 0xff complete transparency?)? > Depends on your blendfunction parameters. Usually 0x00 is transparent & blendfunction (BF_SA, BF_MSA) is used. This would reverse if you switched the blendfunction arguments. You have lots of flexibility to do lots of things with your blendfunction. > What I want to do is basically have a cursor drawn, over the 3D > graphics, in PostDraw() with some completely transparent areas. > > Regards, > Morten Eriksen > >-- End of excerpt from Morten Eriksen -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Tue Apr 23 10:04:51 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA00638; Tue, 23 Apr 1996 09:54:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA00635; Tue, 23 Apr 1996 09:54:17 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA20216; Tue, 23 Apr 96 09:54:15 -0700 Received: from central.cis.upenn.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA20491; Tue, 23 Apr 1996 09:54:08 -0700 Received: from grip.cis.upenn.edu (GRIP.CIS.UPENN.EDU [158.130.10.2]) by central.cis.upenn.edu (8.6.12/UPenn 1.4) with SMTP id MAA06169 for ; Tue, 23 Apr 1996 12:54:06 -0400 Received: from LOCALHOST by grip.cis.upenn.edu id AA04563; Tue, 23 Apr 96 12:54:06 EDT Posted-Date: Tue, 23 Apr 1996 12:54:05 EDT Message-Id: <9604231654.AA04563@grip.cis.upenn.edu> To: info-performer@sgi.sgi.com Subject: meshes and culling Date: Tue, 23 Apr 1996 12:54:05 EDT From: Jean-Marc Vezien Status: O I have a question concering the culling process, or more precisely how I can use it to my own goals: I create and render several pfGeode's which are triangle meshes. I wan't to display them and test things like intersections, visibility, etc. I can do that in software, but I was wondering if one can extract information (eg. their id and to which pfGeode they belong) from the triangles that have been determined visible through the culling process. Thanks for any info, Jean-Marc. From guest Tue Apr 23 10:44:16 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA00827; Tue, 23 Apr 1996 10:31:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA00822; Tue, 23 Apr 1996 10:31:19 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA22494; Tue, 23 Apr 96 10:31:18 -0700 Received: from relay.infobyte.it by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA27231; Tue, 23 Apr 1996 10:27:59 -0700 Received: from marco.infobyte.it by relay.infobyte.it via ESMTP (940816.SGI.8.6.9/940406.SGI) for <@relay.infobyte.it:info-performer@sgi.com> id TAA26464; Tue, 23 Apr 1996 19:26:50 -0100 Received: by marco.infobyte.it (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id TAA01964; Tue, 23 Apr 1996 19:25:33 -0100 From: "Marco Tartaglia" Message-Id: <9604231925.ZM1962@marco.infobyte.it> Date: Tue, 23 Apr 1996 19:25:32 +0000 X-Face: %uBtZt;(b5oh@P}@PgP*rG+TNcP`MK6Z4Z,W>]L$.O]$."Cc@l2s2Yc)hW5%o|X=-p_.\1{ =g=3Az?3o9m!'fEy+X!i Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA01398; Tue, 23 Apr 1996 12:07:11 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA28282; Tue, 23 Apr 96 12:06:50 -0700 Received: from mailhost.tue.nl by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA15600; Tue, 23 Apr 1996 12:06:41 -0700 Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.7.4) for id PAA06044 (ESMTP). Tue, 23 Apr 1996 15:22:54 +0200 (MET DST) Received: from rcion@localhost by asterix.urc.tue.nl (8.7.4) for info-performer@sgi.sgi.com id PAA19492. Tue, 23 Apr 1996 15:22:53 +0200 (MDT) From: Ion Barosan Message-Id: <199604231322.PAA19492@asterix.urc.tue.nl> Subject: 3DS To: info-performer@sgi.sgi.com Date: Tue, 23 Apr 1996 15:22:52 +0200 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: O HI, The file "3dsftk.h" (/usr/share/Performer/src/lib/libpfdb/libpf3ds/3dsftk) contains a lot of information about the 3DS file structure and a lot of functions. It seems that the animation also is handled. Are those functions described in "3dsftk.h" used by the loader ? Could they be used as an interface to the 3DS file structure ? Best Regards, -Ion. From guest Tue Apr 23 17:36:27 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA02237; Tue, 23 Apr 1996 17:30:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA02234; Tue, 23 Apr 1996 17:30:16 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA16853; Tue, 23 Apr 96 17:30:14 -0700 Received: from jeeves.icemt.iastate.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA26319; Tue, 23 Apr 1996 17:30:08 -0700 Received: from helser75.res.iastate.edu (helser75.res.iastate.edu [129.186.76.75]) by jeeves.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) with SMTP id TAA23496 for ; Tue, 23 Apr 1996 19:30:06 -0500 Received: by helser75.res.iastate.edu with Microsoft Mail id <01BB314B.44AE4340@helser75.res.iastate.edu>; Tue, 23 Apr 1996 19:30:02 -0500 Message-Id: <01BB314B.44AE4340@helser75.res.iastate.edu> From: Allen Bierbaum To: "'Performer List'" Date: Tue, 23 Apr 1996 19:29:53 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Status: O Performers, For input processing in my current program, I hacked the input code = from /usr/share/Performer/src/pguide/C++/detail.C. I only use the input = processing from here. In other words, I use pfuMouse and pfuEventStream = to do auto input for a variety of Xformers. I needed the ability to = switch between fly, drive, and trackball modes. This was the only = program example that I found to do all this. My program (and detail.C) work fine as long as I compile -32, but if I = try -N32 or -64, I have problems. They compile correctly, but when the = view comes up, it is as if they receive no input data. I traced the = programs through a debugger, and it seems as if the draw loop is doing = it's thing fine. The program just doesn't accept any input. I next = tried to compile some other program samples included with Performer to = see if they allowed input compiled in this way. I compiled the programs = in the libpfui directory. They work fine, but they don't use the same = method for input. In fact they seem to use a much more difficult and = cumbersome way to handle input and xformers. =20 My question is, have I just run across a known limitation in the event = processing code, or is there an error in the detail.C program sample???=20 I was unable to find any more samples that do input in this way, so I = could not check the code for correctness. I really need to be able to = compile N32 or 64 because I would like to use STL in some of my current = code. It seems that the N32 and 64 bit SGI compilers only support the = more advanced features of C++ needed. Can anyone help me??? -Allen allenb@iastate.edu ISU CAVE++ RA - Dr. Carolina Cruz-Neira From guest Tue Apr 23 18:23:12 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA02483; Tue, 23 Apr 1996 18:17:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA02480; Tue, 23 Apr 1996 18:17:09 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA19813; Tue, 23 Apr 96 18:17:07 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id SAA03430; Tue, 23 Apr 1996 18:17:06 -0700 Received: from hell.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA19786; Tue, 23 Apr 96 18:17:03 -0700 Received: by hell.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id SAA11841; Tue, 23 Apr 1996 18:17:01 -0700 From: "Don Hatch" Message-Id: <9604231817.ZM11839@hell.asd.sgi.com> Date: Tue, 23 Apr 1996 18:17:01 -0700 In-Reply-To: Allen Bierbaum "" (Apr 23, 7:29pm) References: <01BB314B.44AE4340@helser75.res.iastate.edu> X-Face: /7QDEc=iPrsQG=j>iQo4F||T'ys-t--1bb9IJ9qo~4|i0nB|OG%gK}I3J2{/u*-q.I8=OSv/&K}V(pw:~5aIV!Y4:y+Vk#AAX)|i'B-jHf+r(?U'"B'9"D|<-(/1PD32tUN X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Allen Bierbaum , "'Performer List'" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 23, 7:29pm, Allen Bierbaum wrote: > Subject: > > [ plain text > Encoded with "quoted-printable" ] : Performers, > For input processing in my current program, I hacked the input code from /usr/share/Performer/src/pguide/C++/detail.C. I only use the input processing from here. In other words, I use pfuMouse and pfuEventStream to do auto input for a variety of Xformers. I needed the ability to switch between fly, drive, and trackball modes. This was the only program example that I found to do all this. > > My program (and detail.C) work fine as long as I compile -32, but if I try -N32 or -64, I have problems. They compile correctly, but when the view comes up, it is as if they receive no input data. I traced the programs through a debugger, and it seems as if the draw loop is doing it's thing fine. The program just doesn't accept any input. I next tried to compile some other program samples included with Performer to see if they allowed input compiled in this way. I compiled the programs in the libpfui directory. They work fine, but they don't use the same method for input. In fact they seem to use a much more difficult and cumbersome way to handle input and xformers. > > My question is, have I just run across a known limitation in the event processing code, or is there an error in the detail.C program sample??? > > I was unable to find any more samples that do input in this way, so I could not check the code for correctness. I really need to be able to compile N32 or 64 because I would like to use STL in some of my current code. It seems that the N32 and 64 bit SGI compilers only support the more advanced features of C++ needed. > > Can anyone help me??? This is a bug in libpfutil's input handling that only manifests in N32 and N64, and will be fixed in Performer 2.1 and future patches. You can fix it yourself by changing and recompiling libpfutil; here is the relevant portion of the Performer 2.1 release notes: | Intermittent loss of input: | This was a bug in pfu input handling. The return value of XPeekEvent() | in IRIX 6.2 is random data. The workaround is in Performer 2.1, but | existing Performer 2.0 and Performer 2.0.1 customers can resolve this | by changing the IRIS Performer utility library source code for | input.c to make the main loop as follows: | | while (!DeviceInput->exit) | { | if (!DeviceInput->inited) | openXInput(p); | | if (DeviceInput->inited) | { | /* does not return a value */ | XPeekEvent(theDisplay, &event); | | collectXInput(); | } | } Don -- Don Hatch hatch@sgi.com (415) 933-5150 Silicon Graphics, Inc. From guest Tue Apr 23 18:50:17 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA02637; Tue, 23 Apr 1996 18:44:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA02634; Tue, 23 Apr 1996 18:44:26 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA20911; Tue, 23 Apr 96 18:44:25 -0700 Received: from nypinet.nyp.ac.sg by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id SAA06727; Tue, 23 Apr 1996 18:44:03 -0700 Received: from mgate.nyp.ac.sg. (mgate.nyp.ac.sg [202.12.95.26]) by nypinet.nyp.ac.sg (8.7.1/8.7.1) with SMTP id JAA10797; Wed, 24 Apr 1996 09:42:41 +0700 (SST) Received: by mgate.nyp.ac.sg. with Microsoft Mail id <317E5990@mgate.nyp.ac.sg.>; Wed, 24 Apr 96 09:40:48 PDT From: "Ng Kian Bee, SIT/CS" To: Angus , performer Subject: URGENT: Looking for VR company near bay area California Date: Wed, 24 Apr 96 09:23:00 PDT Message-Id: <317E5990@mgate.nyp.ac.sg.> Encoding: 20 TEXT X-Mailer: Microsoft Mail V3.0 Status: O Hi, I'm posting this on behalf of my colleage. He needs this help urgently. Could someone help. He needs to know if there are any company famous in doing VR work at the bay area of California. (I hope I got him right!) As long as companies doing VR work at that area he would like very much to get their contacts, addresses etc. Anyone knows? Please reply me at my email address. ngkb@nyp.ac.sg Millions thanx! Rgds. Kian ngkb@nyp.ac.sg From guest Tue Apr 23 23:08:37 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA03117; Tue, 23 Apr 1996 23:03:14 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA03114; Tue, 23 Apr 1996 23:03:13 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA27352; Tue, 23 Apr 96 23:03:12 -0700 Received: from mcenroe.cs.unc.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id XAA27845; Tue, 23 Apr 1996 23:03:08 -0700 Received: from orville.cs.unc.edu by mcenroe.cs.unc.edu (8.6.10/UNC_06_21_94) id CAA15994; Wed, 24 Apr 1996 02:03:06 -0400 From: Daniel Aliaga Received: by orville.cs.unc.edu (8.6.10/UNC_06_21_94) id CAA19859; Wed, 24 Apr 1996 02:03:00 -0400 Message-Id: <199604240603.CAA19859@orville.cs.unc.edu> Subject: pfMorph To: info-performer@sgi.sgi.com Date: Wed, 24 Apr 1996 02:02:59 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 828 Status: O This might be a long shot, but has anyone experienced apparent problems with pfMorph node in multiprocess mode. Specifically, I am defining the pfMorphAttr's in the CULL phase and later specifying the pfMorphWeights and calling pfEvaluateMorph node, all also the CULL phase. The manual seems to imply usually evaluating the pfMorph node in the APP phase, but I need to do it in the CULL phase. Are there any fundamental problems with this? I suppose the pfCycleBuffers which are used automagically by pfMorph will act correctly? Any comments appreciated... -Daniel. -- Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id AAA03379; Wed, 24 Apr 1996 00:51:30 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id AAA24753; Wed, 24 Apr 1996 00:51:29 -0700 Received: from cony.gsf.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id AAA05755; Wed, 24 Apr 1996 00:51:24 -0700 Received: from lulu.gsf.de by cony.gsf.de (8.6.4.2/Arcane-3.41) id JAA21037; Wed, 24 Apr 1996 09:49:33 +0200 Received: by lulu.gsf.de (950911.SGI.8.6.12.PATCH825/940406.SGI) for info-performer@sgi.com id JAA22618; Wed, 24 Apr 1996 09:50:37 +0200 From: "Wolfgang Baudler" Message-Id: <9604240950.ZM22616@lulu.gsf.de> Date: Wed, 24 Apr 1996 09:50:36 -0600 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Integrating Input-Devices into Performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hello, I would like to use some different input-devices (Data-Glove, Tracking System etc.; we wrote device-drivers already) and I wonder how to integrate this devices into Performer 2.0 so I get new functions like the Performer Xformer functions pfiNewTDFXformer and pfiSelectXformerModel. I think I have to use C++ in order to achieve this in a good way. Does anybody know, where I can find source-code examples which could help me in doing this? How else is using non-standard-devices with Performer? Thank you. Bye Wolfgang -- ------------------------------------------------------- Wolfgang Baudler GSF/MEDIS - Forschungszentrum fuer Umwelt u. Gesundheit Ingolstaedter Landstr. 1, 85764 Oberschleissheim Neuherberg / Munich - Germany email: baudler@gsf.de Tel.: +49 (0) 89/3187-4463 Fax.: +49 (0) 89/3187-3326 ------------------------------------------------------- From guest Wed Apr 24 04:03:41 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id DAA03707; Wed, 24 Apr 1996 03:57:39 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id DAA03704; Wed, 24 Apr 1996 03:57:35 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA29705; Wed, 24 Apr 1996 03:57:34 -0700 Received: from ldsa.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA16548; Wed, 24 Apr 1996 03:57:32 -0700 From: dheskamp@ldsa.com Received: from ldsa.com (dgate) by ldsa.com (5.x/SMI-SVR4) id AA22077; Wed, 24 Apr 1996 06:53:01 -0400 Received: from ldsa (sun294) by ldsa.com (5.x/SMI-SVR4) id AA23776; Wed, 24 Apr 1996 06:57:47 -0400 Received: from pc1197.ldsa by ldsa (5.x/SMI-SVR4) id AA17496; Wed, 24 Apr 1996 06:57:44 -0400 To: info-performer@sgi.sgi.com Subject: intersection processing thread Date: Wed, 24 Apr 96 06:58:45 EDT Message-Id: <9604241058.2D3A1C@pc1197.ldsa> X-Mailer: SelectMAIL 1.2 Status: O Hello: Does anyone know where to find an example that uses intersection testing in a separate process? Dave Heskamp Lockheed Martin Tactical Defense Systems 1210 Massillon Road Akron, Ohio 44315-0001 phone: (330) 796 - 5383 fax: (330) 796 - 7009 email: dheskamp@ldsa.com From guest Wed Apr 24 04:07:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id EAA03716; Wed, 24 Apr 1996 04:02:34 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id EAA03713; Wed, 24 Apr 1996 04:02:34 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA00306; Wed, 24 Apr 1996 04:02:33 -0700 Received: from mandator.se by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id EAA16973; Wed, 24 Apr 1996 04:02:26 -0700 Received: by mandator.se (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA0413; Wed, 24 Apr 96 11:55:57 -0400 Message-Id: <9604241555.AA0413@mandator.se> Received: from Mandator with "Lotus Notes Mail Gateway for SMTP" id F0507132F650A18A802563160042594F; Wed, 24 Apr 96 11:55:52 To: info-performer From: Ulf Yngwe/COMATOR/HELSINGBORG/SE/MANDATOR AB Date: 24 Apr 96 13:07:50 Subject: Flight dynamics Mime-Version: 1.0 Content-Type: Text/Plain Status: O A couple of months ago, some of you discussed flight-dynamics using quaternions. Someone had a web-address where you could find an article about it, does anyone remember this address. I could not find it in the monthly archives. From guest Wed Apr 24 04:12:12 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id EAA03731; Wed, 24 Apr 1996 04:06:57 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id EAA03728; Wed, 24 Apr 1996 04:06:49 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA00455; Wed, 24 Apr 1996 04:06:49 -0700 Received: from relay1.oleane.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id EAA17255; Wed, 24 Apr 1996 04:06:45 -0700 Received: (from uutnt@localhost) by relay1.oleane.net (8.6.10/8.6.9) with UUCP id NAA06634 for info-performer@sgi.sgi.com; Wed, 24 Apr 1996 13:06:38 +0200 Received: from kpmvisu2 by newcube.tnt.oleane.com (NX5.67d/oleANe-Net_NeXT-2.0) id AA00369; Wed, 24 Apr 96 11:36:07 +0200 Message-Id: <9604240936.AA00369@tnt.oleane.com> Received: by kpmvisu2 (NX5.67f2/NX3.0X) id AA00457; Wed, 24 Apr 96 11:36:05 +0200 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: rouand Date: Wed, 24 Apr 96 11:36:05 +0200 To: info-performer@sgi.sgi.com Subject: subscribe me Status: O From guest Wed Apr 24 05:59:07 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA04262; Wed, 24 Apr 1996 05:53:47 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA04259; Wed, 24 Apr 1996 05:53:46 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA03229; Wed, 24 Apr 1996 05:53:45 -0700 Received: from cesit1.unifi.it by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA24409; Wed, 24 Apr 1996 05:52:23 -0700 Received: from INGFI1.ING.UNIFI.IT by CESIT1.UNIFI.IT (PMDF V5.0-4 #3688) id <01I3X9HW0NU8000RC0@CESIT1.UNIFI.IT> for info-performer@sgi.sgi.com; Wed, 24 Apr 1996 14:52:06 +0100 (MET) Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Wed, 24 Apr 1996 14:51:32 +0200 (MET-DST) Received: from smoke by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA05487; Wed, 24 Apr 1996 14:51:58 +0200 Received: by smoke (940816.SGI.8.6.9) id OAA06282; Wed, 24 Apr 1996 14:51:52 +0200 Date: Wed, 24 Apr 1996 14:51:52 -0600 From: Luz Marina Tinjaca Subject: Loader Inventor V2.1 ascii To: info-performer@sgi.sgi.com Cc: luz@aguirre.ing.unifi.it Message-id: <9604241451.ZM6280@smoke> MIME-version: 1.0 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Status: O hi , I need to load in Performer 1.2 the objects in format Inventor V2.1 ascii , but the loader that I have ,load only objects with format inventor V1.0 , anyone have a loader for this format or can say me the way to change the version ? thanks in advance, luz -- ******************************** Luz Marina Tinjaca' Universita' di Firenze Dipartimento di Sistemi e Informatica Via Santa Marta ,3 Firenze Tel : +39-55-4796365 e-mail : luz@aguirre.ing.unifi.it ********************************* From guest Wed Apr 24 06:45:57 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA04456; Wed, 24 Apr 1996 06:40:09 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA04453; Wed, 24 Apr 1996 06:40:04 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA04438; Wed, 24 Apr 1996 06:40:04 -0700 Received: from relay1.oleane.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA28808; Wed, 24 Apr 1996 06:40:01 -0700 Received: from csf2.pobox.oleane.com (csf2.pobox.oleane.com [194.2.5.17]) by relay1.oleane.net (8.6.10/8.6.9) with SMTP id PAA13629 for ; Wed, 24 Apr 1996 15:39:23 +0200 Message-Id: <199604241339.PAA13629@relay1.oleane.net> X-Sender: csf2@pobox.oleane.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Apr 1996 15:33:30 +0000 To: info-performer@sgi.sgi.com From: arnaud@pobox.oleane.com (Space Magic Team) Subject: unsuscribe X-Mailer: Status: O ____________________________________________________________________ | | /\ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= /\ | | | -(*)- <[]> arnaud@POBOX.oleane.com <[]> -(*)- | | | \/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= \/ | | |--------------------------------------------------------------------| | ______ _________ ____________ _________ ______ | | /_/_/_/\ | Space | \/\/\/\/\/\/ | Space | /\_\_\_\ | | /_/_/_/\/\ | ~~~~~~~ | \/\/\/\/\/ | ~~~~~~~ | /\/\_\_\_\ | |/_/_/_/\/\/\ | Magic | \/\/\/\/ | Basic | /\/\/\_\_\_\| |\_\_\_\/\/\/ '---------' \/\/\/ '---------' \/\/\/_/_/_/| | \_\_\_\/\/ / ######### \ \/\/ / ######### \ \/\/_/_/_/ | | \_\_\_\/ / ########### \ \/ / ########### \ \/_/_/_/ | | '---------------' '---------------' | |--------------------------------------------------------------------| | o o Thomson Training & Simulation o o | | o o Z.A. Les Boutries; 5, rue Leonardo da Vinci; B.P. 252 o o | | o o 78703 Conflans Sainte Honorine Cedex France o o | | o o Tel: [33] (1) 34903614 Fax: [33] (1) 34903602 o o | |____________________________________________________________________| From guest Wed Apr 24 06:57:32 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA04479; Wed, 24 Apr 1996 06:51:33 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA04476; Wed, 24 Apr 1996 06:51:33 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA04834; Wed, 24 Apr 1996 06:51:32 -0700 Received: from barney.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id GAA00042; Wed, 24 Apr 1996 06:51:22 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id OAA08418; Wed, 24 Apr 1996 14:51:16 +0100 From: "Rob Jenkins" Message-Id: <9604241451.ZM8416@barney.reading.sgi.com> Date: Wed, 24 Apr 1996 14:51:15 +0100 In-Reply-To: Luz Marina Tinjaca "Loader Inventor V2.1 ascii" (Apr 24, 2:51pm) References: <9604241451.ZM6280@smoke> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Luz Marina Tinjaca , info-performer@sgi.sgi.com Subject: Re: Loader Inventor V2.1 ascii Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O you can change the version of Inventor files with /usr/sbin/ivdowngrade which is installed from inventor_eoe.sw.inventor. Also you can read V1 files into gview and if you save the current scenegraph from gview to a .iv file it will be the version of Inventor you are running ( probably only works going V1->V2.x ). Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. Forum 1, Station Road, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Wed Apr 24 07:15:37 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA04588; Wed, 24 Apr 1996 07:10:18 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA04585; Wed, 24 Apr 1996 07:10:09 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA05443; Wed, 24 Apr 1996 07:10:09 -0700 Received: from octagon.tacom.army.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA02342; Wed, 24 Apr 1996 07:10:03 -0700 From: tidrowd@cc.tacom.army.mil Received: from cc.tacom.army.mil by octagon.tacom.army.mil (8.7.5/8.7.3-kbp) with SMTP id KAA08280; Wed, 24 Apr 1996 10:07:34 -0400 (EDT) Received: from ccMail by cc.tacom.army.mil (IMA Internet Exchange 1.04b) id 17e33f60; Wed, 24 Apr 96 10:00:22 -0400 Mime-Version: 1.0 Date: Wed, 24 Apr 1996 10:01:01 -0400 Message-ID: <17e33f60@cc.tacom.army.mil> To: info-performer@sgi.sgi.com, dheskamp@ldsa.com Subject: Re: intersection processing thread Content-Type: multipart/mixed; boundary="IMA.Boundary.224453038" Status: O This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.224453038 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part I second the motion! If anyone has examples, please post to the mailing list. Don Tidrow Visual Simulation Developer US Army TACOM ______________________________ Reply Separator _________________________________ Subject: intersection processing thread Author: dheskamp@ldsa.com at TWLAN-SMTP Date: 4/24/96 6:58 AM Hello: Does anyone know where to find an example that uses intersection testing in a sep arate process? Dave Heskamp Lockheed Martin Tactical Defense Systems 1210 Massillon Road Akron, Ohio 44315-0001 phone: (330) 796 - 5383 fax: (330) 796 - 7009 email: dheskamp@ldsa.com --IMA.Boundary.224453038 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Received: from octagon.tacom.army.mil by cc.tacom.army.mil with SMTP (IMA Internet Exchange 1.04b) id 17e104e0; Wed, 24 Apr 96 07:28:14 -0400 Received: from sgigate.sgi.com by octagon.tacom.army.mil (8.7.5/8.7.3-kbp) with S MTP id HAA05583; Wed, 24 Apr 1996 07:29:43 -0400 (EDT) Received: from holodeck.csd.sgi.com by sgigate.sgi.com via ESMTP (950911.SGI.8.6. 12.PATCH825/940406.SGI) id EAA22708; Wed, 24 Apr 1996 04:20:06 -0700 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id DAA03707; Wed, 24 Apr 1996 03:57:39 -0700 Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6 .12/940406.SGI.AUTO) for id DAA03704; Wed, 24 Apr 1996 03:57:35 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/91080 5.SGI) for id DAA29705; Wed, 24 Apr 1996 03:57:34 -0 700 Received: from ldsa.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA16548; Wed, 24 Apr 1996 03:57:32 -0700 From: dheskamp@ldsa.com Received: from ldsa.com (dgate) by ldsa.com (5.x/SMI-SVR4) id AA22077; Wed, 24 Apr 1996 06:53:01 -0400 Received: from ldsa (sun294) by ldsa.com (5.x/SMI-SVR4) id AA23776; Wed, 24 Apr 1996 06:57:47 -0400 Received: from pc1197.ldsa by ldsa (5.x/SMI-SVR4) id AA17496; Wed, 24 Apr 1996 06:57:44 -0400 To: info-performer@sgi.sgi.com Subject: intersection processing thread Date: Wed, 24 Apr 96 06:58:45 EDT Message-Id: <9604241058.2D3A1C@pc1197.ldsa> X-Mailer: SelectMAIL 1.2 --IMA.Boundary.224453038-- From guest Wed Apr 24 07:50:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA04870; Wed, 24 Apr 1996 07:45:25 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA04867; Wed, 24 Apr 1996 07:45:21 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA06800; Wed, 24 Apr 1996 07:45:20 -0700 Received: from elaine.crcg.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA06447; Wed, 24 Apr 1996 07:45:02 -0700 Received: from condor.crcg.edu by elaine.crcg.edu (4.1/SMI-4.1) id AA04907; Wed, 24 Apr 96 09:45:36 EST Received: by condor.crcg.edu (940816.SGI.8.6.9/SMI-4.0) id LAA24737; Thu, 25 Apr 1996 11:44:20 -0400 Date: Thu, 25 Apr 1996 11:44:19 +30000 From: Mike Macedonia X-Sender: mmacedon@condor To: Ulf Yngwe/COMATOR/HELSINGBORG/SE/MANDATOR AB Cc: info-performer Subject: Re: Flight dynamics In-Reply-To: <9604241555.AA0413@mandator.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O See pubs on: http://www-npsnet.cs.nps.navy.mil/npsnet/index.html ----------------------------------------------------------------- | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | | Vice President | EMAIL: mmacedon@crcg.edu | | Fraunhofer CRCG | | | 167 Angell Street | PH : (+1) 401 453-6363 | | Providence, RI 02906 | FAX: (+1) 401 453-0444 | ----------------------------------------------------------------- On 24 Apr 1996, Ulf Yngwe/COMATOR/HELSINGBORG/SE/MANDATOR AB wrote: > A couple of months ago, some of you discussed flight-dynamics using quaternions. > Someone had a web-address where you could find an article about it, does anyone > remember this address. I could not find it in the monthly archives. > From guest Wed Apr 24 08:57:18 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA05218; Wed, 24 Apr 1996 08:51:51 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA05215; Wed, 24 Apr 1996 08:51:50 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA09741; Wed, 24 Apr 1996 08:51:50 -0700 Received: from trident.neiddd.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA15514; Wed, 24 Apr 1996 08:51:35 -0700 Received: from ohio.neiddd.com by trident.neiddd.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for <@trident.neiddd.com:info-performer@sgi.com> id LAA11289; Wed, 24 Apr 1996 11:53:33 -0400 Received: by ohio.neiddd.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id LAA21328; Wed, 24 Apr 1996 11:53:49 -0400 From: "Ray Twiddy" Message-Id: <9604241153.ZM21326@ohio.neiddd.com> Date: Wed, 24 Apr 1996 11:53:48 -0400 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Double Precision Support in Performer? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O TO: SGI Performer developers and All who are interested in geocentric terrain models When will Performer provide access to double precision in both modeling and matrix operations similar to those in OpenGL (glRotated, glTranslated, glLoadMatrisd, glMultMatrixd, etc.)? We are developing a "real" world simulation system using a geocentric coordinate system and, therefore, require the accuracy of double precision. Currently, we are applying an offset to our terrain database in order to gain a few decimal places in floating point precision. -Ray -- Ray Twiddy | / ____/ / NEI - Nomura Enterprise Inc. rltwiddy@neiddd.com | / / / 14240-G Sullyfield Circle Bus. (703) 818-1990 / | / ___/ / Chantilly, VA 22021 FAX (703) 818-7626 / / / / ___________________________________________________ __/ __/ _____/ __/ From guest Wed Apr 24 08:57:21 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA05213; Wed, 24 Apr 1996 08:51:50 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA05210; Wed, 24 Apr 1996 08:51:49 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA09737; Wed, 24 Apr 1996 08:51:48 -0700 Received: from ldsa.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA15538; Wed, 24 Apr 1996 08:51:45 -0700 From: dheskamp@ldsa.com Received: from ldsa.com (dgate) by ldsa.com (5.x/SMI-SVR4) id AA23456; Wed, 24 Apr 1996 11:47:06 -0400 Received: from ldsa (sun294) by ldsa.com (5.x/SMI-SVR4) id AA24885; Wed, 24 Apr 1996 11:51:54 -0400 Received: from pc1197.ldsa by ldsa (5.x/SMI-SVR4) id AA27038; Wed, 24 Apr 1996 11:51:52 -0400 To: info-performer@sgi.sgi.com Subject: RE: Returned mail Date: Wed, 24 Apr 96 11:52:52 EDT Message-Id: <9604241552.344354@pc1197.ldsa> X-Mailer: SelectMAIL 1.2 Status: O Thanks to Scott O' for his code fragment. I found a more detailed code fragment in the man page for pfIsectFunc. Does anyone have a complete working example such as "intersect.C" that uses a forked intersection process? Dave Heskamp Lockheed Martin Tactical Defense Systems 1210 Massillon Road Akron, Ohio 44315-0001 phone: (330) 796 - 5383 fax: (330) 796 - 7009 email: dheskamp@ldsa.com From guest Wed Apr 24 10:10:01 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA05686; Wed, 24 Apr 1996 10:04:40 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA05683; Wed, 24 Apr 1996 10:04:39 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA14201; Wed, 24 Apr 1996 10:04:39 -0700 Received: from motown.detroit.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA28665; Wed, 24 Apr 1996 10:04:32 -0700 Received: by motown.detroit.sgi.com (950413.SGI.8.6.12/930416.SGI) for info-performer@sgi.sgi.com id NAA21125; Wed, 24 Apr 1996 13:04:30 -0400 From: "Scott Young" Message-Id: <9604241304.ZM21123@motown.detroit.sgi.com> Date: Wed, 24 Apr 1996 13:04:30 -0400 X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O unsubscribe From guest Wed Apr 24 10:44:42 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA05832; Wed, 24 Apr 1996 10:39:14 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA05829; Wed, 24 Apr 1996 10:39:05 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA16400; Wed, 24 Apr 1996 10:39:05 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA05323; Wed, 24 Apr 1996 10:38:58 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA14977; Wed, 24 Apr 96 10:38:52 -0700 Received: by babar.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA11741; Wed, 24 Apr 1996 10:38:51 -0700 Date: Wed, 24 Apr 1996 10:38:51 -0700 From: mtj@babar.asd.sgi.com (Michael T. Jones) Message-Id: <199604241738.KAA11741@babar.asd.sgi.com> To: info-performer@sgi.sgi.com, rltwiddy@ohio.neiddd.com Subject: re: Double Precision Support in Performer Status: O Ray writes: :When will Performer provide access to double precision in both :modeling and matrix operations similar to those in OpenGL (glRotated, :glTranslated, glLoadMatrisd, glMultMatrixd, etc.)? Careful here. OpenGL lets you pass double-precision values into the functions, but all implementations that I'm aware of immediately convert them to single-precision floating point before taking any further steps, such as translations, matrix stack operations, etc. To be clear, the results from using SP and DP would be exactly the same on every machine that IRIS Performer operates on, were we to support double precision. Given that, there is one argument for and one against direct Performer support for double precision. For: an application may use the geoset data for it's own purposes and need the extra precision. This is a good argument. Against: we'd get half of the effective bus bandwidth since we'd send 8-bytes rather than 4 for each vertex, and the GFX subsystem would be busy tossing out the extra bytes as it's first task. This would mean lower performance. Our choice: single-precision, lower data traffic, and greater performance until such time as the machine would really use the extra precision. :We are developing a "real" world simulation system using a geocentric :coordinate system and, therefore, require the accuracy of double precision. I'd agree with "desire", but not with "require". The reason is... :Currently, we are applying an offset to our terrain database in order to :gain a few decimal places in floating point precision. ...that this approach works well when carefully implemented. What you need are some non-performer DP values: a DP eyepoint location, a DP global origin, and, a DP local origin for each big chunk of your world. (The maximum chunksize should be limited to about 1/2 the dynamic range of SP given your chosen model coordinate system epsilon). In operation (method A): put the eye wherever you want (DP). put the global origin at the eye (DP). set the performer eye to 0,0,0. (SP is fine for this ;-) for each chunk compute chunkOffset as chunkOrigin - globalOrigin (DP) (this is the happy part ... even though the two numbers above are DP, the difference fits into a SP number nicely) set performer DCS for chunk to chunkOffset (SP) pfFrame(); Alternate method (saves one DCS, under the eye). Make sure you *really* understand method A before thinking about this. put the eye wherever you want (DP). figure out which chunk is under the eye -- the "localChunk". set the global origin to the localChunk's origin. (DP) compute eyeOffset as eyepoint - globalOrigin; (though these subtrahends are DP, their difference is representable in SP) set the performer eye to eyeOffset for each chunk compute chunkOffset as chunkOrigin - globalOrigin (DP) (this is the happy part ... even though the two numbers above are DP, the difference fits into a SP number nicely) set performer DCS for chunk to chunkOffset (SP) pfFrame(); Once it all makes sense to you, implement method B if there is much complexity in your database. The advantage of B is that there's no matrix (or just an identity matrix) in the performer scene graph above it, so that libpr geoset bounding box culling will be performed. This can be a big win in the local area when many cultural features are present and geodes contain many geosets. Someday, perhaps Performer will provide double precision values for the eyepoint and global offset in the pfChannel, and either a special pfOrigin node or a new semantic for DCS nodes to make the implementation of methods A and B automatic. Until then, the code outlined above is identical to what we'd do--just as efficient and probably better since it makes the relationships between the chunk dynamic ranges and SP/DP precisions more exposed and thus likely more widely understood. Michael "Think Globally, Offset Locally" Jones P.S. the case for DP geoset data so that CAD modelling tools, FEA programs, and such have access to the high-precision data that they need is a good one and not one that's lost on us. Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Wed Apr 24 11:17:09 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA06037; Wed, 24 Apr 1996 11:11:14 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA06034; Wed, 24 Apr 1996 11:11:09 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA18756; Wed, 24 Apr 1996 11:11:09 -0700 Received: from cirrus.redstone.army.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA11570; Wed, 24 Apr 1996 11:10:59 -0700 Received: by cirrus.redstone.army.mil (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.sgi.com id NAA17434; Wed, 24 Apr 1996 13:11:27 -0500 From: "dave" Message-Id: <9604241311.ZM17432@cirrus.redstone.army.mil> Date: Wed, 24 Apr 1996 13:11:20 -0500 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O unsubscribe -- _______ David Edgemon | Nichols Research Corp. \__________________(*)__________________/ dave@cirrus.redstone.army.mil Huntsville Soaring Club From guest Wed Apr 24 12:56:26 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA06830; Wed, 24 Apr 1996 12:50:33 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA06827; Wed, 24 Apr 1996 12:50:29 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA25026; Wed, 24 Apr 1996 12:50:28 -0700 Received: from mail.thecia.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id MAA28237; Wed, 24 Apr 1996 12:50:21 -0700 Received: (from sage@localhost) by mail.thecia.net (8.7.5/8.7.5) id PAA21133; Wed, 24 Apr 1996 15:53:52 -0400 (EDT) Date: Wed, 24 Apr 1996 15:53:52 -0400 (EDT) From: sasha eysymontt To: info-performer@sgi.sgi.com cc: info-performer-admin@sgi.sgi.com Subject: Re: unsubscribe In-Reply-To: <9604241311.ZM17432@cirrus.redstone.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O We've been seeing a lot of unsubscribe/subscribe requests to the list of late, and for very good reason. It seems that the majordomo at SGI is broken -- doesn't seem to like requests of any kind -- i've been trying to unsubscribe for about a week. Any admins @ SGI want to take a look? -sasha ------------ sasha eysymontt = sage@thecia.net webdesigner/webmaster @ complete internet access = cambridge, ma operagraphics '96 = http://www.thecia.net/cia/staff/sage From guest Wed Apr 24 13:55:25 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA07395; Wed, 24 Apr 1996 13:49:49 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA07392; Wed, 24 Apr 1996 13:49:45 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA27937; Wed, 24 Apr 1996 13:49:44 -0700 Received: from listserv.gmd.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA07989; Wed, 24 Apr 1996 13:49:13 -0700 Received: from mailer.mpib-tuebingen.mpg.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <8.B3810168@listserv.gmd.de>; Wed, 24 Apr 1996 22:49:04 +0200 Received: from bogart.mpib-tuebingen.mpg.de by mailer.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0912AM) id AA06416; Wed, 24 Apr 1996 22:17:59 +0100 Received: from squash.mpik-tueb.mpg.de by bogart.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0442PM) id AA05684; Wed, 24 Apr 1996 22:49:55 +0100 Received: by squash (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.sgi.com id WAA29152; Wed, 24 Apr 1996 22:48:51 +0200 From: "Dietrich Opitz" Message-Id: <9604242248.ZM29150@squash.mpik-tueb.mpg.de> Date: Wed, 24 Apr 1996 22:48:51 +0000 In-Reply-To: Mike Macedonia "Re: Flight dynamics" (Apr 25, 11:44am) References: X-Face: ,78BGR^:N$.'76:g~S1U^5[;4H@V1KZvxT0W&ugiSX!CO}A((fKEnL2;vdw~RdA'C}Snv2n/1pB3cZjiFbN{Q}nXx}2cd* X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Static db loaders Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, is there a way to link the loader for flt-files static under Performer 2.0 ? I want to create an all included fat binary, but i got complains like: PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "flt" PF Warning: pfdLoadFile() - Unable to load file boat.flt because of problem finding pfdLoadFile_flt Any help? Dietrich Opitz -- -- Dietrich Opitz MPI fuer biologische Kybernetik Spemannstr. 38 72076 Tuebingen GERMANY Tel: ++49(7071) 601 606 FAX: ++49(7071) 601 575 e-mail: dio@mpik-tueb.mpg.de From guest Thu Apr 25 01:32:12 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA10036; Thu, 25 Apr 1996 01:24:31 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA10029; Thu, 25 Apr 1996 01:24:21 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA23927; Thu, 25 Apr 1996 01:24:21 -0700 Received: from relay-2.mail.demon.net by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id BAA10070; Thu, 25 Apr 1996 01:24:19 -0700 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ab22468; 25 Apr 96 9:24 +0100 Received: from marklynn.demon.co.uk ([158.152.142.157]) by relay-3.mail.demon.net id aa18401; 25 Apr 96 9:22 +0100 From: Mark Baranowski To: Dietrich Opitz Cc: info-performer@sgi.sgi.com Subject: Re: Static db loaders Date: Thu, 25 Apr 1996 08:20:19 GMT Organization: Pera Message-Id: <317f35bd.3357000@post.demon.co.uk> References: <9604242248.ZM29150@squash.mpik-tueb.mpg.de> In-Reply-To: <9604242248.ZM29150@squash.mpik-tueb.mpg.de> X-Mailer: Forte Agent .99d/32.182 Status: O On Wed, 24 Apr 1996 22:48:51 +0000, you wrote: >Hi, > >is there a way to link the loader for flt-files static under >Performer 2.0 ? > >I want to create an all included fat binary, but i got complains >like: > >PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "flt" >PF Warning: pfdLoadFile() - Unable to load file boat.flt because of problem >finding pfdLoadFile_flt Don't know if the loader library name is different for Performer 2.0 (we are still waiting to get it) but if you have got libpfflt.a on your machine you can link with it by specifying -B static before -lpfflt when you link. Mark. -- Mark Baranowski at work (baranowski@marklynn.demon.co.uk) Pera, VR Division. Melton Mowbray, Leicestershire. UK. Tel: +44 1664 501501, Fax: +44 1664 501553 From guest Thu Apr 25 01:28:47 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA10027; Thu, 25 Apr 1996 01:22:46 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA10024; Thu, 25 Apr 1996 01:22:45 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA23905; Thu, 25 Apr 1996 01:22:44 -0700 Received: from listserv.gmd.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA09971; Thu, 25 Apr 1996 01:22:26 -0700 Received: from mailer.mpib-tuebingen.mpg.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <1.86585481@listserv.gmd.de>; Thu, 25 Apr 1996 10:22:09 +0200 Received: from bogart.mpib-tuebingen.mpg.de by mailer.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0912AM) id AA07767; Thu, 25 Apr 1996 09:50:22 +0100 Received: from squash.mpik-tueb.mpg.de by bogart.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0442PM) id AA06388; Thu, 25 Apr 1996 10:23:00 +0100 Received: by squash (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.sgi.com id KAA29575; Thu, 25 Apr 1996 10:22:05 +0200 From: "Dietrich Opitz" Message-Id: <9604251022.ZM29573@squash.mpik-tueb.mpg.de> Date: Thu, 25 Apr 1996 10:22:04 +0000 X-Face: ,78BGR^:N$.'76:g~S1U^5[;4H@V1KZvxT0W&ugiSX!CO}A((fKEnL2;vdw~RdA'C}Snv2n/1pB3cZjiFbN{Q}nXx}2cd* X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Static db loaders - solved.. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, it was just a problem with the Makefile i used. Is fixed now. Sorry. Dietrich -- -- Dietrich Opitz MPI fuer biologische Kybernetik Spemannstr. 38 72076 Tuebingen GERMANY Tel: ++49(7071) 601 606 FAX: ++49(7071) 601 575 e-mail: dio@mpik-tueb.mpg.de From guest Thu Apr 25 04:30:18 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id EAA10415; Thu, 25 Apr 1996 04:21:18 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id EAA10412; Thu, 25 Apr 1996 04:21:13 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA28497; Thu, 25 Apr 1996 04:21:12 -0700 Received: from ldsa.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id EAA20508; Thu, 25 Apr 1996 04:21:10 -0700 From: dheskamp@ldsa.com Received: from ldsa.com (dgate) by ldsa.com (5.x/SMI-SVR4) id AA27190; Thu, 25 Apr 1996 07:16:38 -0400 Received: from ldsa (sun294) by ldsa.com (5.x/SMI-SVR4) id AA28938; Thu, 25 Apr 1996 07:21:26 -0400 Received: from pc1197.ldsa by ldsa (5.x/SMI-SVR4) id AA00682; Thu, 25 Apr 1996 07:21:22 -0400 To: info-performer@sgi.sgi.com Subject: MP isect data passing Date: Thu, 25 Apr 96 07:22:21 EDT Message-Id: <9604251122.153AE0@pc1197.ldsa> X-Mailer: SelectMAIL 1.2 Status: O Hello: I have successfully forked an intersection process, and passed data to it from my application process using pfPassIsectData. I then update the Isect data in the Intersection process and call pfGetIsectData from the application process. I DO NOT see the updated data in the application task. My question: How does one pass data back from the Intersection process to the application process. pfGetIsectData does not appear to work! Dave Heskamp Lockheed Martin Tactical Defense Systems 1210 Massillon Road Akron, Ohio 44315-0001 phone: (330) 796 - 5383 fax: (330) 796 - 7009 email: dheskamp@ldsa.com From guest Thu Apr 25 05:40:30 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA10609; Thu, 25 Apr 1996 05:32:10 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA10606; Thu, 25 Apr 1996 05:32:06 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA00135; Thu, 25 Apr 1996 05:32:05 -0700 Received: from rising.irisa.fr by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA24796; Thu, 25 Apr 1996 05:32:03 -0700 Received: from picasso.irisa.fr (picasso.irisa.fr [131.254.41.7]) by rising.irisa.fr (8.7.5/8.7.3) with ESMTP id OAA08324 for ; Thu, 25 Apr 1996 14:31:51 +0200 (MET DST) From: Elena Liria Date: Thu, 25 Apr 1996 14:31:49 +0200 Message-Id: <199604251231.OAA06927@picasso.irisa.fr> To: info-performer@sgi.sgi.com Subject: pfMakeLookat??? Status: O I'll like to know if there is any kind of function in Performer -lib- C++ to manage the point of view,( by changing its angles (h,p,r) or the angles and the position or the position only), in order to follow all the time a pfDCS's translation. Giving the pfDCS's translation, the camera has to be all the time looking at the objet. Elena Liria From guest Thu Apr 25 05:37:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA10602; Thu, 25 Apr 1996 05:29:17 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA10599; Thu, 25 Apr 1996 05:29:16 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA29976; Thu, 25 Apr 1996 05:29:15 -0700 Received: from shallow.division.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA24493; Thu, 25 Apr 1996 05:29:05 -0700 Received: from nga.division.co.uk by shallow.division.co.uk with SMTP id AA29214 (5.65c/IDA-1.4.4 for info-performer@sgi.sgi.com); Thu, 25 Apr 1996 12:28:54 GMT Received: by nga.division.co.uk with Microsoft Mail id <01BB32AB.33DC69A0@nga.division.co.uk>; Thu, 25 Apr 1996 13:29:17 +-100 Message-Id: <01BB32AB.33DC69A0@nga.division.co.uk> From: Andrew Ng To: "'Performer Mailing List'" Subject: Reducing latency in multi-process mode. Date: Thu, 25 Apr 1996 13:29:16 +-100 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Status: O Hi, I've been trying to implement a method for reducing the latency of the = view position when rendering in multi-process mode in Performer 2.0. = Basically the method is to over cull in the CULL stage and then to = insert the current view position into the DRAW stage from the APP. I've managed to achieve the over culling, and the insertion of the view = position into the DRAW using pfLoadMatrix in the draw callback. However, = the problem I'm facing now is the synchronization between the APP and = the DRAW. This is particularly important when dealing with multiple = channels and pipes which need to stay in sync. Basically I need to = somehow ensure that the DRAW gets the latest view position that the APP = has received, but at the same time for multiple channels and/or pipes, I = need to make sure that all the DRAW stages get the view positions from = the same sample time in the APP, otherwise the views will drift. I've been looking at the Performer multi-process model, trying to = understand how it behaves in the various phase modes, in order to try to = find a solution to the problem above. In particular how it works when = there are multiple channels and/or multiple CULL and DRAW processes. = What exactly does pfSync and pfFrame do in these situations? How do the = processes synchronize to each other? Any help, suggestions or comments would be greatly appreciated. Thanks. -------------------------------------------------------------------------= ----- Andrew Ng (Software Engineer) Division Limited, 19 Apex Court, Email: = nga@division.co.uk Woodlands, Almondsbury. Tel: +44 (0)1454 = 615554 Bristol BS12 4JT. UK. Fax: +44 (0)1454 = 615532 From guest Thu Apr 25 07:18:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA10965; Thu, 25 Apr 1996 07:10:05 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA10962; Thu, 25 Apr 1996 07:10:01 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA02841; Thu, 25 Apr 1996 07:10:00 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA04890; Thu, 25 Apr 1996 07:09:59 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA28488; Thu, 25 Apr 96 07:09:56 -0700 Received: by babar.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id HAA15650; Thu, 25 Apr 1996 07:09:55 -0700 Date: Thu, 25 Apr 1996 07:09:55 -0700 From: mtj@babar.asd.sgi.com (Michael T. Jones) Message-Id: <199604251409.HAA15650@babar.asd.sgi.com> To: info-performer@sgi.sgi.com, nga@division.co.uk Subject: RE: Reducing latency in multi-process mode Status: O Andrew writes: : I've been trying to implement a method for reducing the latency of the : view position when rendering in multi-process mode in Performer 2.0. : Basically the method is to over cull in the CULL stage and then to : insert the current view position into the DRAW stage from the APP. Note that a new feature in IRIS Performer 2.0 was the ability to have separate cull and viewing volumes for just this reason. Its documented in the man pages but the best example is to see what happens when the 'z' key is pressed in Perfly -- look at that code for an example. : I've managed to achieve the over culling, and the insertion of the view : position into the DRAW using pfLoadMatrix in the draw callback. However, : the problem I'm facing now is the synchronization between the APP and : the DRAW. This is particularly important when dealing with multiple : channels and pipes which need to stay in sync. Basically I need to : somehow ensure that the DRAW gets the latest view position that the APP : has received, but at the same time for multiple channels and/or pipes, I : need to make sure that all the DRAW stages get the view positions from : the same sample time in the APP, otherwise the views will drift. You have view position as a per-frame update stream from a head-tracker and simply need to get that value consistently in all channels and in all pipelines. The Performer channel pass-through data is not what you need here. What you need would seem to be a time-stamped (or rather, destination frame stamped) list of view parameters in shared memory that is consulted in the channel pre-draw callback to update the view. Note that since each channel on the same pipe is drawn consecutively, just grabbing the latest parameters is not sufficient. You'll also need to pay attention to the "frame id" which is something that you should send down through the channel pass-through data mechanism. : I've been looking at the Performer multi-process model, trying to : understand how it behaves in the various phase modes, in order to try to : find a solution to the problem above. In particular how it works when : there are multiple channels and/or multiple CULL and DRAW processes. : What exactly does pfSync and pfFrame do in these situations? How do the : processes synchronize to each other? Just remember that in LOCK or FLOAT mode entire frames will be dropped after an overload-frame event. This is why simple incrementing of the frame ID in the draw callback won't be enough. (Presuming that there are one or more frame overruns. If not, then there shoud be no problem.) : Any help, suggestions or comments would be greatly appreciated. This approach can be made to work well. It's been used in theme-park rides and other head-tracked applications. Michael Jones Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Thu Apr 25 09:22:39 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA11360; Thu, 25 Apr 1996 09:11:50 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA11357; Thu, 25 Apr 1996 09:11:49 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA07201; Thu, 25 Apr 1996 09:11:49 -0700 Received: from buggy.coryphaeus.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA21722; Thu, 25 Apr 1996 09:11:13 -0700 Received: by buggy.coryphaeus.com (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA04714; Thu, 25 Apr 1996 09:09:26 -0700 Date: Thu, 25 Apr 1996 09:09:26 -0700 From: kowsik@coryphaeus.com (Kowsik Guruswamy) Message-Id: <9604250909.ZM4712@buggy.coryphaeus.com> In-Reply-To: dheskamp@ldsa.com "MP isect data passing" (Apr 25, 7:22am) References: <9604251122.153AE0@pc1197.ldsa> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: dheskamp@ldsa.com, info-performer@sgi.sgi.com Subject: Re: MP isect data passing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 25, 7:22am, dheskamp@ldsa.com wrote: > Subject: MP isect data passing > Hello: > > I have successfully forked an intersection process, and passed data to it from my application process using > pfPassIsectData. I then update the Isect data in the Intersection process and call pfGetIsectData from the application > process. I DO NOT see the updated data in the application task. > > My question: How does one pass data back from the Intersection process to the application process. pfGetIsectData > does not appear to work! > > > Dave Heskamp pfPassIsectData is always downstream only. If you need to pass data from the Isect process back to the APP, you need to put the results in a shared memory segment maybe with a mutual exclusion lock. Not to mention framestamping it. Probably, the easiest thing to do is to have a pfCycleBuffer and every frame copy the necessary information to the Isect process and then get back the results. cbuf->getCurData(); // Check to see if we have any hits // process the hits // fill cbuf with new data cbuf->changed(); K. ps: Only catch is that you may not get the results of the collision immediately in the next frame, since the number of pfCycleMemory's created by pfCycleBuffer will be dependent on your APP, CULL, DRAW process model. -- kowsik@coryphaeus.com | pirts suiboM a hguorht neeb sah txet sihT http://www.coryphaeus.com | | You are not you, you are me! - arnie work: (408)-395-4537 e201 | From guest Thu Apr 25 09:58:11 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA11458; Thu, 25 Apr 1996 09:46:56 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA11455; Thu, 25 Apr 1996 09:46:52 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA09076; Thu, 25 Apr 1996 09:46:31 -0700 Received: from ldsa.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA27493; Thu, 25 Apr 1996 09:46:16 -0700 From: dheskamp@ldsa.com Received: from ldsa.com (dgate) by ldsa.com (5.x/SMI-SVR4) id AA28816; Thu, 25 Apr 1996 12:41:40 -0400 Received: from ldsa (sun294) by ldsa.com (5.x/SMI-SVR4) id AA00451; Thu, 25 Apr 1996 12:46:28 -0400 Received: from pc1197.ldsa by ldsa (5.x/SMI-SVR4) id AA10587; Thu, 25 Apr 1996 12:46:24 -0400 To: dheskamp@ldsa.com, info-performer@sgi.sgi.com Subject: Re: MP isect data passing Date: Thu, 25 Apr 96 12:47:22 EDT Message-Id: <9604251647.163D28@pc1197.ldsa> X-Mailer: SelectMAIL 1.2 Status: O Thanks to kowsik@coryphaeus.com for an answer on intersection data passing. I suggest that Silicon Graphics alter the man page for pfGetIsectData to be more explicit in this regard.... Dave Heskamp Lockheed Martin Tactical Defense Systems 1210 Massillon Road Akron, Ohio 44315-0001 phone: (330) 796 - 5383 fax: (330) 796 - 7009 email: dheskamp@ldsa.com From guest Thu Apr 25 10:10:00 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id JAA11590; Thu, 25 Apr 1996 09:59:49 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id JAA11587; Thu, 25 Apr 1996 09:59:49 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id JAA09710; Thu, 25 Apr 1996 09:59:48 -0700 Received: from motown.detroit.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA29996; Thu, 25 Apr 1996 09:59:29 -0700 Received: by motown.detroit.sgi.com (950413.SGI.8.6.12/930416.SGI) for info-performer@sgi.sgi.com id MAA01620; Thu, 25 Apr 1996 12:59:14 -0400 From: "Scott Young" Message-Id: <9604251259.ZM1618@motown.detroit.sgi.com> Date: Thu, 25 Apr 1996 12:59:14 -0400 X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O unscribe From guest Thu Apr 25 10:13:17 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA11611; Thu, 25 Apr 1996 10:03:55 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA11608; Thu, 25 Apr 1996 10:03:54 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA10062; Thu, 25 Apr 1996 10:03:54 -0700 Received: from evl.eecs.uic.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA00875; Thu, 25 Apr 1996 10:03:49 -0700 Received: from zbox.eecs.uic.edu by evl.eecs.uic.edu via ESMTP (950215.SGI.8.6.10/940406.SGI.AUTO) for id MAA17889; Thu, 25 Apr 1996 12:03:53 -0500 Received: (swami@localhost) by zbox.eecs.uic.edu (8.6.12/8.6.4) id RAA14530; Thu, 25 Apr 1996 17:03:53 GMT Date: Thu, 25 Apr 1996 12:03:53 -0500 (CDT) From: Swaminathan To: info-performer@sgi.sgi.com Subject: SIGSEGV in pfGroup::nb_cull Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I sent this sometime ago, but didnt receive any replies. I still havent solved this problem; probably because it happens infrequently. Hope I'm lucky the second time around! Any leads will be greatly appreciated. Thanks Swami ---------- Forwarded message ---------- Date: Mon, 15 Apr 1996 20:04:06 -0500 (CDT) From: Swaminathan To: info-performer@sgi.sgi.com Subject: SIGSEGV in pfGroup::nb_cull I am having problems reminiscient of the nb_clean() kind. I am loading a vrml scene into performer, and then bufferAddChild() all the respective inlines, with a corresponding pfBuffer::merge() after each addChild. The other suggestion of having a bounding sphere didnt work. The app runs almost all the time, except when I give demos :-). And I get the following in debugger when examining the core file. Core from signal SIGSEGV: Segmentation violation pfGroup::nb_cull() ["pfGroup.C":258, 0x5d47de14] Thanks Swami P.S. The call stack is as follows. pfGroup::nb_cull() ["pfGroup.C":258] pfSCS::nb_cull() ["pfSCS.C":308] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfGroup::nb_cull() ["pfGroup.C":247] pfSCS::nb_cull() ["pfSCS.C":259] pfSCS::nb_cull() ["pfSCS.C":308] pfSCS::nb_cull() ["pfSCS.C":308] pfGroup::nb_cull() ["pfGroup.C":247] pfScene::nb_cull() ["pfScene.C":269] _pfCuller::nb_cull() ["pfCuller.C":197] pfCull() ["pfProcess.C":3295] cbcull() ["pfChannel.C":60] pfChannel::pf_callCullFunc() ["pfChannel.C":1797] threadCull() ["pfProcess.C":3192] doCull() ["pfProcess.C":3244] doCullForkedDraw() ["pfProcess.C":3689] mpCull() ["pfProcess.C":3553] pfConfig() ["pfProcess.C":1630] main(argc = 1, argv = 0x7fffaf2c) ["cave6u.c++":74] __start() ["crt1text.s":133] From guest Thu Apr 25 13:48:20 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA13399; Thu, 25 Apr 1996 13:39:47 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA13396; Thu, 25 Apr 1996 13:39:46 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA21165; Thu, 25 Apr 1996 13:39:46 -0700 Received: from sgivie.vienna.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA06846; Thu, 25 Apr 1996 13:39:40 -0700 Received: from hobbes.vienna.sgi.com by sgivie.vienna.sgi.com via SMTP (920330.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA03769; Thu, 25 Apr 96 21:39:35 +0100 Received: by hobbes.vienna.sgi.com (950413.SGI.8.6.12/930416.SGI) for info-performer@sgi.sgi.com id WAA01202; Thu, 25 Apr 1996 22:39:25 -1300 From: "Franz Novak" Message-Id: <9604252239.ZM1201@hobbes.vienna.sgi.com> Date: Thu, 25 Apr 1996 22:39:24 +0000 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@sgi.sgi.com Subject: Performer and 50hz Video Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, a customer sent us to following questions concerning live video-input at 50 hz. Is this a known problem or is demo-code available where the customer can see how this is done? Here are the questions/problems: Problem 1: ********** Hardware: Onyx RE2 / 4 RM5 / Sirius Option Library: Performer 2.0 Display: 50 Hz Problem: We need to get a rendered scene with a live video-input at 50hz framerate. What we do have now: We got a stable framerate of 50 hz, but as soon as we turn on the live video-input and drain it to the RM, the framerate drops to appr. 25 hz. We use SIR_TEX_PACK_RGB_5 packing for the tex drain. What we tried: We tried to draw only the Live-Video Texture --> still appr. 25 hz framerate. We tried interleaved and non-interleaved --> no effect We tried PFTEX_LIST_APPLY and PFTEX_BASE_AUTO_SUBLOAD We tried to reduce the texture size from 1024*1024 to 512*512 --> the machine crashed. Question: Is there a way of getting Live-Video- input to texture memory with a 50 frames/sec ? It seems to us that the video-transfer blocks the rendering completely, because the sirius option has to wait until it gets a complete frame. We could also live with a quality penalty of the live input, but our framerate has to be stable 50 hz. Problem 2: ********** Hardware: Onyx RE2 / 4 RM5 / Sirius Option Library: Performer 2.0 Display: 50 Hz Problem: How do we get a texture on a loaded graphic e.g: .obj ? Problem 3: ********** Hardware: Onyx RE2 / 4 RM5 / Sirius Option Library: Performer 2.0 Display: 50 Hz Problem: As soon as our Live-video-texture gets into view, it sometimes happens that the video-input is drained to the wrong textures. It seems that the sirius board sometimes writes into the wrong texture memory adress. Thank you in advance for your help. Best regards Franz -- *********************************************************************** | Franz Novak | System Engineer | | | Silicon Graphics GmbH | | | | Modecenterstrasse 14 | franzn@vienna.sgi.com | | | A-1030 Wien | Phone: +43 1 7986848-517 | VoiceMail: 58025 | | Austria | Fax: +43 1 7986848-11 | Mail-Stop: IVA-309 | *********************************************************************** From guest Thu Apr 25 15:01:12 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA14250; Thu, 25 Apr 1996 14:54:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA14247; Thu, 25 Apr 1996 14:54:08 -0700 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA21649; Thu, 25 Apr 96 14:54:06 -0700 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id OAA05105; Thu, 25 Apr 1996 14:54:03 -0700 From: "Remi Arnaud" Message-Id: <9604251454.ZM5103@remi.asd.sgi.com> Date: Thu, 25 Apr 1996 14:54:02 -0700 In-Reply-To: Swaminathan "SIGSEGV in pfGroup::nb_cull" (Apr 25, 12:03pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@remi.asd.sgi.com, Swaminathan Subject: Re: SIGSEGV in pfGroup::nb_cull Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 25, 12:03pm, Swaminathan wrote: > > I am having problems reminiscient of the nb_clean() kind. I am loading a > vrml scene into performer, and then bufferAddChild() all the respective > inlines, with a corresponding pfBuffer::merge() after each addChild. The > other suggestion of having a bounding sphere didnt work. The app runs > almost all the time, except when I give demos :-). And I get the following > in debugger when examining the core file. > Do you have a callback associated to this last pfGroup ? Can you run the application in single cpu mode (-m0) to see if this is not a dso loader problem ? -- o o Remi ARNAUD - Silicon Graphics, Advanced Systems Dev o o o o Mail Stop 590 - 2011 N. Shoreline Boulevard o o o o Mountain View, California 94043-1389, USA o o o o Tel: (415) 933 6208 Fax: (415) 965 2658 o o From guest Thu Apr 25 16:43:24 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id QAA15010; Thu, 25 Apr 1996 16:33:27 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id QAA15007; Thu, 25 Apr 1996 16:33:27 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id QAA01304; Thu, 25 Apr 1996 16:33:26 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA03760; Thu, 25 Apr 1996 16:33:11 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id AAA02378; Fri, 26 Apr 1996 00:31:43 +0100 From: "Angus Dorbie" Message-Id: <9604260031.ZM2376@bitch.reading.sgi.com> Date: Fri, 26 Apr 1996 00:31:42 +0100 In-Reply-To: "Franz Novak" "Performer and 50hz Video" (Apr 25, 10:39pm) References: <9604252239.ZM1201@hobbes.vienna.sgi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: "Franz Novak" , info-performer@sgi.sgi.com Subject: Re: Performer and 50hz Video Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 25, 10:39pm, Franz Novak wrote: > Subject: Performer and 50hz Video > Hi, > > a customer sent us to following questions concerning live video-input > at 50 hz. Is this a known problem or is demo-code available where the > customer can see how this is done? > > > Here are the questions/problems: > > > Problem 1: > ********** > > Hardware: Onyx RE2 / 4 RM5 / Sirius Option > Library: Performer 2.0 > Display: 50 Hz > > Problem: We need to get a rendered scene with a live video-input at > 50hz framerate. > > What we do have now: > We got a stable framerate of 50 hz, but as soon as we > turn on the live video-input and drain it to the RM, the > framerate drops to appr. 25 hz. > We use SIR_TEX_PACK_RGB_5 packing for the tex drain. > > > What we tried: > We tried to draw only the Live-Video Texture --> still > appr. 25 hz framerate. > We tried interleaved and non-interleaved --> no effect > We tried PFTEX_LIST_APPLY and PFTEX_BASE_AUTO_SUBLOAD > We tried to reduce the texture size from 1024*1024 to > 512*512 --> the machine crashed. > > Question: Is there a way of getting Live-Video- input to texture memory with > a 50 frames/sec ? > > It seems to us that the video-transfer blocks the rendering completely, > because the sirius option has to wait until it gets a complete frame. > We could also live with a quality penalty of the live input, but our > framerate has to be stable 50 hz. > > > Problem 2: > ********** > Hardware: Onyx RE2 / 4 RM5 / Sirius Option > Library: Performer 2.0 > Display: 50 Hz > > Problem: How do we get a texture on a loaded graphic e.g: .obj ? Simply change the geostate or apply it & override in draw callbacks, use texture matrix to scale existing coordinates or texgen if coordinates are required. > > > Problem 3: > ********** > > Hardware: Onyx RE2 / 4 RM5 / Sirius Option > Library: Performer 2.0 > Display: 50 Hz > > Problem: As soon as our Live-video-texture gets into view, it sometimes > happens that the video-input is drained to the wrong textures. > It seems that the sirius board sometimes writes into the wrong texture memory > adress. > The target texture should be bound when loading the video image, could this be your problem? > > > Thank you in advance for your help. > > Best regards > > > Franz > > -- > > *********************************************************************** > | Franz Novak | System Engineer | | > | Silicon Graphics GmbH | | | > | Modecenterstrasse 14 | franzn@vienna.sgi.com | | > | A-1030 Wien | Phone: +43 1 7986848-517 | VoiceMail: 58025 | > | Austria | Fax: +43 1 7986848-11 | Mail-Stop: IVA-309 | > *********************************************************************** > >-- End of excerpt from Franz Novak -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Thu Apr 25 17:34:25 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA15408; Thu, 25 Apr 1996 17:26:28 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA15405; Thu, 25 Apr 1996 17:26:24 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA03926; Thu, 25 Apr 1996 17:26:23 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA11310; Thu, 25 Apr 1996 17:26:16 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA12262; Thu, 25 Apr 1996 20:18:56 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id UAA13198; Thu, 25 Apr 1996 20:12:17 -0400 From: "Bernard Leclerc" Message-Id: <9604252012.ZM13196@eagle.cae.ca> Date: Thu, 25 Apr 1996 20:12:12 -0400 In-Reply-To: Elena Liria "pfMakeLookat???" (Apr 25, 2:31pm) References: <199604251231.OAA06927@picasso.irisa.fr> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Elena Liria , info-performer@sgi.sgi.com Subject: Re: pfMakeLookat??? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Bonjour Elena, > I'll like to know if there is any kind of function in Performer -lib- C++ > to manage the point of view,( by changing its angles (h,p,r) or the angles > and the position or the position only), in order to follow all the time a > pfDCS's translation. Giving the pfDCS's translation, the camera has to be > all the time looking at the objet. A few weeks ago, I faced a similar problem. I wanted to be able to attach the viewpoint to any pfNode. I solved the problem by creating a new class derived from pfChannel. Here is an excerpt from the class definition: class pfuChannel : public pfChannel { public: void attachView(pfNode*); void detachNode(); private: pfNode* viewpoint; } The function pfuChannel::attachView() attaches a special vpNode to the pfNode passed as argument. This vpNode has a app() function that gets called during the pfAppFrame() traversal. At that moment, the vpNode has access to the current transformation matrix (pfTraverser::getMat) which is used to set the channel viewpoint position (pfChannel::setViewMat). To implement a pfMakeLookAt() function, just attach the viewpoint to the node and use pfChannel::setViewOffsets() to move the viewpoint outside the node. It works well and smoothly. I can't give you the actual implementation details since this class has been developped specifically for a contract... and I haven't had time to make it public yet... ;) However Elena, I invite you to get in touch with me directly if you need more info on the subject. I'll be glad to help you. Bonne chance... -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Thu Apr 25 21:27:21 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id VAA16011; Thu, 25 Apr 1996 21:19:53 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id VAA16008; Thu, 25 Apr 1996 21:19:48 -0700 Received: from deliverator.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id VAA10881; Thu, 25 Apr 1996 21:19:48 -0700 Received: from nypinet.nyp.ac.sg by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) id VAA29571; Thu, 25 Apr 1996 21:19:22 -0700 Received: from mgate.nyp.ac.sg. (mgate.nyp.ac.sg [202.12.95.26]) by nypinet.nyp.ac.sg (8.7.1/8.7.1) with SMTP id MAA05144; Fri, 26 Apr 1996 12:19:20 +0700 (SST) Received: by mgate.nyp.ac.sg. with Microsoft Mail id <31812149@mgate.nyp.ac.sg.>; Fri, 26 Apr 96 12:17:29 PDT From: "Ng Kian Bee, SIT/CS" To: performer , "Vincent, SGI" , "vincentoh@singapore.sgi.com" Subject: URGENT HELP: Polhemus tracker with Performer Date: Fri, 26 Apr 96 12:16:00 PDT Message-ID: <31812149@mgate.nyp.ac.sg.> Encoding: 26 TEXT X-Mailer: Microsoft Mail V3.0 Status: O Hello, I need this help ASAP. Millions thanx! I would like to use the following devices for my project: - Polhemus FASTRAK motion tracking device by Polhmeus Inc. - 3D Spaceball 2003 by Spacetec Inc. The software I'm using is Coryphaeus Software's EasyScene 3.0. Since this software runs on top of Performer 1.2/2.0, I'm praying that someone here could help me. I'm running on my RE2 machine. I need some one to guide me as to 1. where can I get the drivers for both the Polhemus and Spaceball? Or anyone here had tried on the device with their performer? 2. How do I set the devices up? That is do I just run the driver and it will work or do I have to configure my RE2 or ... Appreciate any reply. Many thanx! Kian ngkb@nyp.ac.sg From guest Fri Apr 26 06:12:51 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id DAA16640; Fri, 26 Apr 1996 03:21:06 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id DAA16637; Fri, 26 Apr 1996 03:20:58 -0700 Received: from deliverator.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA19787; Fri, 26 Apr 1996 03:20:57 -0700 Received: from mail0.nk-exa.co.jp by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id DAA04837; Fri, 26 Apr 1996 03:20:46 -0700 Received: from mail1.nk-exa.co.jp by mail0.nk-exa.co.jp (8.6.12+2.4W/3.3W-exa02) with ESMTP id TAA17064; Fri, 26 Apr 1996 19:19:03 +0900 Received: from exagw.nk-exa.co.jp (exagw.nk-exa.co.jp [160.14.254.1]) by mail1.nk-exa.co.jp (8.6.12+2.4W/3.4WEXA05) with ESMTP id TAA00823 for ; Fri, 26 Apr 1996 19:19:04 +0900 Received: from dimwit.dst.nk-exa.co.jp by exagw.nk-exa.co.jp (8.6.12+2.4W/3.4W2/1.4) with SMTP id TAA04894; Fri, 26 Apr 1996 19:12:11 +0900 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.com id AA08114; Fri, 26 Apr 96 19:17:35 +0900 To: info-performer@sgi.com Subject: pfLightPoint Date: Fri, 26 Apr 1996 19:17:27 +0900 Message-Id: <8113.830513847@dimwit.dst.nk-exa.co.jp> From: YAMANAKA MASAHIKO Status: O This might be one of FAQ, but... I checked the behavior of pfLightPoint at Performer2.0(170). What I did was following. 1. Create pfLightPoint 2. AddChild it under the proper node. However, no light points were visible, and as I did 3. Set the light point's position the light point appears. Is this one of Performer's spec.? or bug? or there are some mistakes of me? # I know, it's obsolete so I shouldn't use it. # However, it's very convenient. # I think it's good to support it in the future. Thanx, -- M.Y. From guest Fri Apr 26 08:51:24 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA16840; Fri, 26 Apr 1996 07:19:51 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA16837; Fri, 26 Apr 1996 07:19:46 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA25660; Fri, 26 Apr 1996 07:19:46 -0700 Received: from listserv.gmd.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA00391; Fri, 26 Apr 1996 07:18:37 -0700 Received: from mailer.mpib-tuebingen.mpg.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <0.38A88E30@listserv.gmd.de>; Fri, 26 Apr 1996 9:43:00 +0200 Received: from bogart.mpib-tuebingen.mpg.de by mailer.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0912AM) id AA12694; Fri, 26 Apr 1996 09:09:47 +0100 Received: from squash.mpik-tueb.mpg.de by bogart.mpib-tuebingen.mpg.de; (5.65v3.2/1.1.8.2/03Nov95-0442PM) id AA09081; Fri, 26 Apr 1996 09:43:43 +0100 Received: by squash (940816.SGI.8.6.9/940406.SGI) id JAA00853; Fri, 26 Apr 1996 09:42:42 +0200 From: "Dietrich Opitz" Message-Id: <9604260942.ZM851@squash.mpik-tueb.mpg.de> Date: Fri, 26 Apr 1996 09:42:41 +0000 In-Reply-To: "Franz Novak" "Performer and 50hz Video" (Apr 25, 10:39pm) References: <9604252239.ZM1201@hobbes.vienna.sgi.com> X-Face: ,78BGR^:N$.'76:g~S1U^5[;4H@V1KZvxT0W&ugiSX!CO}A((fKEnL2;vdw~RdA'C}Snv2n/1pB3cZjiFbN{Q}nXx}2cd* X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Franz Novak" Subject: Re: Performer and 50hz Video Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi Franz, European PAL-Video format has 25 Frames per second. (50 Fields.) If you don't have access to the fields, this resticts LiveVideo to 25 fps. So, why not refresh the Live Video in every second call of pfDraw() and run the videohandler in single process. Should give you a stable 50fps. Dietrich -- Dietrich Opitz MPI fuer biologische Kybernetik Spemannstr. 38 72076 Tuebingen GERMANY Tel: ++49(7071) 601 606 FAX: ++49(7071) 601 575 e-mail: dio@mpik-tueb.mpg.de From guest Fri Apr 26 08:51:48 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA16854; Fri, 26 Apr 1996 07:22:33 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA16850; Fri, 26 Apr 1996 07:22:25 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA25768; Fri, 26 Apr 1996 07:22:24 -0700 Received: from listserv.esi.es by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA00813; Fri, 26 Apr 1996 07:22:15 -0700 Received: from esi.es (OFFICE.esi.es) by listserv.esi.es (5.0/SMI-SVR4) id AA24106; Fri, 26 Apr 1996 16:22:17 --100 Received: from OFFICE/MERCURY by esi.es (Mercury 1.21); 26 Apr 96 16:21:28 GMT+0100 Received: from MERCURY by OFFICE (Mercury 1.21); 26 Apr 96 16:20:50 GMT+0100 Received: from VISTA95.esi.es by esi.es (Mercury 1.21); 26 Apr 96 16:20:26 GMT+0100 Message-Id: <3180DC42.78DC@esi.es> Date: Fri, 26 Apr 1996 16:22:58 +0200 From: Stefan Schuster Organization: ESI X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: info-performer@sgi.sgi.com Subject: rotate dcs positioned relative to scene matrix Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable content-length: 473 Status: O Hi, I=B4m loading various objects into a scene and want to rotate and = translate them as DCS=B4s by use of pfDCSRot. These objects were = positioned relative to each other in a modeling tool. My problem is, that I want them to rotate (translate) relative to their own position but don=B4t have a clue, which Matrix-Transformations to use. By now their always rotating around the scene centerpoint. I=B4d appreciate if anyone could give me a hint on that. Thanks Stefan From guest Fri Apr 26 09:11:01 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA16922; Fri, 26 Apr 1996 07:44:29 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA16919; Fri, 26 Apr 1996 07:44:28 -0700 Received: from deliverator.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA26501; Fri, 26 Apr 1996 07:44:28 -0700 Received: from bhole.cae.ca by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) id HAA29927; Fri, 26 Apr 1996 07:44:26 -0700 Received: from poster.cae.ca (poster.cae.ca [142.39.22.1]) by bhole with SMTP (DuhMail/2.0) id KAA21714; Fri, 26 Apr 1996 10:40:37 -0400 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA06481; Fri, 26 Apr 1996 10:37:20 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id KAA14976; Fri, 26 Apr 1996 10:38:47 -0400 From: "Bernard Leclerc" Message-Id: <9604261038.ZM14974@eagle.cae.ca> Date: Fri, 26 Apr 1996 10:38:43 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.com Subject: Onyx Infinite Reality vof's Cc: gilroy@stlaurent.sgi.com (Gilles Roy - SGI Account Manager), parviz@stlaurent.sgi.com (Parviz Parandeh - SGI System Engineer) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O A very simple question... On a deskside Onyx InfiniteReality, is it possible to generate 3 channels of 1024x768_60 using a single graphics pipe? Is the MCO required? Thanks in advance. -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Fri Apr 26 09:23:13 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA16975; Fri, 26 Apr 1996 07:58:23 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA16972; Fri, 26 Apr 1996 07:58:22 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA27116; Fri, 26 Apr 1996 07:58:15 -0700 Received: from pxp.stlaurent.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id HAA03875; Fri, 26 Apr 1996 07:58:00 -0700 Received: by pxp.stlaurent.sgi.com (950413.SGI.8.6.12/911001.SGI) id LAA02267; Fri, 26 Apr 1996 11:07:48 -0400 From: "parviz" Message-Id: <9604261107.ZM2265@pxp.stlaurent.sgi.com> Date: Fri, 26 Apr 1996 11:07:48 -0400 In-Reply-To: "Bernard Leclerc" "Onyx Infinite Reality vof's" (Apr 26, 10:38am) References: <9604261038.ZM14974@eagle.cae.ca> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Bernard Leclerc" , info-performer@sgi.sgi.com Subject: Re: Onyx Infinite Reality vof's Cc: gilroy@stlaurent.sgi.com (Gilles Roy - SGI Account Manager), parviz@stlaurent.sgi.com (Parviz Parandeh - SGI System Engineer) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On InfiniteReality you don't need MCO any more. what you need is InfiniteReality with DG-8 option, by default you get 2 channel and since you need three you should look at DG-8 option, one pipe vs two depends on total number of polygons and pipeline polygon throughput. -- Regards Parviz Parandeh SE , Montreal Canada parviz@stlaurent.sgi.com Voice mail: 58479 Tel: 514-745-2440 Fax: 514-745-2660 From guest Fri Apr 26 09:21:28 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA16970; Fri, 26 Apr 1996 07:57:48 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA16967; Fri, 26 Apr 1996 07:57:47 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA27102; Fri, 26 Apr 1996 07:57:46 -0700 Received: from xr1.atlas.fr by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA03787; Fri, 26 Apr 1996 07:57:22 -0700 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 26 Apr 1996 10:53:34 +0200 X400-Received: by mta xr1.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 26 Apr 1996 10:53:34 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 26 Apr 1996 10:53:29 +0200 X400-Received: by /PRMD=THOMSON/ADMD=ATLAS/C=FR/; converted (undefined); Relayed; Fri, 26 Apr 1996 12:53:13 +0200 Date: Fri, 26 Apr 1996 12:53:13 +0200 X400-Originator: DOMINIQUE.D.P.PIERRE@TTS.thomson.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=THOMSON/ADMD=ATLAS/C=FR/;4708531026041996/A28995/INDRE] Original-Encoded-Information-Types: undefined X400-Content-Type: P2-1984 (2) Content-Identifier: 11A4D2B50700 Alternate-Recipient: Allowed From: PIERRED Message-ID: <4708531026041996/A28995/INDRE/11A4D2B50700*@MHS> To: Performer (Non Receipt Notification Requested) (IPM Return Requested) (Reply Requested) Subject: Subscribe me please. Importance: High Sensitivity: Private X-Zm-Priority: Urgent Status: O From guest Fri Apr 26 09:45:25 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA17018; Fri, 26 Apr 1996 08:25:02 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA17015; Fri, 26 Apr 1996 08:24:58 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA29098; Fri, 26 Apr 1996 08:24:57 -0700 Received: from tcsernet.tcs.ernet.in by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA03318; Fri, 26 Apr 1996 07:53:55 -0700 From: deepa@tcsernet.tcs.ernet.in Message-ID: <9604262033.AA22075@tcsernet.tcs.ernet.in> Subject: Lights To: info-performer@sgi.sgi.com Date: Fri, 26 Apr 96 16:45:12 EDT Content-Length: 815 Content-Type: text X-Mailer: ELM [version 2.3 PL2] Status: O Dear Performer users, I wrote a very simple program to draw one polygon, map a texture on it and rotate it in a loop. I defined colors for the vertices and set the the shade model as Gouraud shading model. One light was set, and a default light model applied. The program was compiled on the onyx and executed with the display set to Indy, Indigo and the onyx respectively. The program works perfectly on the onyx, but exits without displaying on the indigo (2 extreme) and on the indy the whole scene appears white at first and gradually dims to gray as the object rotates away from the light (on the onyx, the background which is black is not affected and the lighting only affects the object). Why does this happen? Can anyone help? Deepa Krishnan Tata Consultancy Services deepa@tcsernet.tcs.ernet.in From guest Fri Apr 26 09:46:05 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA17031; Fri, 26 Apr 1996 08:28:19 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA17028; Fri, 26 Apr 1996 08:28:18 -0700 Received: from deliverator.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA29279; Fri, 26 Apr 1996 08:28:18 -0700 Received: from bhole.cae.ca by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) id IAA05191; Fri, 26 Apr 1996 08:28:16 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA14079; Fri, 26 Apr 1996 11:20:03 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id LAA15137; Fri, 26 Apr 1996 11:21:27 -0400 From: "Bernard Leclerc" Message-Id: <9604261121.ZM15135@eagle.cae.ca> Date: Fri, 26 Apr 1996 11:21:22 -0400 In-Reply-To: "parviz" "Re: Onyx Infinite Reality vof's" (Apr 26, 11:07am) References: <9604261038.ZM14974@eagle.cae.ca> <9604261107.ZM2265@pxp.stlaurent.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.com Subject: Re: Onyx Infinite Reality vof's Cc: gilroy@stlaurent.sgi.com (Gilles Roy - SGI Account Manager), parviz@stlaurent.sgi.com (Parviz Parandeh - SGI System Engineer) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 26, 11:07am, Parviz Parandeh wrote: > On InfiniteReality you don't need MCO any more. what you need is > InfiniteReality with DG-8 option, by default you get 2 channel and since > you need three you should look at DG-8 option, one pipe vs two depends > on total number of polygons and pipeline polygon throughput. Can the DG-8 option fit inside a Onyx Deskside? Specifically, I would need the capability to expand to 6 CPUs, 1 InfiniteReality, 1 DG-8 option, 384 Mb RAM and one 4 Gb disk. Can this fit in a deskside Onyx? Thanks. -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Fri Apr 26 10:14:21 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA17114; Fri, 26 Apr 1996 08:57:22 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA17111; Fri, 26 Apr 1996 08:57:22 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA01276; Fri, 26 Apr 1996 08:57:17 -0700 Received: from pxp.stlaurent.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id IAA12211; Fri, 26 Apr 1996 08:56:47 -0700 Received: by pxp.stlaurent.sgi.com (950413.SGI.8.6.12/911001.SGI) id MAA02366; Fri, 26 Apr 1996 12:07:50 -0400 From: "parviz" Message-Id: <9604261207.ZM2364@pxp.stlaurent.sgi.com> Date: Fri, 26 Apr 1996 12:07:50 -0400 In-Reply-To: "Bernard Leclerc" "Re: Onyx Infinite Reality vof's" (Apr 26, 11:21am) References: <9604261038.ZM14974@eagle.cae.ca> <9604261107.ZM2265@pxp.stlaurent.sgi.com> <9604261121.ZM15135@eagle.cae.ca> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Bernard Leclerc" , info-performer@sgi.sgi.com Subject: Re: Onyx Infinite Reality vof's Cc: gilroy@stlaurent.sgi.com (Gilles Roy - SGI Account Manager), parviz@stlaurent.sgi.com (Parviz Parandeh - SGI System Engineer) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O If you need more than 4 cpus you should look at onyx rack, onyx deskside suport 2-4 CPU's, 2 RM6 and DG-2 or DG-8, also three 1024x768_60 channels with depth compexity of 4 requires more than 2 RM6 -- Regards Parviz Parandeh SE , Montreal Canada parviz@stlaurent.sgi.com Voice mail: 58479 Tel: 514-745-2440 Fax: 514-745-2660 From guest Fri Apr 26 12:54:32 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA18337; Fri, 26 Apr 1996 11:35:45 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA18334; Fri, 26 Apr 1996 11:35:40 -0700 Received: from deliverator.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA12006; Fri, 26 Apr 1996 11:35:39 -0700 Received: from ht.com by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id LAA23518; Fri, 26 Apr 1996 11:35:32 -0700 Received: from te.ht.com by ht.com (940816.SGI.8.6.9/3.1.090690-High Techsplanations) id OAA15159; Fri, 26 Apr 1996 14:22:03 -0400 Received: by te.ht.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id OAA01655; Fri, 26 Apr 1996 14:22:03 -0400 From: "Paul Sherman" Message-Id: <9604261422.ZM1653@te.ht.com> Date: Fri, 26 Apr 1996 14:22:03 -0400 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.com Subject: pfSprites Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Does anyone have any example code on these? Not urgent, they just kind of interesting. Looks like you could implement several "billboard" type objects in concert pretty easily (a forest of trees to extend the example in the pguide). Anyway, if anyone has some non-proprietary code they'd be willing to share, I'd love to see it. If not, I will probably get around to trying them myself later on. Thanks, Paul Sherman paul@ht.com From guest Fri Apr 26 14:39:11 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id NAA18876; Fri, 26 Apr 1996 13:20:57 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA18873; Fri, 26 Apr 1996 13:20:56 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA16608; Fri, 26 Apr 1996 13:20:54 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id NAA13463; Fri, 26 Apr 1996 13:20:27 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA09155; Fri, 26 Apr 1996 16:14:58 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id QAA15948; Fri, 26 Apr 1996 16:16:02 -0400 From: "Bernard Leclerc" Message-Id: <9604261615.ZM15946@eagle.cae.ca> Date: Fri, 26 Apr 1996 16:15:56 -0400 In-Reply-To: "parviz" "Re: Onyx Infinite Reality vof's" (Apr 26, 12:07pm) References: <9604261038.ZM14974@eagle.cae.ca> <9604261107.ZM2265@pxp.stlaurent.sgi.com> <9604261121.ZM15135@eagle.cae.ca> <9604261207.ZM2364@pxp.stlaurent.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Onyx Infinite Reality vof's Cc: gilroy@stlaurent.sgi.com (Gilles Roy - SGI Account Manager), parviz@stlaurent.sgi.com (Parviz Parandeh - SGI System Engineer) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 26, 12:07pm, Parviz Parandeh wrote: > If you need more than 4 cpus you should look at onyx rack, onyx deskside > support 2-4 CPU's, 2 RM6 and DG-2 or DG-8, also three 1024x768_60 channels > with depth complexity of 4 requires more than 2 RM6 Ok. Assume I limit myself to 4 CPUs, 2 RM6 and 1 DG-8 -- it's still a lot :) Are you telling me I can't have 4 sub-samples with three 1024x768_60 channels? If it's the case, then I have no anti-aliasing. Is it possible to use a smaller resolution (say 800x600_60) for the two side channels while keeping the center channel at 1024x768_60? And will this give enough depth for multi-sampling? -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Fri Apr 26 18:01:00 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id QAA19722; Fri, 26 Apr 1996 16:23:18 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id QAA19719; Fri, 26 Apr 1996 16:23:14 -0700 Received: from deliverator.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id QAA26571; Fri, 26 Apr 1996 16:23:14 -0700 Received: from toutatis.xs4all.nl by deliverator.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI.AUTO) for id QAA20251; Fri, 26 Apr 1996 16:23:11 -0700 Received: from xs1.xs4all.nl (gideon@xs1.xs4all.nl [193.78.33.42]) by toutatis.xs4all.nl (8.7.5/8.7.2) with SMTP id BAA10237 for ; Sat, 27 Apr 1996 01:14:08 +0200 (MET DST) Received: by xs1.xs4all.nl id AA03184 (5.67b/IDA-1.5 for info-performer@sgi.com); Sat, 27 Apr 1996 01:14:08 +0200 From: gideon Message-Id: <199604262314.AA03184@xs1.xs4all.nl> Subject: RGBA or ABGR and textures To: info-performer@sgi.com Date: Sat, 27 Apr 1996 01:14:07 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: O Hi, I'm trying to download textures from an sgi movie file - using the dmedia library. It all seems to work, except for the fact that the packing of the pixels is wrong. I've tried a number of things to change the pixel packing during transer (like glPixelStorei ...), to no avail. Does anyone have a suggestion how to solve this ? BTW I'm using Performer 2.0 and OpenGL on a High Impact. Thanks, Gideon. From guest Fri Apr 26 19:07:47 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA20001; Fri, 26 Apr 1996 17:38:47 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA19998; Fri, 26 Apr 1996 17:38:39 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA29840; Fri, 26 Apr 1996 17:38:38 -0700 Received: from teal.csn.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA17688; Fri, 26 Apr 1996 17:38:36 -0700 Received: from uucp-1.csn.net (uucp-1.csn.net [199.117.27.26]) by teal.csn.net (8.6.12/8.6.9) with ESMTP id SAA07181 for ; Fri, 26 Apr 1996 18:38:35 -0600 Received: from evt.com (uucp@localhost) by uucp-1.csn.net (8.7.5/8.7.3) with UUCP id SAA01713 for csn!sgi.com!info-performer; Fri, 26 Apr 1996 18:38:35 -0600 (MDT) Received: from snowmass by vail via ESMTP (940816.SGI.8.6.9/930416.SGI) for <@vail:info-performer@sgi.com> id SAA01112; Fri, 26 Apr 1996 18:10:38 -0700 Received: by snowmass (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id SAA24289; Fri, 26 Apr 1996 18:10:38 -0700 From: "Dewey Anderson" Message-Id: <9604261810.ZM24287@snowmass> Date: Fri, 26 Apr 1996 18:10:37 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: movietex and OpenGL Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I've had some trouble trying to get movietex to work with OpenGl. (I haven't tried IGL.) This is on an Onyx REII, Performer 2.0, IRIX 5.3. First I had to fix some errors to get it to compile, to wit: The variable "DoFields" was declared twice. I removed one. In VideoInit, the line videosource = glXCreateGLXVideoSourceSGIX(Dsp, 0 /* screen */, vlServer, vlPath, VL_TEXTURE, vlDrn)) == None); has unbalanced parentheses. Since there was no obvious "if" action taking place, I just removed the ") == None)" There were also 4 calls to "mmode" which is not OGL. I replaced them with calls to glMatrixMode. And then I installed patch 154 so that the GLXVideoSourceSGIX stuff in VideoInit would work. This done, I got it to compile and run. I used the -vR commands, i.e.: movietex -vR so that it would map video onto the texture and begin running immediately. All I get is a white square rotating about the Z axis. The motion looks right, but that white square is supposed to be incoming video. I have called up the video control panel and done "Live Video Input" to verify that the video is coming in OK. It is. Also, vidtotex works fine, so I'm confident the video can get in OK. movietex just doesn't seem to be able to do the "Performery" thing with it. Has anybody gotten movietex to work with live video and OpenGL? Naturally, my objective isn't to have movietex running, but to use a working example as a guide to get my own application to work. But I can't get the example to work. Thanks, Dewey K. Anderson Evolving Video Technologies Arvada, Colorado From guest Fri Apr 26 20:06:57 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id SAA20159; Fri, 26 Apr 1996 18:24:41 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id SAA20156; Fri, 26 Apr 1996 18:24:40 -0700 Received: from giraffe.asd.sgi.com by rock.csd.sgi.com via SMTP (950413.SGI.8.6.12/910805.SGI) for id SAA01526; Fri, 26 Apr 1996 18:24:39 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@rock.csd.sgi.com id AA24841; Fri, 26 Apr 96 18:24:33 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id SAA05808; Fri, 26 Apr 1996 18:24:21 -0700 Date: Fri, 26 Apr 1996 18:24:21 -0700 From: src@rose.asd.sgi.com (Sharon Clay) Message-Id: <199604270124.SAA05808@rose.asd.sgi.com> To: info-performer@rock Subject: Announcing IRIS Performer2.1 for InfiniteReality Cc: performer@rose.asd.sgi.com Status: O ************* Announcing IRIS Performer 2.1 *************** IRIS Performer 2.1 is now available for shipping to run on an InfiniteReality near you! New features in IRIS Performer2.1 for InfiniteReality include: o Clip-mapping for texturing like you've never textured before! You can have MIPmapped geospecific textures of size up to 32768x32768 (will get even bigger in the future) and let IRIS Performer manage the texture paging automatically for you while you traverse your database in real time. This uses special texturing capabilities in InfiniteReality. o Dynamic video resizing for dynamic resolution Finally, a real way to manage overload due to fill limitations. InfiniteReality allows for the resolution of an output channel to be changed dynamically in real time. This allows fill-limited application to draw to a smaller viewport as load increases. IRIS Performer will manage the details, as well as provide automatic and user-controlled load management utilities. o Graphics timing from within the graphics pipeline using special InfiniteReality timing support for better real-time load management o Active surface definition applied to smooth LOD morphing of terrain Tired of drawing tons of sub-pixel polygons at your horizon? IRIS Performer2.1 allows you to define very large terrain areas with levels of detail and will smoothly transition between levels based on a variety of possible default or user-defined parameters and functions. o Fast database loader The new libpfpfb database loader (and writer) will let you convert your databases to this new fast-loading .pfb format. We have released this new version of IRIS Performer specifically for those applications using the new features of InfiniteReality. To be able to have this product available with the introduction of InfiniteReality, we have focused our attention for this release on that platform. Therefore, 2.1 is only intended to run on IRIX6.2 and on InfiniteReality. However, utilities that do not require an InfiniteReality, namely the fast database loader and the adaptive terrain library, are being made available through other mechanisms: o our ftp site o patch upgrades for 2.0 that will be announced soon. We hope that this will address everyone's current needs and will further enable you to new heights of high performance graphics! Sincerely The IRIS Performer Team Read on for ordering information! Product Codes and Prices: ------------------------- SC4-PERF-2.1 - $1265.00 IRIS Performer 2.1 Software Includes a CD and online documentation (reference pages and book) M4-PERF-2.0 - $230.00 IRIS Performer 2.0 Documentation Only (the book has not changed for 2.1) Includes a Programmer's Guide (600 Pages) Includes C and C++ Man Pages (700+ Pages each) (Need extra printed documentation sets?) SR4-PERF-2.1 - $295.00 IRIS Performer 2.1 Right To Use For people who need to run performer on multiple development stations but don't require a CD and Manuals for each one. (This is for the second through Nth copies, not the first) Upgrade Policies: ----------------- If you have a software support contract with SGI's Global Customer Satisfaction Division (previously known as CSD) and have previously bought a copy of IRIS Performer, than you can an order a copy of IRIS Performer2.1 at no charge. However, you do have to call and order it so here is the number: 800-800-4SGI (upgrades) Note that the basic product does not include the manuals. These manuals will be the same as the 2.0 manuals so you may not need them if you already have 2.0. New Purchases: -------------- If you are buying an InfiniteReality and have not previously bought a copy of IRIS Performer, or, do not have a support contract, you can purchase your copy of 2.1 through tele-sales at 1-800-800-7441 (new purchases) or through your sales representative. Note that printed manuals are ordered separately. We also recommend that you get a support contract so that we can easily update you with new versions! Overview of IRIS Performer2.1: ------------------------------ IRIS Performer provides a powerful and extensible programming interface for creating real-time visual simulation and other interactive graphics applications. IRIS Performer 2.1 is designed to bring out the best of the Onyx/InfiniteReality (iR) system. It does this by providing direct support for advanced features of the iR, such as very large MIP-map textures (up to 32768x32768) for geospecific texture (called Clip-mapped textures), dynamic video resolution to control pixel rendering load, active surface definitions for efficient meshing and morphing, graphics pipeline instrumentation for tuning and optimization, fast database loading, and other iR advances. IRIS Performer 2.1 is based on the industry standard OpenGL graphics library and combines with the IRIX 6.2 64-bit operating system and its REACT extensions to form a uniquely powerful suite of tools and features for creating real-time visual simulation applications. IRIS Performer consists of two main libraries, libpf and libpr, and four associated libraries, libpfdu, libpfui, libpfutil, and the new libpfs, as well as numerous database loader libraries, including the new fast loading libpfpfb. The basis of IRIS Performer is the performance rendering library libpr, a low level library providing high speed rendering functions based on pfGeoSets, efficient graphics state control using pfGeoStates, and other application-neutral functions. Layered above libpr is libpf, a real-time visual simulation environment providing a high-performance multi-processing database rendering system that takes best advantage of IRIS symmetric multiprocessing CPU hardware. The new Active Surface Definition library, libpfs, contains support for active surface definitions, an advanced method of defining, reconstructing, and displaying geometric objects with variable resolution. One use of this support is in large-area terrain rendering where the hierarchical level of detail nature and user directed morphing allow high-quality visualization with selectable polygon density. This library has both a C and C++ API and is IRIS GL/OpenGL independent. The database utility library, libpfdu, provides powerful functions for defining both geometric and appearance attributes of three dimensional objects, encourages sharing of state and materials and generates efficient triangle strips from independent polygonal input. The libpfui library contains user interface building blocks for creating manipulators and user-interface components common to many interactive applications. This library has both a C and C++ API and is IRIS GL/OpenGL independent. Completing the suite of support libraries is libpfutil, the IRIS Performer utility library. It provides a collection of convenience routines implementing tasks such as smoke effects, MultiChannel Option support, graphical user interface tools, X and IRIS GL event collection and management, and traversal functions. Added for 2.1 are utilities for loading and viewing databases with Clip-mapped textures and sample routines to create and read active surface definition data structures. The database libraries use the facilities of libpfdu, libpf, and libpr to import database files in many popular industry standard database formats. These loaders also serve as a guide to developers creating new database importers. The PFA and PFB formats can read and write any valid Performer scene graph and the binary PFB format loads geometry are rates exceeding 150000 triangles per second, up to two orders of magnitude faster than many of the other loaders. IRIS Performer2.1 also supports the addition of loader-independent DSOs that contain database operators that operate on files after they are loaded. These operators are currently used for applying Clip-mapping to generic databases. For aid in application development, IRIS Performer includes sample application source code ranging from simple programs to illustrate particular features to the comprehensive, GUI-driven file viewer perfly. IRIS Performer2.1 also includes demos (with source code) of Clip-mapping and active surface definition terrain. Getting More Information: ------------------------- For further information, check out the IRIS Performer WWW Page in SiliconSurf. The URL is: http://www.sgi.com/Technology/Performer.html Be sure to check out the gift source code as we update these periodically with new-improved versions and bug fixes. You can also contact our product marketing manger: Larry McDonough, lardog@asd.sgi.com, (415) 933-6165 and me: Sharon Rose Clay, src@asd.sgi.com, (415) 933 - 1002 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Fri Apr 26 22:03:47 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id UAA20497; Fri, 26 Apr 1996 20:16:43 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id UAA20494; Fri, 26 Apr 1996 20:16:35 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id UAA05004; Fri, 26 Apr 1996 20:16:35 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA27762; Fri, 26 Apr 1996 20:16:33 -0700 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA28575; Fri, 26 Apr 96 20:15:57 -0700 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id UAA27417; Fri, 26 Apr 1996 20:11:20 -0700 From: "Javier Castellar" Message-Id: <9604262011.ZM27415@sixty.asd.sgi.com> Date: Fri, 26 Apr 1996 20:11:20 -0700 In-Reply-To: "Bernard Leclerc" "Re: Onyx Infinite Reality vof's" (Apr 26, 4:15pm) References: <9604261038.ZM14974@eagle.cae.ca> <9604261107.ZM2265@pxp.stlaurent.sgi.com> <9604261121.ZM15135@eagle.cae.ca> <9604261207.ZM2364@pxp.stlaurent.sgi.com> <9604261615.ZM15946@eagle.cae.ca> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Bernard Leclerc" , info-performer@sgi.sgi.com Subject: Re: Onyx Infinite Reality vof's Cc: gilroy@stlaurent.sgi.com (Gilles Roy - SGI Account Manager), parviz@stlaurent.sgi.com (Parviz Parandeh - SGI System Engineer) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O There is not a video/frame buffer limitation in your case (with 2 RM6 you could get three 1024x768 with 8 subsamples AA), the limitation is on the pixel fill, this is why Parviz configured a 4 RM6 machine: DC = 4 1024 x 2304 x 4 x 60 = 576 Mtexels/s ===> 4 RM6 ( if your system is 60hz) On Apr 26, 4:15pm, Bernard Leclerc wrote: > Subject: Re: Onyx Infinite Reality vof's > On Apr 26, 12:07pm, Parviz Parandeh wrote: > > > If you need more than 4 cpus you should look at onyx rack, onyx deskside > > support 2-4 CPU's, 2 RM6 and DG-2 or DG-8, also three 1024x768_60 channels > > with depth complexity of 4 requires more than 2 RM6 > > Ok. Assume I limit myself to 4 CPUs, 2 RM6 and 1 DG-8 -- it's still a lot :) > Are you telling me I can't have 4 sub-samples with three 1024x768_60 channels? > If it's the case, then I have no anti-aliasing. > > Is it possible to use a smaller resolution (say 800x600_60) for the two side > channels while keeping the center channel at 1024x768_60? And will this give > enough depth for multi-sampling? > > -- > ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca > / / | / Systems Engineer voice: +1 514 341 2000 > / / | __/ CAE Electronics Ltd. extension 2275 > / / | / 8585 Cote De Liesse fax: +1 514 340 5496 > / ____ | / P.O. Box 1800 > _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 >-- End of excerpt from Bernard Leclerc -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon From guest Fri Apr 26 23:46:24 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id WAA20682; Fri, 26 Apr 1996 22:02:35 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id WAA20679; Fri, 26 Apr 1996 22:02:31 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id WAA07718; Fri, 26 Apr 1996 22:02:30 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id WAA02500; Fri, 26 Apr 1996 22:02:26 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA01015; Fri, 26 Apr 96 22:02:06 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id WAA07755; Fri, 26 Apr 1996 22:01:15 -0700 From: "Sharon Clay" Message-Id: <9604262201.ZM7753@rose.asd.sgi.com> Date: Fri, 26 Apr 1996 22:01:15 -0700 In-Reply-To: "Dewey Anderson" "movietex and OpenGL" (Apr 26, 6:10pm) References: <9604261810.ZM24287@snowmass> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Dewey Anderson" , info-performer@sgi.sgi.com Subject: Re: movietex and OpenGL - cont. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Woops - I made an error in my previous mail. OpenGL video texture for Performer2.0 did NOT make it into the IRIX6.2 release. My apologies, src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Fri Apr 26 23:46:04 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id VAA20673; Fri, 26 Apr 1996 21:57:53 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id VAA20670; Fri, 26 Apr 1996 21:57:52 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id VAA07536; Fri, 26 Apr 1996 21:57:52 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id VAA02241; Fri, 26 Apr 1996 21:57:47 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA00925; Fri, 26 Apr 96 21:57:06 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id VAA07693; Fri, 26 Apr 1996 21:56:09 -0700 From: "Sharon Clay" Message-Id: <9604262156.ZM7691@rose.asd.sgi.com> Date: Fri, 26 Apr 1996 21:56:08 -0700 In-Reply-To: "Dewey Anderson" "movietex and OpenGL" (Apr 26, 6:10pm) References: <9604261810.ZM24287@snowmass> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Dewey Anderson" , info-performer@sgi.sgi.com Subject: Re: movietex and OpenGL Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 26, 6:10pm, Dewey Anderson wrote: > Subject: movietex and OpenGL -> ->Has anybody gotten movietex to work with live video and OpenGL? Video texture for OpenGL was broken in Performer2.0. A fix is available in 2 ways: 1) the performer_eoe 2.0.1 libraries in 6.2 have fixed video texture 2) we will soon be providing a patch for 2.0 with fixes for current bugs. I will post the current bug list following this. FYI: here is an updated movietex.c: /* * Copyright 1995, Silicon Graphics, Inc. * ALL RIGHTS RESERVED * * UNPUBLISHED -- Rights reserved under the copyright laws of the United * States. Use of a copyright notice is precautionary only and does not * imply publication or disclosure. * * U.S. GOVERNMENT RESTRICTED RIGHTS LEGEND: * Use, duplication or disclosure by the Government is subject to restrictions * as set forth in FAR 52.227.19(c)(2) or subparagraph (c)(1)(ii) of the Rights * in Technical Data and Computer Software clause at DFARS 252.227-7013 and/or * in similar or successor clauses in the FAR, or the DOD or NASA FAR * Supplement. Contractor/manufacturer is Silicon Graphics, Inc., * 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311. * * Permission to use, copy, modify, distribute, and sell this software * and its documentation for any purpose is hereby granted without * fee, provided that (i) the above copyright notices and this * permission notice appear in all copies of the software and related * documentation, and (ii) the name of Silicon Graphics may not be * used in any advertising or publicity relating to the software * without the specific, prior written permission of Silicon Graphics. * * THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, * EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. * * IN NO EVENT SHALL SILICON GRAPHICS BE LIABLE FOR ANY SPECIAL, * INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY * DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, * WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY * THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE * OR PERFORMANCE OF THIS SOFTWARE. * * file: movietex.c * ---------------- * * Example of using pfTextures different dynamic input sources * for creating texture movies * o using Sirius video as input source control via VideoLibrary * - needs HAVE_VL defined * o using images in memory as input source * o using framebufer as input source (not yet implemented) * * $Revision: 1.14 $ * * Cmdline Options: * ---------------- * -i - use image texture source (can follow with list of textures * or else we will make default ones) * -v - use video texture source * -f - use framebuffer texture source * -t - default base texture * -R - start up running * -F - transfer fields from video * -c - set number of components in texture image * * Runtime Controls: * ----------------- * r - start running movie * space - stop and reset movie * ESC - exit * up/down arrows: step through image movie * */ /* Make this 1 to have Video Library calls */ #define HAVE_VL 0 /* general includes */ #include #include #include #include #include /* X Window includes */ #include #include #include #include #if HAVE_VL /* VL includes */ #include #include #endif #include #if HAVE_VL int vlTexWidth, vlTexHeight; /* Video controls */ static int vlInSrc = VL_ANY, vlDevice = VL_ANY; static VLControlValue vlSize, vlTiming, vlTexPack; static VLControlValue vlFormat; static VLControlValue vlCaptureType; static VLServer vlServer; static VLPath vlPath; static VLNode vlSrc, vlDrn; #endif /* HAVE_VL */ #if HAVE_VL static int VideoInit(void); static void VideoExit(void); static void setVideoTextureParameters(pfGeoSet *gset); static int loadTextureMatrixCB(pfGeoState *gs, void *userData); static int loadIDMatrixCB(pfGeoState *gs, void *userData); #endif /* HAVE_VL */ static pfList *loadMovieFiles(pfTexture *movieTex, char **fileNames, int count); static pfDispList *MakeScene(pfGeoSet *geom, pfTexture *tex); static void DoEvents(void); static void DrawScene(void); static void StartMovie(void); static void ResetMovie(void); static void GetFrameData(void); static float idmat[4][4] = { 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0 }; pfVec2 texcoords[]={ {0.0f, 0.0f}, {1.0f, 0.0f}, {1.0f, 1.0f}, {0.0f, 1.0f} }; pfVec3 coords[] ={ {-1.0f, -1.0f, 0.0f }, { 1.0f, -1.0f, 0.0f }, { 1.0f, 1.0f, 0.0f }, {-1.0f, 1.0f, 0.0f } }; pfVec4 colors[] ={ {1.0f, 1.0f, 1.0f, 1.0f} }; #define NUM_COLORS 10 static unsigned int texclrs[] = { 0x108f8fff, /* base is teal */ 0xff0000ff, /* level 1 is red */ 0x00ff00ff, /* level 2 is green */ 0x0000ffff, /* level 3 is blue */ 0xff00ffff, /* level 4 is magenta */ 0xfff00fff, /* level 5 is yellow */ 0x00ffffff, /* level 6 is cyan */ 0xf0f0f0ff, /* level 7 is grey */ 0xf0f010ff, /* level 8 is ground */ 0xf010f0ff, /* level 9 is sky */ }; /* setup parameters */ static int TexSource=PFTEX_SOURCE_IMAGE; static int glTexFormat = PFTEX_RGB_5; /* PFTEX_RGB_4, PFTEX_RGBA_8 */ static int TexComp = 3; /* for movies of host texture images */ static char *dftTexName=NULL; static char **texFileNames=NULL; static int ListLength=0; static pfList *TexList=NULL; /* general movie controls */ static int DoExit = 0; /* flag to quit */ static int RunMode = 0; /* is movie running */ static int TexFrame = -1; /* for IMAGE textures only */ /* general movie data */ static pfTexture *MovieTex=NULL; static pfGeoSet *ScreenGeom=NULL; static pfDispList *SceneDL=NULL; static Display *Dsp=NULL; static pfWindow *Win=NULL; static char OptionStr[] = "c:ifvR?t:"; static int docmdline(int argc, char **argv) { extern char *optarg; extern int optind; int opt; while ((opt = getopt(argc,argv,OptionStr)) != -1) { switch(opt) { /* custom options */ case 'c': TexComp = atoi(optarg); break; case 'f': /* use image in framebuffer - not implemented */ TexSource = PFTEX_SOURCE_FRAMEBUFFER; break; case 'i': /* use specified files as movie textures */ TexSource = PFTEX_SOURCE_IMAGE; break; case 'v': /* use video input */ TexSource = PFTEX_SOURCE_VIDEO; break; case 't': /* default textue when no movie is running */ dftTexName = optarg; break; case 'R': /* come up running */ RunMode ^= 1; break; case '?': default: pfNotify(PFNFY_FATAL,PFNFY_USAGE, "movietex [-irRf] [-t dftimage] [image0 image1 image2 ...]\n"); exit(0); break; } /* switch */ } /* while */ texFileNames = &(argv[optind]); return argc - optind; } int main(long argc, char *argv[]) { int i, j, k; int arg; char* str; pfFrustum *frust; pfTexture* tex; Window xwin; void *arena=NULL; /* Initialize Performer */ pfInit(); /* pfInitArenas(); */ pfNotifyLevel(PFNFY_DEBUG); pfInitState(arena); arg = docmdline(argc, argv); /* Append to PFPATH standard data dirs */ pfFilePath(".:/usr/share/Performer/data:/usr/demos/data/textures"); /* Initialize window and viewing frustum */ Win = pfNewWin(arena); pfWinOriginSize(Win, 0, 0, 400, 400); pfWinName(Win, "texlist"); pfWinType(Win, PFWIN_TYPE_X); pfOpenWin(Win); Dsp = pfGetCurWSConnection(); xwin = pfGetWinWSWindow(Win); XSelectInput(Dsp, xwin, KeyPressMask); XMapWindow(Dsp, xwin); XSync(Dsp,FALSE); frust = pfNewFrust(NULL); pfApplyFrust(frust); pfDelete(frust); pfLoadMatrix(idmat); pfTranslate (0.0f, 0.0f, -4.0f); /* Create Movie Texture and Screen Geom */ MovieTex = pfNewTex(arena); /* set some basic formats for doing dynamic textures */ pfTexFormat(MovieTex, PFTEX_SUBLOAD_FORMAT, 1); pfTexFilter(MovieTex, PFTEX_MINFILTER, PFTEX_BILINEAR); if (dftTexName) { pfNotify(PFNFY_DEBUG, PFNFY_PRINT, "\tLoading tex %s as base texture\n", dftTexName); if (!pfLoadTexFile(MovieTex, dftTexName)) dftTexName = 0; } ScreenGeom = pfNewGSet(arena); /* create scene */ SceneDL = MakeScene(ScreenGeom, MovieTex); /* initialize movie */ switch(TexSource) { case PFTEX_SOURCE_VIDEO: #if HAVE_VL pfNotify(PFNFY_INFO, PFNFY_PRINT, "Starting Sirius Video...."); if (VideoInit() < 0) pfNotify(PFNFY_FATAL, PFNFY_RESOURCE, "Error in initializing VL and Sirius."); setVideoTextureParameters(ScreenGeom); /* video starts running HERE */ vlBeginTransfer(vlServer, vlPath, 0, NULL); pfNotify(PFNFY_NOTICE,PFNFY_PRINT,"Done with video init"); #else pfNotify(PFNFY_FATAL, PFNFY_PRINT, "HAVE_VL is not defined - no video texture possible."); #endif /* HAVE_VL */ break; case PFTEX_SOURCE_IMAGE: TexList = loadMovieFiles(MovieTex, texFileNames, arg); ListLength = pfGetNum(TexList); pfNotify(PFNFY_INFO, PFNFY_PRINT, "%s has %d frames\n", pfGetTexName(MovieTex), ListLength); break; case PFTEX_SOURCE_FRAMEBUFFER: pfNotify(PFNFY_FATAL, PFNFY_PRINT, "Framebuffer movies are not implemented."); break; } pfEnable(PFEN_TEXTURE); pfApplyTEnv(pfNewTEnv(arena)); pfApplyTex(MovieTex); while(!DoExit) { /* draw textured scene */ DrawScene(); /* advance running movie */ if (RunMode) { /* get data for next movie frame */ GetFrameData(); } /* handle user events */ DoEvents(); } #if HAVE_VL VideoExit(); #endif /* HAVE_VL */ return 0; } static void DoEvents(void) { long do_draw = 0; long hlmode = 0; long ov = 0; int dev; short val; while (XPending(Dsp)) { XEvent event; XNextEvent(Dsp, &event); switch (event.type) { case KeyPress: { char buf[100]; int rv; KeySym ks; rv = XLookupString(&event.xkey, buf, sizeof(buf), &ks, 0); switch(ks) { case XK_Escape: DoExit = 1; break; case XK_space: ResetMovie(); break; case XK_r: StartMovie(); break; case XK_Up: if ((TexSource == PFTEX_SOURCE_IMAGE) && val) { TexFrame++; if (TexFrame < ListLength) { pfTexFrame(MovieTex, TexFrame); TexFrame = pfGetTexFrame(MovieTex); fprintf(stderr, "Tex frame %d: \"%s\"\n", TexFrame, pfGetTexName(pfGet(TexList, TexFrame))); pfApplyTex(MovieTex); } else { fprintf(stderr, "frame %d too high. max is %d.\n", TexFrame, ListLength-1); TexFrame = ListLength-1; } } break; case XK_Down: if ((TexSource == PFTEX_SOURCE_IMAGE) && val && (TexFrame > -1)) { TexFrame--; if (TexFrame < -1) TexFrame = -1; pfTexFrame(MovieTex, TexFrame); TexFrame = pfGetTexFrame(MovieTex); fprintf(stderr, "Tex frame %d: \"%s\"\n", TexFrame, pfGetTexName(pfGet(TexList, TexFrame))); pfApplyTex(MovieTex); } break; default: break; }/* key switch */ } }/* dev switch */ } /* while events */ } static void DrawScene(void) { static pfVec4 clr = {0.1f, 0.0f, 0.4f, 1.0f}; static frame = 0; pfClear(PFCL_COLOR | PFCL_DEPTH, clr); if (TexSource == PFTEX_SOURCE_VIDEO) { /* since incoming video is interlaced, offset destination by 1 on alternate frames */ pfTexLoadOrigin(MovieTex, PFTEX_ORIGIN_DEST, 0, (frame++ % 2) ? 1 : 0); pfLoadTex(MovieTex); } pfRotate (PF_Z, 1.0f); pfDrawDList(SceneDL); pfSwapWinBuffers(Win); } static void StartMovie(void) { switch(TexSource) { case PFTEX_SOURCE_IMAGE: TexFrame = 0; case PFTEX_SOURCE_VIDEO: break; case PFTEX_SOURCE_FRAMEBUFFER: break; } RunMode = 1; } static void GetFrameData(void) { switch(TexSource) { case PFTEX_SOURCE_IMAGE: pfNotify(PFNFY_NOTICE,PFNFY_PRINT," MOVIE FRAME %d", TexFrame); pfTexFrame(MovieTex, TexFrame); pfApplyTex(MovieTex); TexFrame++; if (TexFrame == ListLength) TexFrame = 0; case PFTEX_SOURCE_VIDEO: /* load texture for next frame */ pfLoadTex(MovieTex); break; case PFTEX_SOURCE_FRAMEBUFFER: break; } } static void ResetMovie(void) { switch(TexSource) { case PFTEX_SOURCE_IMAGE: TexFrame = -1; RunMode = 0; pfTexFrame(MovieTex, TexFrame); TexFrame = pfGetTexFrame(MovieTex); fprintf(stderr, "Tex frame %d: \"%s\"\n", TexFrame, pfGetTexName(MovieTex)); pfApplyTex(MovieTex); break; case PFTEX_SOURCE_VIDEO: break; case PFTEX_SOURCE_FRAMEBUFFER: break; } } static pfDispList * MakeScene(pfGeoSet *geom, pfTexture *tex) { pfDispList *dl; pfGeoState *gstate; void *arena=NULL; dl = pfNewDList(PFDL_FLAT, 0, arena); pfGSetAttr(geom, PFGS_COORD3, PFGS_PER_VERTEX, coords, NULL); pfGSetAttr(geom, PFGS_TEXCOORD2, PFGS_PER_VERTEX, texcoords, NULL); pfGSetAttr(geom, PFGS_COLOR4, PFGS_OVERALL, colors, NULL); pfGSetPrimType(geom, PFGS_QUADS); pfGSetNumPrims(geom, 1); gstate = pfNewGState (arena); pfGSetGState (geom, gstate); pfGStateMode (gstate, PFSTATE_CULLFACE, PFCF_OFF); pfGStateAttr (gstate, PFSTATE_TEXENV, pfNewTEnv(arena)); pfGStateAttr (gstate, PFSTATE_TEXTURE, tex); pfOpenDList(dl); pfDrawGSet(geom); pfCloseDList(); return dl; } static pfList * loadMovieFiles(pfTexture *movieTex, char **fileNames, int count) { pfList *texList; pfTexture *tex; unsigned int *image; void *arena=NULL; int i, j; texList = pfNewList(sizeof(pfTexture*), 16, arena); pfTexLoadMode(movieTex, PFTEX_LOAD_LIST, PFTEX_LIST_AUTO_SUBLOAD); if (count) { char *strp; pfTexName(movieTex, "File Image Movie"); if (!dftTexName) { dftTexName = texFileNames[0]; pfLoadTexFile(movieTex, dftTexName); } for (i=0; i < count; i++) { strp = texFileNames[i]; tex = pfNewTex(arena); pfTexName(tex, strp); pfNotify(PFNFY_DEBUG, PFNFY_PRINT, "\tLoading tex %s as frame %d\n", strp, i-1); pfLoadTexFile(tex, strp); pfTexFormat(tex, PFTEX_SUBLOAD_FORMAT, 1); pfTexFilter(tex, PFTEX_MINFILTER, PFTEX_BILINEAR); pfAdd(texList, tex); } } else { /* no files specified - create some colored textures */ char tstr[PF_MAXSTRING]; pfTexName(movieTex, "Color Image Movie"); if (!dftTexName) { image = pfMalloc(sizeof(int)*32*32, NULL); for (j=0; j < 32*32; j++) image[j] = 0xff808000; pfTexImage(movieTex, image, 4, 32, 32, 1); } for (i=0; i < NUM_COLORS; i++) { image = pfMalloc(sizeof(int)*32*32, NULL); for (j=0; j < 32*32; j++) image[j] = texclrs[i]; tex = pfNewTex(arena); sprintf(tstr, "frame=%d", i); pfTexName(tex, tstr); pfTexFormat(tex, PFTEX_SUBLOAD_FORMAT, 1); pfTexFilter(tex, PFTEX_MINFILTER, PFTEX_BILINEAR); pfTexImage(tex, image, 4, 32, 32, 1); pfTexLoadSize(tex, 32, 32); pfAdd(texList, tex); } } /* set list of texture frame on the base texture */ pfTexList(movieTex, texList); return texList; } #if HAVE_VL static int VideoInit(void) { /* open the server */ if (!(vlServer = vlOpenVideo(""))) { vlPerror("vlOpenVideo"); fprintf(stderr, "couldn't open video server!\n"); return 1; } /* Get the Video source */ vlSrc = vlGetNode(vlServer, VL_SRC, VL_VIDEO, vlInSrc); /* Get the Texture drain */ vlDrn = vlGetNode(vlServer, VL_DRN, VL_TEXTURE, 0); /* Create path */ vlPath = vlCreatePath(vlServer, vlDevice, vlSrc, vlDrn); if (vlPath < 0) { vlPerror("vlCreatePath"); return -1; } /* setup path */ if (vlSetupPaths(vlServer, (VLPathList)&vlPath,1,VL_SHARE, VL_SHARE) < 0) { vlPerror("vlSetupPaths"); return -1; } /* select the appropriate events */ if (vlSelectEvents(vlServer, vlPath, VLStreamPreemptedMask | VLControlChangedMask ) < 0) { vlPerror("Select Events"); return -1; } /* sirius always delivers fields, so the capture type is moot */ vlCaptureType.intVal = VL_CAPTURE_NONINTERLEAVED; vlSetControl(vlServer, vlPath, vlDrn, VL_CAP_TYPE, &vlCaptureType); switch( glTexFormat ) { case PFTEX_RGBA_4: vlTexPack.intVal = SIR_TEX_PACK_RGBA_4; break; case PFTEX_RGB_5: vlTexPack.intVal = SIR_TEX_PACK_RGB_5; break; case PFTEX_RGBA_8: vlTexPack.intVal = SIR_TEX_PACK_RGBA_8; break; default: vlTexPack.intVal = SIR_TEX_PACK_RGB_5; glTexFormat = PFTEX_RGB_5; break; } /* Set the Texture packing mode */ vlSetControl(vlServer, vlPath, vlDrn, VL_PACKING, &vlTexPack); /* Get the timing from input source */ vlGetControl(vlServer, vlPath, vlSrc, VL_TIMING, &vlTiming); /* Set texture drain's timing to input source */ vlSetControl(vlServer, vlPath, vlDrn, VL_TIMING, &vlTiming); /* Get corresponding size */ vlGetControl(vlServer, vlPath, vlSrc, VL_SIZE, &vlSize); #ifndef IRISGL /* OPENGL */ { GLXVideoSourceSGIX videosource; const char *gl_extensions; int has_interlace; videosource = glXCreateGLXVideoSourceSGIX(Dsp, 0 /* screen */, vlServer, vlPath, VL_TEXTURE, vlDrn); if (videosource == None) { fprintf(stderr, "can't create video source\n"); exit(EXIT_FAILURE); } glXMakeCurrentReadSGI(Dsp, pfGetWinWSDrawable(Win), videosource, pfGetWinGLCxt(Win)); /* turn on interlacing */ gl_extensions = glGetString(GL_EXTENSIONS); if (!gl_extensions) { fprintf(stderr, "can't get GL_EXTENSIONS\n"); } has_interlace = strstr((const char *) gl_extensions, "GL_SGIX_interlace") != NULL; glEnable(GL_INTERLACE_SGIX); if (!has_interlace || !glIsEnabled(GL_INTERLACE_SGIX)) { fprintf(stderr, "can't enable interlace extension\n"); exit(EXIT_FAILURE); } } #endif return 0; } static void setVideoTextureParameters(pfGeoSet *gset) { pfGeoState *gstate; pfTexture *tex; pfMatrix *tmat; void *arena=NULL; float s_scale, t_scale; gstate = pfGetGSetGState(gset); tex = pfGetGStateAttr(gstate, PFSTATE_TEXTURE); if ((vlTiming.intVal == VL_TIMING_525_SQ_PIX) || (vlTiming.intVal == VL_TIMING_525_CCIR601)) { vlTexWidth = 1024; vlTexHeight = 512; } else { vlTexWidth = 1024; vlTexHeight = 1024; } /* create texture matrix for scaling texcoords to valid part of texture */ tmat = (pfMatrix*) pfCalloc(sizeof(pfMatrix), 1, arena); pfMakeIdentMat(*tmat); s_scale = vlSize.xyVal.x / (float) vlTexWidth; t_scale = vlSize.xyVal.y / (float) vlTexHeight; (*tmat)[0][0] = s_scale; (*tmat)[1][1] = -t_scale; /* invert in y because of video origin */ (*tmat)[3][1] = t_scale; /* this is really a translate */ /* gset callbacks to manage texture matrix - put matrix in userData */ pfGStateFuncs(gstate, loadTextureMatrixCB, loadIDMatrixCB, tmat); /* since interlacing is on, the actual height of the texture is doubled */ pfTexImage(tex, NULL, TexComp, vlTexWidth, vlTexHeight/2, 1); /* sirius sends fields, so each load is half the height of the video */ pfTexLoadSize(tex, vlSize.xyVal.x, vlSize.xyVal.y/2); /* specify the texture format, this is the default */ pfTexFormat(tex, PFTEX_INTERNAL_FORMAT, glTexFormat); pfTexLoadMode(tex, PFTEX_LOAD_SOURCE, PFTEX_SOURCE_VIDEO); } static void VideoExit(void) { vlEndTransfer(vlServer, vlPath); vlDestroyPath(vlServer, vlPath); vlCloseVideo(vlServer); exit(0); } /* callback to load texture matrix to invert the video image */ static int loadTextureMatrixCB(pfGeoState *gs, void *userData) { pfMatrix *tmat = (pfMatrix *)(userData); #ifdef IRISGL mmode(MTEXTURE); pfLoadMatrix(*tmat); mmode(MVIEWING); #else glMatrixMode(GL_TEXTURE); pfLoadMatrix(*tmat); glMatrixMode(GL_MODELVIEW); #endif return 0; } static int loadIDMatrixCB(pfGeoState *gs, void *userData) { #ifdef IRISGL mmode(MTEXTURE); pfLoadMatrix(idmat); mmode(MVIEWING); #else glMatrixMode(GL_TEXTURE); pfLoadMatrix(idmat); glMatrixMode(GL_MODELVIEW); #endif return 0; } #endif -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Sat Apr 27 00:37:30 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id WAA20812; Fri, 26 Apr 1996 22:53:32 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id WAA20805; Fri, 26 Apr 1996 22:53:24 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id WAA08878; Fri, 26 Apr 1996 22:53:24 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id WAA04801; Fri, 26 Apr 1996 22:53:15 -0700 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA01644; Fri, 26 Apr 96 22:51:48 -0700 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA27478; Fri, 26 Apr 1996 22:46:35 -0700 From: "Javier Castellar" Message-Id: <9604262246.ZM27476@sixty.asd.sgi.com> Date: Fri, 26 Apr 1996 22:46:35 -0700 In-Reply-To: carter@eai.com "OpenPerformer & Vis/Sim outside SGI" (Apr 16, 9:45am) References: <199604161445.JAA06866@granite.eai.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: javier@sixty.asd.sgi.com, carter@eai.com, info-performer@sgi.sgi.com Subject: OpenPf & Vis/Sim outside SGI (I) Cc: carter@vortex.eai.com (2370) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I just came back for a long trip, here please find my own comments on this interesting issue. On Apr 16, 9:45am, carter@eai.com wrote: > Subject: OpenPerformer & Vis/Sim outside SGI > I have a couple of things to say on the subject of the Vis/Sim world > outside SGI. SGI seems to me largely responsible for developing and > driving the field of commercial visual simulation over the past five > years or so. They've done so with the excellent RE product line, and > the well thought-out Performer library. Others have been slow to catch on. > > SGI has been alone on the battlefield for so long (so to speak) that > _perhaps_ it hasn't had the opportunity to build up its own corporate > self-confidence with respect to competing with others. > > Now, the world is rapidly taking on a different hue with respect to > the market for visual simulation. No longer is SGI completely alone in > its offerings of HW and SW to this market. Now that other competent > graphics hardware is entering the mainstream market on platforms such > as HP and Sun, where does that leave SGI with respect to visual simulation > on those platforms? In my opinion the HP, IBM and Sun offers still miles away from the SGI high end offer (both HW = iR/RE2 and SW = Performer 2.1). Only in the medium end and mainly in the low end systems is in which we should consider competition but mainly in the HW, not in SW (HW=Impact/Extreme and SW = Performer 2.0). > > Here are some possible, though perhaps extreme, postures SGI might adopt: > > 1. IBM-style "do it our way or do it all yourself": Performer remains a > closed product tied to the SGI platform, and other vendor's customers > must invent all their visual simulation applications from scratch. > This has the advantage of minimizing "leakage" of the customer base > away from the SGI platform, but it makes it very difficult for SGI > to win customers away from other vendors -- they would have to > rewrite their applications yet again for the platforms whose policy > forced them to write it from scratch in the first place! Not to > mention that the last time I heard the official policy from SGI (Dev > Forum '95), it was "SGI is a hardware company, not a software company. > We are interested in selling SGI boxes." Of course, that was before > the acquisition of Alias and Wavefront. :-) We provide a medium term, we let people to use Performer (our way) or use OpenGL (do it all your self). Maybe we have not OpenPerformer but we have an outstanding feature that other vendors cannot offer: a single API regardless the level of your simulator (it works from Indy to iR). A simulator that begings with an Indy can became a iR level simulator. > > 2. OpenGL-style: SGI takes the high road and places its hardware and support > into direct, level, fair, head-to-head competition with HP, Sun, E&S and > anyone else who feels that they have the "grambaugh" to tangle with the > inventors of visual simulation, and the leaders in commercial hardware > rendering! OpenPerformer. This has the added advantage that the sales > force can compete to "convert" customers from other platforms to SGI. > > The market for visual simulation on platforms other than SGI is not > growing, it is *HERE* ***NOW***!!! The market is *not* standing still > waiting to see if SGI will open up performer. Both HP and Sun have > competent graphics products available NOW. You can bet that they have > announcements of excellent products on the way. Our initial aproach is to move into an OpenDatabase aproach to VisSim. Other vendors (mainly on the high end) use to rely on "closed" databases to trap his clients. The SGI's aproach of being open in terms in the databases support (to be as much as indenpent as possible from the database format) > > Both have the strategic advantage of being MUCH larger organizations > than SGI. First off SGI is not what a call an small company. Second i would like to know how much money they spend R&D for Hi-end graphics . I think that SGI is the most focused in hi-end graphics and in fact we devote more resources to graphics that E&S, HP ... etc. > Both have the distinct tactical disadvantage that they are now > trying to break into SGI's home turf. SGI is at a critical policy > crossroads: it can finesse the entire market into playing by ITS rules > (by opening Performer), or it can leave Performer a proprietary library > and let the market decide whose rules to play by. I agree, but we have to go step by step ... and i prefer the first step to be perfomance + features rather that to be Open as the first priority. > >-- End of excerpt from carter@eai.com -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon From guest Sat Apr 27 00:45:41 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA20882; Fri, 26 Apr 1996 23:00:39 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA20879; Fri, 26 Apr 1996 23:00:38 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA09043; Fri, 26 Apr 1996 23:00:38 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id XAA05072; Fri, 26 Apr 1996 23:00:32 -0700 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA01742; Fri, 26 Apr 96 22:59:27 -0700 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA27521; Fri, 26 Apr 1996 22:54:36 -0700 From: "Javier Castellar" Message-Id: <9604262254.ZM27519@sixty.asd.sgi.com> Date: Fri, 26 Apr 1996 22:54:35 -0700 In-Reply-To: klaus "Re: OpenPerformer & Vis/Sim outside SGI" (Apr 16, 11:13am) References: <199604161713.LAB10780@xmission.xmission.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com, klaus Subject: (II) OpenPf & Vis/Sim outside SGI Cc: javier@sixty.asd.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Some additional comments. On Apr 16, 11:13am, klaus wrote: > Subject: Re: OpenPerformer & Vis/Sim outside SGI > > > > From: carter@eai.com > > Subject: OpenPerformer & Vis/Sim outside SGI > > To: info-performer@sgi.sgi.com > > > > 2. OpenGL-style: SGI takes the high road and places its hardware and support > > into direct, level, fair, head-to-head competition with HP, Sun, E&S and > > anyone else who feels that they have the "grambaugh" to tangle with the > > inventors of visual simulation, and the leaders in commercial hardware > > rendering! OpenPerformer. This has the added advantage that the sales > > force can compete to "convert" customers from other platforms to SGI. > > > > Are you claiming that SGI are the inventors of visual simulation? > Hmmmm. Not very old, are you? And Apple invented GUI's, right? ;> You are right, SGI did not invented VisSim but a lot of people who work here did in some percent in SGI, E&S, L-M, Star, ... etc. What SGI maybe did was to reinvent it. > > -klaus > > > >-- End of excerpt from klaus -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetent" Hari Seldon From guest Sat Apr 27 00:49:29 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA20892; Fri, 26 Apr 1996 23:03:50 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA20888; Fri, 26 Apr 1996 23:03:50 -0700 Received: from giraffe.asd.sgi.com by rock.csd.sgi.com via SMTP (950413.SGI.8.6.12/910805.SGI) id XAA09160; Fri, 26 Apr 1996 23:03:38 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@rock.csd.sgi.com id AA01824; Fri, 26 Apr 96 23:03:36 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id XAA10364; Fri, 26 Apr 1996 23:02:26 -0700 From: "Sharon Clay" Message-Id: <9604262302.ZM10362@rose.asd.sgi.com> Date: Fri, 26 Apr 1996 23:02:25 -0700 In-Reply-To: src (Sharon Clay) "Announcing IRIS Performer2.1 for InfiniteReality" (Apr 26, 6:24pm) References: <199604270124.SAA05808@rose.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@rock Subject: Performer2.0 bug list Cc: performer@rose.asd.sgi.com, aschaffe@rock Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Here is the Performer2.0 bug list. Some of these were already in the release notes for Performer2.0. src. =========================== IRIS Performer 2.0 Bug List =========================== Bugs fixed in the IRIX6.2 performer_eoe libraries: o OpenGL Fog: OpenGL exponential fog in IRIS Performer 2.0 did not match the IRIS GL fog. o OpenGL default MIPmapped Texture filter: Graphics platforms that should be using MIPMAP_TRILINEAR as the default minification filter (such as RealityEngine and IMPACT) were actually using MIPMAP_LINEAR in 2.0. o Detail Texture Splines:\f1 Several bugs with the specification of detail splines in IRIS Performer 2.0 have been fixed. The default OpenGL splines now match the IRIS GL defaults. Specification of clamped detail splines for IRIS GL operation have been fixed. o OpenGL Detail Texture on IRIX 6.2: OpenGL detail texture through IRIS Performer 2.0 was not functional when running under 6.2. o OpenGL Texture Loading on RealityEngine: In IRIS Performer 2.0 running under OpenGL on RealityEngine graphics, texture had to be explicitly enabled for a texture to be successfully loaded. This is now handled internally by IRIS Performer. o Video Clock Timing: video clock timing in IRIS Performer 2.0 was often slightly off. o pfdLoadFile_flt: The FLT loader under IRIS Performer 2.0 64bit operation may core dump on textures. o pfMergeBuffer core dump in clean() when creating children before parents: IRIS Performer 2.0 could core dump after pfMergeBuffer() if child nodes in the asynchronous process were created before their parents. o pfDrawBin core dump: pfDrawBin() in IRIS Performer 2.0 will core dump if called on an empty bin. o IRIS GL windows had no stereo buffers: pure IRIS GL windows would not be configured with stereo buffers with pfWinFBConfigAtrrs() even if the PFFB_STEREO token was present in the attribute array. o IRIS GL window queries were broken: some of the window config queries for pfQueryWin() would always return 0 for pure IRIS GL windows. o Resizing of pfPipeWindows when multi-processed and using X windows (IRIS GLX or OpenGL/X) when an alternate framebuffer configuration window is selected (such as the fill statistics window in OpenGL/X perfly) has been fixed. In IRIS Performer 2.0 this could channel viewports to be confused when the alternate framebuffer configuration window is de-selected (such as disabling the fill statistics in perfly when running with X windows). o pfAlphaFunc had no effect if PFSTATE_ENLIGHTING is being overridden o pfMatrix::getOrthoCoord\f1: Performer2.0 it gave bad roll when pitch was +-90. o C++ perfly error\f1: In the C++ perfly and related programs, on multipipe machines, all windows get opened on pipe 0. The fix is swapping lines 419 and 420 in perf/sample/apps/C++/common/generic.C. o Intersections with PFGS_POLYS could cause core dumps in Performer2.0 o Memory corruption by extending pfStrings by 1 character o Bad malloc for names of pfFontss could potentially cause a core dump in Performer2.0. o Order of pfBuffer commands executed by pfMergeBuffer() is reversed in 2.0 Problems to be fixed in later patch for 2.0: o Asynchronous pfDelete of data of data allocated off the heap and not in shared memory could cause core dump. o OpenGL textures with VIDEO and FRAMEBUFFER sources do not work in 2.0 o pfFlatten on indexed pfGeoSets may dump for in 2.0 -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Sat Apr 27 01:16:09 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA20937; Fri, 26 Apr 1996 23:28:47 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA20934; Fri, 26 Apr 1996 23:28:43 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA09642; Fri, 26 Apr 1996 23:28:42 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id XAA06520; Fri, 26 Apr 1996 23:28:36 -0700 Received: from kid.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA02181; Fri, 26 Apr 96 23:27:54 -0700 Received: from localhost by kid.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) id XAA27414; Fri, 26 Apr 1996 23:27:14 -0700 Message-Id: <199604270627.XAA27414@kid.asd.sgi.com> To: "Dewey Anderson" Cc: info-performer@sgi.sgi.com, shui@kid.asd.sgi.com Subject: Re: movietex and OpenGL In-Reply-To: Your message of "Fri, 26 Apr 96 18:10:37 PDT." <9604261810.ZM24287@snowmass> Date: Fri, 26 Apr 96 23:27:13 -0700 From: Simon Hui Status: O Hi, there is a bug in performer that prevented video texturing from working with OpenGL; that's why you get the white rectangle. That bug, plus the bugs in the movietex.c program itself, was fixed in Performer 2.1, and are also fixed in the upcoming patch to Performer 2.0.1. Simon Hui > From: "Dewey Anderson" > Subject: movietex and OpenGL > > I've had some trouble trying to get movietex to work with OpenGl. (I > haven't tried IGL.) This is on an Onyx REII, Performer 2.0, IRIX 5.3. From guest Sat Apr 27 01:43:18 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA20958; Fri, 26 Apr 1996 23:56:27 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA20955; Fri, 26 Apr 1996 23:56:23 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA10250; Fri, 26 Apr 1996 23:56:23 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id XAA07691; Fri, 26 Apr 1996 23:56:18 -0700 Received: from sixty.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA02557; Fri, 26 Apr 96 23:54:42 -0700 Received: by sixty.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id XAA27557; Fri, 26 Apr 1996 23:49:29 -0700 From: "Javier Castellar" Message-Id: <9604262349.ZM27555@sixty.asd.sgi.com> Date: Fri, 26 Apr 1996 23:49:28 -0700 In-Reply-To: "John Archdeacon" "OpenGVS Cross Platform API" (Apr 17, 1:18pm) References: <199604172008.NAA25916@gemtech.gemtech.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "John Archdeacon" , "Performer News" Subject: Re: OpenGVS Cross Platform API Cc: jburwell@sixty.asd.sgi.com, javier@sixty.asd.sgi.com, judithp@sixty.asd.sgi.com, mtj@sixty.asd.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 17, 1:18pm, John Archdeacon wrote: > Subject: OpenGVS Cross Platform API > REGARDING OpenGVS Cross Platform API 4/17/96 10:58 > >Gemini has had a paper entitled "RealWorld Benchmarks for Workstation and PC >Computer Image Generation Systems" accepted at the upcoming Image Society >meeting in June (Arizona) which largely addresses this issue. Gemini has >proposed a new benchmark system for computer image generation (CIG) application >developers which will allow end users to compare the relative performance of >3-D graphics systems under identical "realworld" application and database >workload (on or off SGI systems). The OpenGVS test suite environment makes >this possible as it runs on top of OpenGL (like Performer does) as well as >other low level rendering engines (e.g., Direct3D). In my opinion your test suit will show *YOUR* software perfomance across the different IGs, NOT the perfomance of the IGs themselves. I know that your company have very strong skills on SGI and this makes your SGI OpenGVS implementation very interesting but if you are using OpenGL instead of Performer for the SGI-OpenGVS it means that you are taking a trade off of easy portability versus perfomance. If your SGI-OpenGVS were running on top of libpr i could accept that the pure rendering speed (after substracting all the culling-LOD-App host load due to OpenGVS) will be a good representation of the SGI IG speed but since you are using OpenGL i may say that is not 100% sure that you are getting the top rendering perfomance for most of the databases. If you are running the benchmarks in single CPU (as it seems to be after speaking with Judith Pafford) you are adding a distorting factor since VisSim perfomance is not only graphics perfomance (you are adding your software propietary culling-lod perfomance on top of the IG measure). > The test suite as proposed will include a flight simulation stress test, a >race car test, and a tank simulation environment test. The paper itself will >shortly be published on the WEB at http://www.gemtech.com. Gemini has received >favorable comments from some hardware manufacturers who are interested in >officially endorsing the test suite. I have incorporated good commments as >well from SGI (Judith Pafford). The results of tests will be published in June >or July on our WEB site. My PERSONAL opinion (and vote) is that SGI should not take your test suit as a valid comparison of SGI versus other IGs since is based on OpenGL GVS implementation instead of Performer. Beside this fact your test suit is a very interesting reference as an example of OpenGVS application perfomance on OpenGL that could be in some way be extrapolated to a well written OpenGL implementation in VisSim databases. Another issue is the support for SGI specific features for iR that are only available using performer, some of this features help a lot in order to fully use the "fast path" of our IGs. >... > > >-- End of excerpt from John Archdeacon -- ************************************************************************* * Javier Castellar Arribas * Email: javier@asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetent" Hari Seldon From guest Sat Apr 27 12:35:22 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA22399; Sat, 27 Apr 1996 10:58:51 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA22396; Sat, 27 Apr 1996 10:58:50 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA25457; Sat, 27 Apr 1996 10:58:50 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA02224; Sat, 27 Apr 1996 10:58:45 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA12310; Sat, 27 Apr 96 10:58:20 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA11908; Sat, 27 Apr 1996 10:57:21 -0700 From: "Sharon Clay" Message-Id: <9604271057.ZM11906@rose.asd.sgi.com> Date: Sat, 27 Apr 1996 10:57:21 -0700 In-Reply-To: Simon Hui "Re: movietex and OpenGL" (Apr 26, 11:27pm) References: <199604270627.XAA27414@kid.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: Simon Hui , "Dewey Anderson" Subject: Re: movietex and OpenGL Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 26, 11:27pm, Simon Hui wrote: > Subject: Re: movietex and OpenGL ->From guest@holodeck.csd.sgi.com Sat Apr 27 02:17:13 1996 ->To: "Dewey Anderson" ->Cc: info-performer@sgi.sgi.com, shui@kid ->Subject: Re: movietex and OpenGL ->In-Reply-To: Your message of "Fri, 26 Apr 96 18:10:37 PDT." -> <9604261810.ZM24287@snowmass> ->Date: Fri, 26 Apr 96 23:27:13 -0700 ->From: Simon Hui -> ->Hi, there is a bug in performer that prevented video texturing from working ->with OpenGL; that's why you get the white rectangle. That bug, plus the bugs ->in the movietex.c program itself, was fixed in Performer 2.1, and are also ->fixed in the upcoming patch to Performer 2.0.1. FYI, 2.0.1 was just our internal way to refer to the DSOs that we release with 6.2. The patch will cover anyone who has 2.0. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Sat Apr 27 12:48:02 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA22415; Sat, 27 Apr 1996 11:12:42 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA22412; Sat, 27 Apr 1996 11:12:34 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA25839; Sat, 27 Apr 1996 11:12:33 -0700 Received: from ligsg26.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA02740; Sat, 27 Apr 1996 11:12:31 -0700 Received: by ligsg26.epfl.ch (Smail3.1.29.1 #28) id m0uDETt-0003IGC; Sat, 27 Apr 96 20:12 MDT From: "Fernando D. Mato Mira" Message-Id: <9604272012.ZM17872@lig.di.epfl.ch> Date: Sat, 27 Apr 1996 20:12:29 -0600 In-Reply-To: "Javier Castellar" "(II) OpenPf & Vis/Sim outside SGI" (Apr 26, 10:54pm) References: <199604161713.LAB10780@xmission.xmission.com> <9604262254.ZM27519@sixty.asd.sgi.com> X-Face: +(HrN.)~49u8-TQ;yV?v]-KFW;TEu3C_S,.lR,i&33X*C#G/`fPOnfi=W}(Y8CZ]7uV7W_Y z~F2isE!U%t1rR.\Jc{VO&Of.i;p%BD/X~^5+M5"_:xM\x@Wjced&{)\`IwrTAPLGSz:N}UDE`)6oR ~FgQP}#==%Jva9'}x1EjeONjHN&:ML3ad'`JI, info-performer@sgi.sgi.com Subject: Re: (II) OpenPf & Vis/Sim outside SGI Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 26, 10:54pm, Javier Castellar wrote: > You are right, SGI did not invented VisSim but a lot of people who work here > did in some percent in SGI, E&S, L-M, Star, ... etc. > > What SGI maybe did was to reinvent it. No `reinvent' is a pejorative term which applies to C++, reference counting, Fix+Continue, DSOs/DLLs, dumb Desktop Manager that restarts applications in ridiculous initial states, some hyped Java features, etc. When it comes to _hardware_ SGI invented a lot of things. Same for graphic APIs. From guest Sat Apr 27 13:15:02 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA22449; Sat, 27 Apr 1996 11:38:39 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA22446; Sat, 27 Apr 1996 11:38:38 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA26534; Sat, 27 Apr 1996 11:38:38 -0700 Received: from palladium.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA03829; Sat, 27 Apr 1996 11:38:37 -0700 Received: from isdn-celeste.corp.sgi.com by palladium.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for <@palladium.corp.sgi.com:info-performer@sgi.com> id LAA02257; Sat, 27 Apr 1996 11:38:35 -0700 Received: by isdn-celeste.corp.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id LAA01295; Sat, 27 Apr 1996 11:37:16 -0700 Date: Sat, 27 Apr 1996 11:37:16 -0700 From: mtj@isdn-celeste.corp.sgi.com (Michael Jones) Message-Id: <199604271837.LAA01295@isdn-celeste.corp.sgi.com> To: info-performer@sgi.sgi.com Subject: Performer Update Status: O Reviewing the last week's info-performer email, I can't help but respond to the emails announcing IRIS Performer 2.1, contemplating SGI's role in vis-sim, especially with respect to other workstation companies, discussing benchmarking techniques for IG's, talking about OpenGVS, and asking about the potential for an open Performer. This will be long but there's a surprise at the end, so hopefully it will be worth waiting for (but NO peeking, that would be cheating. ;-) Michael Jones IRIS PERFORMER 2.1 As Sharon explained yesterday, IRIS Performer 2.1 has released and is now available. Those who noticed that the 2.0 release tool a bit longer than planned might be surprised that 2.1 was done so soon. There are significant new features for InfiniteReality users that will amaze you. This version of Performer (which is the partner of InfiniteReality) supports the creation of the most sophisticated applications in the history of visual simulation. SIMULATION CREDIT AND HISTORY Speaking of the history of visual simulation, General Electric Co. invented the computer graphic image generator (IG) in the 1960's and NASA was the deep-pockets customer sponsoring the work. I have a great deal of respect for those early GE engineers and want to make sure they're credited where credit is due. In fact, we've made a point of listing the contributions of these pioneers (and the work at Evans & Sutherland, Link/Sunnyvale, Thomson, etc.) in our SIGGRAPH course "Real-Time Graphics for Entertainment" for the past two years. What SGI did was to find a way to use aggressive technology, rapid product cycles, clever approaches, and a commercial business model (rather than the military contractor style) to reinvent the image generator industry. Our machines, such as the InfiniteReality, are faster, more capable, and less expensive by far (in all three areas!) than those of the Ancien Regime. A trip to a visual simulation trade show such as the recent ITEC show in Holland, IMAGE, or I/ITSEC makes the point very clearly: the tables have turned in visual simulation and it's the early pioneers that are now trying to catch-up. If you were at ITEC and disagree (or agree) please say so. COMPETITIVE WORKSTATIONS Now, as far as HP, SUN, DEC, and IBM, are concerned, it's a very different story. None have products that pose a challenge to SGI, E&S, GE (sold to Loral, then Martin, then Lockheed), CAE, or any other visual simulation provider. Perhaps you might argue that some non-SGI workstation (or high-end PC) is good enough for your database modeling needs, but there is no chance of a SparcStation (or Windows NT Intergraph) providing the visual simulation needs of the F-117 stealth fighter trainer, the German ICE train simulator, or thousands of the other demanding Onyx/RE/Performer applications. This is not arrogance. All of these companies have capable engineers who may be building *future* products to compete in these spaces. Time will tell (but the same is true for SGI -- companies who aim directly at our moving target will miss.) IMAGE GENERATOR BENCHMARKS John Archdeacon of Gemini Technologies sent out email describing the portability and openness of his product, OpenGVS. Most interestingly, he discussed a benchmark suite his company has developed. I think that this is a great idea! While it's always difficult to reduce complex ensembles down to a single virtue number (SPECmark, MPG, and so on), more data can only help. The only problem that I see is the fact that the metric of such tests is not "Virtue of Machine X" but rather "Virtue of Machine X running software Y". This is fine as long as it's marked clearly. The Gemini IG test suite will serve as an interesting benchmark since it's open, in the following ways: 1. It can be run on multiple machines using OpenGVS. It would be a way to verify and judge implementation and hardware. This is the test that a GVS user would want to make, since it is a measure of virtue for the range of available options. 2. It can be run using multiple software libraries (OpenGVS, dVS, VistaWorks, SENSE8, Performer, etc.) on the same machine and database. This is what an SGI user would want to test since it is a measure of virtue for the range of available options. An undecided user (not committed to either Gemini or SGI) would want to examine the results of these tests for the full matrix of results and the prices of the configurations. Now I see the wisdom of Gemini's approach. Hardware vendors would shy away from #1 based on experiences where poor software implementations make their machine look bad, but this fear is resolved by test #2, which validates the benchmark by showing how well the machine can solve the stated problem. If there is a major difference between the results of test #1 for a given machine and test #2 on that same system, then the meaning will be clear. Based on this, I'm eager to get the Gemini Technology test suite and have the Performer team get it up and running. If we can get it here at SGI in time, we can have numbers for test #2 in time for John Archdeacon's presentation at the Image Society meeting in June. We'll post the results here on the mailing list after that. I'll get with Gemini next week to get this started and see if it also includes both single and multiple channel and single and multiple processor tests. PERFORMER .VS OTHER TOOKITS This is the wrong question. Many other toolkits use IRIS Performer, some visibly, some not. We believe that SGI visual simulation and high-speed rendering customers are best served by Performer, but we have no reason to "slight" anyone who uses or sells an alternate product on SGI, or who places portability above all else so long as they know that that choice implies. For example, the Performer team has helped most non-Performer vis-sim partners tune to SGI over the years and have sent extracts from Performer source code where that made sense. SGI appreciates it's partners and customers and has no reason to engage in a debate about product merits. (Though I must admit that the Gemini Technology posting has made me anxious to see the results of tests #1 and #2 on SGI machines, but in a friendly way. :-) THE DESIRE FOR A PORTABLE PERFORMER IRIS Performer is much like IRIS GL in that it has grown up along with increasing hardware capabilities and diverging application scopes. This all comes from user experiences and the growing performance levels of new machines, CPUs, and graphics systems. This leads to a very capable but (perhaps) awkward and eclectic set of features. Moving from this state to a highly portable situation while retaining the features that make a product great requires much reevaluation and analysis. It's a difficult task. This is how OpenGL was created and is what would be needed to create the open, portable performer that people have been asking for here in the mailing list and elsewhere. People like carter@eai.com who are interested in openness issues, who want to understand the SGI software strategy and development road-map for IRIS Performer, OpenInventor, and the ImageVision library, or who seek answers to issues such as portability to other workstations, PCs, Java, and distributed WEB graphics, will find many answers at the Silicon Graphics Developer's Forum this year (Forum info available at http://www.sgi.com). Both Jim Helman and I will be making detailed presentations on these issues and the news should please you (that's the surprise I mentioned before ;-), but we are not free to disclose details of our presentations before the Forum. Be seeing you, Phone:415.390.1455 Fax:415.965.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 "Competition is a by-product of productive work, not its goal. A creative man is motivated by the desire to achieve, not by the desire to beat others." -Ayn Rand From guest Sat Apr 27 13:29:15 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA22461; Sat, 27 Apr 1996 11:53:38 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA22458; Sat, 27 Apr 1996 11:53:33 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA26889; Sat, 27 Apr 1996 11:53:32 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA04402; Sat, 27 Apr 1996 11:53:31 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA13462; Sat, 27 Apr 96 11:53:19 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id LAA12038; Sat, 27 Apr 1996 11:52:58 -0700 From: "Sharon Clay" Message-Id: <9604271152.ZM12036@rose.asd.sgi.com> Date: Sat, 27 Apr 1996 11:52:58 -0700 In-Reply-To: "Julia Kossack" "terrain paging" (Apr 8, 3:50pm) References: <9604081550.ZM21599@westside.corp.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Julia Kossack" , info-performer@sgi.sgi.com Subject: Re: terrain paging Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 8, 3:50pm, Julia Kossack wrote: > Subject: terrain paging ->From guest@holodeck Mon Apr 8 16:10:54 1996 ->From: "Julia Kossack" ->Date: Mon, 8 Apr 1996 15:50:04 -0700 ->X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) ->To: info-performer@sgi.sgi.com ->Subject: terrain paging -> ->Hello Performer team, -> ->Larry McDonough referred me to you regarding this question we received on the ->Fastline: -> ->"Does performer 2.0 support Terrain Paging? Not quite yet. IRIS Performer2.1 for InfiniteReality has an adaptive surface definition terrain library that currently supports smooth transition of terrain LODs through morphing, and handles other issues that arise with morphing terrain when you want to plant objects (such as roads and houses) on it. We will soon make this library available to folks with Performer2.0. Paging of terrain will be directly supported in the next release. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Sat Apr 27 14:03:27 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA22493; Sat, 27 Apr 1996 12:28:18 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA22490; Sat, 27 Apr 1996 12:28:18 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA27839; Sat, 27 Apr 1996 12:28:17 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA05970; Sat, 27 Apr 1996 12:28:16 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA13998; Sat, 27 Apr 96 12:27:35 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id MAA12349; Sat, 27 Apr 1996 12:27:14 -0700 From: "Sharon Clay" Message-Id: <9604271227.ZM12347@rose.asd.sgi.com> Date: Sat, 27 Apr 1996 12:27:13 -0700 In-Reply-To: "Luis Ignacio Miranda" "Inventor loader problem" (Apr 11, 10:10pm) References: <9604112210.ZM29987@buitre.madrid.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Luis Ignacio Miranda" , info-performer@sgi.sgi.com Subject: Re: Inventor loader problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 11, 10:10pm, Luis Ignacio Miranda wrote: > Subject: Inventor loader problem ->From guest@holodeck Thu Apr 11 14:06:20 1996 ->From: "Luis Ignacio Miranda" ->Date: Thu, 11 Apr 1996 22:10:15 -0600 ->X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) ->To: info-performer@sgi.sgi.com ->Subject: Inventor loader problem -> ->Hi all, -> ->I have a problem with the Inventor loader in Performer 2.0. -> ->When I try to load a model with a environment-reflecting texture, it loads the ->texture, but it is not applied to the model, or, it is not applied in the right ->way because the model does not show the texture. -> ->I attach a very simple inventor with a environment-reflecting texture model as ->an example. -> ->Any ideas? Ok, one that I forgot in my my 2.0 bug list... Reflection mapping was broken for OpenGL in the Inventor loader. FYI, libpfdu:pfdCallbacks.c had a texgen handling bug with OpenGL specification of the reference plane for EYE_LINEAR and OBJECT_LINEAR. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Sat Apr 27 15:43:02 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA22891; Sat, 27 Apr 1996 14:09:39 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA22888; Sat, 27 Apr 1996 14:09:34 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA00334; Sat, 27 Apr 1996 14:09:34 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA10049; Sat, 27 Apr 1996 14:09:33 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA15541; Sat, 27 Apr 96 14:09:23 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id OAA12856; Sat, 27 Apr 1996 14:09:07 -0700 From: "Sharon Clay" Message-Id: <9604271409.ZM12854@rose.asd.sgi.com> Date: Sat, 27 Apr 1996 14:09:07 -0700 In-Reply-To: deepa@tcsernet.tcs.ernet.in "Lights" (Apr 26, 4:45pm) References: <9604262033.AA22075@tcsernet.tcs.ernet.in> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: deepa@tcsernet.tcs.ernet.in, info-performer@sgi.sgi.com Subject: Re: Lights Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19604271409.ZM12854.asd.sgi.com" Status: O -- --PART-BOUNDARY=.19604271409.ZM12854.asd.sgi.com Content-Type: text/plain; charset=us-ascii Hi, What version of Performer were you using? What OS was on the respective machines? Also, by any chance was this IRIS GL? +>---- On Apr 26, 4:45pm, deepa@tcsernet.tcs.ernet.in wrote: > Subject: Lights ->From guest@holodeck.csd.sgi.com Fri Apr 26 10:54:06 1996 ->From: deepa@tcsernet.tcs.ernet.in ->Subject: Lights ->To: info-performer@sgi.sgi.com ->Date: Fri, 26 Apr 96 16:45:12 EDT ->X-Mailer: ELM [version 2.3 PL2] -> ->Dear Performer users, -> ->I wrote a very simple program to draw one polygon, map a texture ->on it and rotate it in a loop. I defined colors for the vertices ->and set the the shade model as Gouraud shading model. One light was set, ->and a default light model applied. ->The program was compiled on the onyx and executed with the display set ->to Indy, Indigo and the onyx respectively. The program works perfectly on ->the onyx, but exits without displaying on the indigo (2 extreme) and ->on the indy the whole scene appears white at first and gradually dims to ->gray as the object rotates away from the light (on the onyx, the background ->which is black is not affected and the lighting only affects the object). -> ->Why does this happen? Can anyone help? -> ->Deepa Krishnan ->Tata Consultancy Services ->deepa@tcsernet.tcs.ernet.in -> +>---- End of excerpt from deepa@tcsernet.tcs.ernet.in -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ --PART-BOUNDARY=.19604271409.ZM12854.asd.sgi.com Content-Description: Message from deepa@tcsernet.tcs.ernet.in Content-Type: message/rfc822 Received: from giraffe.asd.sgi.com by rose.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA03614; Fri, 26 Apr 1996 10:54:05 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for src@rose.asd.sgi.com id AA00481; Fri, 26 Apr 96 10:54:00 -0700 Received: from giraffe.asd.sgi.com by rose.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA03609; Fri, 26 Apr 1996 10:53:57 -0700 Received: from holodeck.csd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for srf@rose.asd.sgi.com id AA00463; Fri, 26 Apr 96 10:53:49 -0700 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA17018; Fri, 26 Apr 1996 08:25:02 -0700 Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA17015; Fri, 26 Apr 1996 08:24:58 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA29098; Fri, 26 Apr 1996 08:24:57 -0700 Received: from tcsernet.tcs.ernet.in by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA03318; Fri, 26 Apr 1996 07:53:55 -0700 From: deepa@tcsernet.tcs.ernet.in Message-Id: <9604262033.AA22075@tcsernet.tcs.ernet.in> Subject: Lights To: info-performer@sgi.sgi.com Date: Fri, 26 Apr 96 16:45:12 EDT Content-Length: 815 Content-Type: text X-Mailer: ELM [version 2.3 PL2] Dear Performer users, I wrote a very simple program to draw one polygon, map a texture on it and rotate it in a loop. I defined colors for the vertices and set the the shade model as Gouraud shading model. One light was set, and a default light model applied. The program was compiled on the onyx and executed with the display set to Indy, Indigo and the onyx respectively. The program works perfectly on the onyx, but exits without displaying on the indigo (2 extreme) and on the indy the whole scene appears white at first and gradually dims to gray as the object rotates away from the light (on the onyx, the background which is black is not affected and the lighting only affects the object). Why does this happen? Can anyone help? Deepa Krishnan Tata Consultancy Services deepa@tcsernet.tcs.ernet.in --PART-BOUNDARY=.19604271409.ZM12854.asd.sgi.com-- From guest Sat Apr 27 23:41:05 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id WAA23645; Sat, 27 Apr 1996 22:08:01 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id WAA23642; Sat, 27 Apr 1996 22:08:01 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id WAA10575; Sat, 27 Apr 1996 22:08:00 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id WAA26096; Sat, 27 Apr 1996 22:07:59 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA23008; Sat, 27 Apr 96 22:07:39 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id WAA13551; Sat, 27 Apr 1996 22:07:26 -0700 From: "Sharon Clay" Message-Id: <9604272207.ZM13549@rose.asd.sgi.com> Date: Sat, 27 Apr 1996 22:07:26 -0700 In-Reply-To: "Sharon Clay" "Re: terrain paging" (Apr 27, 11:52am) References: <9604081550.ZM21599@westside.corp.sgi.com> <9604271152.ZM12036@rose.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Julia Kossack" , info-performer@sgi.sgi.com Subject: Re: terrain paging - correction! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I was thinking way toooo Performer2.1 centric when I answered this the first time so I wanted to correct/clarify: +>---- On Apr 27, 11:52am, Sharon Clay wrote: > Subject: Re: terrain paging ->->"Does performer 2.0 support Terrain Paging? -> ->Not quite yet. ->IRIS Performer2.1 for InfiniteReality has an adaptive surface definition terrain ->library that currently supports smooth transition of terrain LODs through morphing, ->and handles other issues that arise with morphing terrain when you want to ->plant objects (such as roads and houses) on it. ->We will soon make this library available to folks with ->Performer2.0. Paging of terrain will be directly supported in the ->next release. -> I was thinking soly in the context of the specific new advanced terrain support in IRIS Performer2.1. However, as most on this list already know, terrain can most definitely be efficiently rendered and paged with the general LOD and database paging facilities IRIS Performer 2.0. I am just so excited about the new Active Surface Definition library that I got a little carried away :-) Back to normal programming, src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Sun Apr 28 03:03:42 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA23973; Sun, 28 Apr 1996 01:28:59 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA23970; Sun, 28 Apr 1996 01:28:59 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA15563; Sun, 28 Apr 1996 01:28:58 -0700 Received: from cordoba.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA01562; Sun, 28 Apr 1996 01:28:56 -0700 Received: by cordoba.reading.sgi.com (940816.SGI.8.6.9/940406.SGI) for info-performer@sgi.com id JAA11259; Sun, 28 Apr 1996 09:28:54 +0100 From: "Greg Edwards, SGI UK." Message-Id: <9604280928.ZM11257@cordoba.reading.sgi.com> Date: Sun, 28 Apr 1996 09:28:54 +0100 Reply-To: gedwards@reading.sgi.com X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Formatting of perfly code Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Can the team inform me what formatter is used on perfly and other Pf example source. It's not my favourite style, but better to stick with it than scrmable the whole thing and defeat xdiff etc. -- __________________________________________________________________________ Greg Edwards, Graphics Support/Consulting Group, Silicon Graphics UK Ltd. Forum 1, Theale, Reading, UK, RG7 4RA. tel +44 1734 257500, direct +44 1734 257740, fax +44 1734 257553 gedwards@reading.sgi.com, US vmail 59130, UK vmail 7740#, mailstop IUK-311 From guest Sun Apr 28 10:03:34 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA24418; Sun, 28 Apr 1996 08:18:18 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA24415; Sun, 28 Apr 1996 08:18:17 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA23323; Sun, 28 Apr 1996 08:18:17 -0700 Received: from palladium.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA11602; Sun, 28 Apr 1996 08:18:16 -0700 Received: from isdn-celeste.corp.sgi.com by palladium.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/911001.SGI) for <@palladium.corp.sgi.com:info-performer@sgi.sgi.com> id IAA12040; Sun, 28 Apr 1996 08:18:15 -0700 Received: by isdn-celeste.corp.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.sgi.com id IAA01074; Sun, 28 Apr 1996 08:16:51 -0700 Date: Sun, 28 Apr 1996 08:16:51 -0700 From: mtj@isdn-celeste.corp.sgi.com (Michael Jones) Message-Id: <199604281516.IAA01074@isdn-celeste.corp.sgi.com> To: info-performer@sgi.sgi.com Subject: RE: Formatting of perfly code Status: O Greg Edwards writes: :Can the team inform me what formatter is used on perfly and other :Pf example source. It's not my favourite style, but better to :stick with it than scrmable the whole thing and defeat xdiff etc. Not your favorite indent, bracket, comment, etc style? Well, as you know there's no pleasing everybody with a coding style. What we did early on was to agree on a style that has nothing that any Performer development team member hated and which seemed generally OK to us. We used the Allman style of brace structuring, which was the not quite universal vote. The formatting is not automatic. Low-tech as it may seem to you, we formatted most of the 585,841 lines (in 1274 files) of IRIS Performer source code by hand. (These stats are by way of find, xargs, and wc, and were computed just now). Back at the time we were discussing the formatting, I bought and read a book that I find to be really great on this subject. It is "C Style: Standards and Guidelines" by David Straker (of Hewlett-Packard, the laser printer company) and is an excellent exposition of popular alternatives and the rationale for and against each. If this topic interests you, I highly recommend it. There's really little in the book about C itself, so it's equally well a C++ style discussion too. Michael Be seeing you, Phone:415.390.1455 Fax:415.965.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 "Competition is a by-product of productive work, not its goal. A creative man is motivated by the desire to achieve, not by the desire to beat others." -Ayn Rand From guest Mon Apr 29 00:44:22 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA25236; Sun, 28 Apr 1996 23:14:14 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA25233; Sun, 28 Apr 1996 23:14:10 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA12063; Sun, 28 Apr 1996 23:14:10 -0700 Received: from storm.certix.fr by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id XAA18268; Sun, 28 Apr 1996 23:14:04 -0700 Received: from nantes0-024.sct.fr (nantes0-024.sct.fr [194.206.158.24]) by storm.certix.fr (8.6.12/8.6.12) with SMTP id IAA01544 for ; Mon, 29 Apr 1996 08:09:44 +0200 Message-Id: <199604290609.IAA01544@storm.certix.fr> X-Sender: ceti@worldnet.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Apr 1996 07:14:50 +0100 To: info-performer@sgi.sgi.com From: ceti@worldnet.net (ceti) Subject: pfMorph and iv loader X-Mailer: Status: O Well, I have two geometries built using Explore ( wavefront ), converted in iv file format. Geometries are same, just shapes are change . I use pfLoadFile to load them and I want to morph from one to the second using morphing nodes. Here is the problem, when checking the two geosets, repartition of the vertex in the strips is not the same. GULP! So I assume that the iv loader tries (and may be succed) to optimise the object but here I want it to be dummy. Is there a way to avoid crossing optimising step or should I write a dummy loader ?? thanks /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ < _/_/ _/ _/_/_/ _/ _/ _/_/_/ _/_/_/ _/_/_/ > < _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ > < _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ _/ > < _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ > < _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ > < _/_/ _/_/_/ _/_/_/ _/ _/_/_/ _/_/_/ _/ _/ > < > < BILLARD Olivier - Ingeneer R&D @ C&I Software > < 1 avenue de la mer - 44380 PORNICHET - FRANCE > < Tel: +33 40 11 68 72 Fax: +33 140 61 68 14 > < Email: ceti@worldnet.net > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From guest Mon Apr 29 03:52:41 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA25558; Mon, 29 Apr 1996 02:18:35 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA25555; Mon, 29 Apr 1996 02:18:27 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA17329; Mon, 29 Apr 1996 02:18:26 -0700 Received: from alpha.luc.ac.be by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA26285; Mon, 29 Apr 1996 02:18:12 -0700 Received: from [193.190.10.11] by alpha.luc.ac.be; (5.65/1.1.8.2/28Jul95-1212AM) id AA07560; Mon, 29 Apr 1996 11:18:06 +0200 Sender: dnouls@luc.ac.be Message-Id: <31849740.6201@luc.ac.be> Date: Mon, 29 Apr 1996 12:17:36 +0200 From: David Nouls Organization: L.T.I. - E.D.M. X-Mailer: Mozilla 3.0b2 (X11; I; IRIX 5.3 IP22) Mime-Version: 1.0 To: info-performer@sgi.sgi.com Subject: 3DS importer with normals support wanted! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O Hello, Did anybody change the 3DS import filter to suppport normals ? I'm currently writing some code to support it, but I would rather spend my time on the main application than on writing import-filters. /)avid -- Expertisecentrum Digitale Media - Wetenschapspark 2 - B-3590 Diepenbeek Tel: +32-(0)11-268412 - Fax: +32-(0)11-268400 e-mail: dnouls@luc.ac.be dnouls@cbit.rma.ac.be we39833@vub.ac.be From guest Mon Apr 29 04:05:16 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA25606; Mon, 29 Apr 1996 02:31:52 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA25603; Mon, 29 Apr 1996 02:31:51 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA17651; Mon, 29 Apr 1996 02:31:51 -0700 Received: from kubrick.ethz.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA26822; Mon, 29 Apr 1996 02:29:22 -0700 Received: (from gramazio@localhost) by kubrick.ethz.ch (8.6.10/8.6.10) id JAA06013 for info-performer@sgi.sgi.com; Mon, 29 Apr 1996 09:31:15 GMT Date: Mon, 29 Apr 1996 09:31:15 GMT From: Fabio Gramazio Message-Id: <9604291131.ZM6011@kubrick.ethz.ch> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O unsubscribe From guest Mon Apr 29 04:19:31 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA25614; Mon, 29 Apr 1996 02:45:30 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA25611; Mon, 29 Apr 1996 02:45:22 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA17903; Mon, 29 Apr 1996 02:45:22 -0700 Received: from cluny.ensam.fr by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA27331; Mon, 29 Apr 1996 02:37:36 -0700 From: pere1@VIDEO3.cluny.ensam.fr Received: from VIDEO3.cluny.ensam.fr by cluny.ensam.fr (5.x/SMI-SVR4) id AA00927; Mon, 29 Apr 1996 10:59:45 +0100 Received: by VIDEO3.cluny.ensam.fr (940816.SGI.8.6.9/930416.SGI) id KAA21439; Mon, 29 Apr 1996 10:46:12 GMT Message-Id: <9604291046.ZM21437@VIDEO3.cluny.ensam.fr> Date: Mon, 29 Apr 1996 10:46:12 +0000 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: Shadows with Performer ? Cc: pere@cluny.ensam.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi I would like to render shadows with Performer.It seems that Performer has not any fonction to do that. So I look on the OpenGL Programming Guide, it is told how shadows work but there isn't any sample code. So I send a message (not in a bottle ...) Could somebody help me? My application is a 3D terrain with thousands trees (yes, it is possible!). For the moment I duplicate all the facets on the forest terrain with a opacity mapping of a shadow image. It works well but it isnt the economical version. I am looking for: 1) A sample code of how to render shadows of one object to another or 2) A sample code of how to map an image (shadow image for example) on a projector Thanks you for your help ! -- login IRIX From guest Mon Apr 29 04:44:32 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id DAA25647; Mon, 29 Apr 1996 03:12:54 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id DAA25644; Mon, 29 Apr 1996 03:12:50 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id DAA18510; Mon, 29 Apr 1996 03:12:50 -0700 Received: from arl-img-7.compuserve.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id DAA28601; Mon, 29 Apr 1996 03:12:49 -0700 Received: by arl-img-7.compuserve.com (8.6.10/5.950515) id GAA09624; Mon, 29 Apr 1996 06:12:47 -0400 Date: 29 Apr 96 06:10:24 EDT From: Werner Hartinger <101573.3267@CompuServe.COM> To: performer Subject: pfLPointState viewing distance Message-ID: <960429101024_101573.3267_IHK84-1@CompuServe.COM> Status: O Hi there, can anyone tell me, why my pfLPointState-points disappear ? I use pfLPointState for my light-points. That basically works. But, as soon as I move further than about 1200 meters away, they disappear. First they have a size of 3 pixels, then they are gone. Now the thing I don't understand: IN ANOTHER, SMALL TEST-APPLICATION, THESE VALUES WORK !!!! That means, the values above must be okay, as I can see the lights from a much bigger distance than 1200 meters ! I've written down the mode values: Size Mode : 1 ON Transp Mode : 1 ON Transp Pixel Size: 1.000000 Transp Pixel Exponent: 1.000000 Transp Scale: 0.100000 Transp Clamp: 0.500000 Fog Mode : 1 ON Dir Mode : 1 ON Shape Mode : 0 UNI shape values: fHor 180.00 vert 180.00 roll 0.00 fall 1.00 amb 0.00 Range Mode : 1 TRUE Min Pixel Size: 3.000000 Max Pixel Size: 5.000000 act. real world: 0.100000 fog scale: 0.250000 intensity: 1.000000 diff_thresh: 0.100000 What values can there be else ? I hope someone can help. Thanks, Werner ---------------------------------------------------------- Werner Hartinger Tel. 049-89-8899-2744 Krauss-Maffei AG Fax. 049-89-8899-4104 Krauss-Maffei-str. 2 D-80997 Munich GERMANY ---------------------------------------------------------- From guest Mon Apr 29 08:24:21 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id GAA26248; Mon, 29 Apr 1996 06:50:25 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id GAA26245; Mon, 29 Apr 1996 06:50:17 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id GAA24351; Mon, 29 Apr 1996 06:50:16 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id GAA11175; Mon, 29 Apr 1996 06:50:14 -0700 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA11932; Mon, 29 Apr 1996 09:45:44 -0400 Received: by eagle.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) id JAA22301; Mon, 29 Apr 1996 09:47:57 -0400 From: "Bernard Leclerc" Message-Id: <9604290947.ZM22299@eagle.cae.ca> Date: Mon, 29 Apr 1996 09:47:53 -0400 In-Reply-To: "Javier Castellar" "Re: Onyx Infinite Reality vof's" (Apr 26, 8:11pm) References: <9604261038.ZM14974@eagle.cae.ca> <9604261107.ZM2265@pxp.stlaurent.sgi.com> <9604261121.ZM15135@eagle.cae.ca> <9604261207.ZM2364@pxp.stlaurent.sgi.com> <9604261615.ZM15946@eagle.cae.ca> <9604262011.ZM27415@sixty.asd.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Javier Castellar" , info-performer@sgi.sgi.com Subject: Re: Onyx Infinite Reality vof's Cc: gilroy@stlaurent.sgi.com (Gilles Roy - SGI Account Manager), parviz@stlaurent.sgi.com (Parviz Parandeh - SGI System Engineer) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 26, 8:11pm, Javier Castellar wrote: > There is not a video/frame buffer limitation in your case (with 2 RM6 you > could get three 1024x768 with 8 subsamples AA), the limitation is on the > pixel fill, this is why Parviz configured a 4 RM6 machine: > > DC = 4 > > 1024 x 2304 x 4 x 60 = 576 Mtexels/s ===> 4 RM6 > > ( if your system is 60hz) Javier, Parviz, My system is supposed to run at 30 Hz. It means I need 288 Mtexels/s. The specs I have says one RM6 can fill up to 200 Mtexels/s. So I should Ok with 2 RM6. Is it correct? -- ___/ | ___/ Bernard Leclerc e-mail: bleclerc@cae.ca / / | / Systems Engineer voice: +1 514 341 2000 / / | __/ CAE Electronics Ltd. extension 2275 / / | / 8585 Cote De Liesse fax: +1 514 340 5496 / ____ | / P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Mon Apr 29 09:01:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA26282; Mon, 29 Apr 1996 07:29:13 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA26279; Mon, 29 Apr 1996 07:29:12 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA25417; Mon, 29 Apr 1996 07:29:12 -0700 Received: from binky.paradigmsim.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA14890; Mon, 29 Apr 1996 07:29:10 -0700 Received: by binky.paradigmsim.com (940816.SGI.8.6.9/921111.SGI.AUTO) for info-performer@sgi.sgi.com id JAA10568; Mon, 29 Apr 1996 09:28:29 -0500 From: "Craig Phillips" Message-Id: <9604290928.ZM10566@binky.paradigmsim.com> Date: Mon, 29 Apr 1996 09:28:27 -0500 In-Reply-To: "Javier Castellar" "Re: OpenGVS Cross Platform API" (Apr 26, 11:49pm) References: <199604172008.NAA25916@gemtech.gemtech.com> <9604262349.ZM27555@sixty.asd.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Performer News" Subject: Re: OpenGVS Cross Platform API Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I may be wrong, but i believe that most developers in the vissim world are far more interested in performance than portability. that is not to say that that it is not important, and that we would all like to write code only once, but given the choice, performance is king. It is tough too say to your customer or boss: "sure, it's only half as fast, but it also runs on a PC". They bought an SGI. They bought it for the performance. Performer was developed by some pretty talented folks to get the performance out of the machine and to provide those capabilities needed in the vissim community. I doubt that GVS can match the capabilities in Performer, given the trade-offs made for cross platform operation, but i would like to see them try. how about it John, is GVS better, faster than Performer? -- __________________________________________________ Craig Phillips CTO, Paradigm Simulation Inc. 14900 Landmark, Suite 400, Dallas, Texas 75248 craig@paradigmsim.com 214-960-2301 __________________________________________________ From guest Mon Apr 29 09:10:04 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id HAA26290; Mon, 29 Apr 1996 07:37:29 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id HAA26287; Mon, 29 Apr 1996 07:37:29 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id HAA25810; Mon, 29 Apr 1996 07:37:28 -0700 Received: from gate.ti.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA15784; Mon, 29 Apr 1996 07:37:27 -0700 Received: from lesol1.dseg.ti.com ([128.247.231.86]) by gate.ti.com (8.6.13/ac3i.dseg.ti.com) with ESMTP id JAA29690 for ; Mon, 29 Apr 1996 09:37:24 -0500 Received: from m2.dseg.ti.com (m2.dseg.ti.com [128.247.216.212]) by lesol1.dseg.ti.com (8.6.9/8.6.6) with SMTP id JAA12954 for ; Mon, 29 Apr 1996 09:36:53 -0500 Received: from mallbright.dseg.ti.com by m2.dseg.ti.com (4.1/SMI-4.1) id AA03478; Mon, 29 Apr 96 09:40:21 CDT Message-Id: <9604291440.AA03478@m2.dseg.ti.com> Comments: Authenticated sender is From: "Mike Allbright" To: info-performer@sgi.sgi.com Date: Mon, 29 Apr 1996 08:23:41 +0000 Subject: UNSUBSCRIBE X-Mailer: Pegasus Mail for Windows (v2.30) Status: O Please unsubscribe me from this mailing list. ******************************************************************************* Michael M. Allbright Texas Instruments m-allbright1@ti.com ******************************************************************************* From guest Mon Apr 29 10:13:25 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA26343; Mon, 29 Apr 1996 08:41:42 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA26338; Mon, 29 Apr 1996 08:41:38 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA28571; Mon, 29 Apr 1996 08:41:38 -0700 Received: from trout.nosc.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA24122; Mon, 29 Apr 1996 08:41:32 -0700 Received: from cod.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA28826; Mon, 29 Apr 96 08:41:31 PDT Received: by cod.nosc.mil (4.1/SMI-4.1) id AA28334; Mon, 29 Apr 96 08:39:20 PDT From: garrova@cod.nosc.mil (James F. Garrova) Message-Id: <9604291539.AA28334@cod.nosc.mil> Subject: Dynamic Terrain Paging To: info-performer@sgi.sgi.com Date: Mon, 29 Apr 1996 08:39:20 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 182 Status: O A representative from MultiGen mentioned a "pfb" format that is or soon will available to support dynamic terrain paging. Could you provide more information on this. Thanx. Jim From guest Mon Apr 29 11:44:46 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA27101; Mon, 29 Apr 1996 10:12:31 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA27096; Mon, 29 Apr 1996 10:12:22 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA03779; Mon, 29 Apr 1996 10:12:21 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA09825; Mon, 29 Apr 1996 10:12:19 -0700 Received: from remi.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA03010; Mon, 29 Apr 96 10:11:51 -0700 Received: by remi.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA11151; Mon, 29 Apr 1996 10:11:07 -0700 From: "Remi Arnaud" Message-Id: <9604291011.ZM11149@remi.asd.sgi.com> Date: Mon, 29 Apr 1996 10:11:06 -0700 In-Reply-To: "Bernard Leclerc" "Re: Onyx Infinite Reality vof's" (Apr 29, 9:47am) References: <9604261038.ZM14974@eagle.cae.ca> <9604261107.ZM2265@pxp.stlaurent.sgi.com> <9604261121.ZM15135@eagle.cae.ca> <9604261207.ZM2364@pxp.stlaurent.sgi.com> <9604261615.ZM15946@eagle.cae.ca> <9604262011.ZM27415@sixty.asd.sgi.com> <9604290947.ZM22299@eagle.cae.ca> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Bernard Leclerc" , "Javier Castellar" , info-performer@sgi.sgi.com Subject: Re: Onyx Infinite Reality vof's Cc: gilroy@stlaurent.sgi.com (Gilles Roy - SGI Account Manager), parviz@stlaurent.sgi.com (Parviz Parandeh - SGI System Engineer) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 29, 9:47am, Bernard Leclerc wrote: > Subject: Re: Onyx Infinite Reality vof's > My system is supposed to run at 30 Hz. It means I need 288 Mtexels/s. The specs > I have says one RM6 can fill up to 200 Mtexels/s. So I should Ok with 2 RM6. Is > it correct? You really want to consider a 150 Mpixels per second fill rate (not texels ??) for each RM6 for a _real_ vis sim application. You may have a better fill rate, but 150 Mpixels/s is a mean value from our experience. This makes it still correct in your case as 300 Mpixels/s > 288 Mpixesl/s Best Regards -- o o Remi ARNAUD - Silicon Graphics, Advanced Systems Dev o o o o Mail Stop 590 - 2011 N. Shoreline Boulevard o o o o Mountain View, California 94043-1389, USA o o o o Tel: (415) 933 6208 Fax: (415) 965 2658 o o From guest Mon Apr 29 11:59:05 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA27235; Mon, 29 Apr 1996 10:26:06 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA27232; Mon, 29 Apr 1996 10:25:58 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA04573; Mon, 29 Apr 1996 10:25:58 -0700 Received: from firewall.cgsd.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA12610; Mon, 29 Apr 1996 10:25:52 -0700 Received: from [192.9.200.107] ([192.9.200.107]) by firewall.cgsd.com (8.6.12/8.6.12) with SMTP id KAA01958 for ; Mon, 29 Apr 1996 10:26:49 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Apr 1996 10:25:37 -0800 To: info-performer@sgi.sgi.com From: mckenna@cgsd.com (Gene McKenna) Subject: OpenFlight Status: O I am trying to read a flight file so that I can copy my geometry data into my own data format for collision detection, but I'm having trouble. I have a copy of MultiGen's OpenFlight spec, but I find it to be somewhat lacking. (One little example couldn't be too hard to include, you would think.) A call to MultiGen proved fruitless. I can't imagine that they don't have a simple parsing code, even just a text dump would be great. Do they really want this to be an open format? For the ridiculous price of MultiGen's software, one would think that help in using their now "open" file format would be a little easier to come by. OK, enough MultiGen bashing. Anyone know where I might find a flight parser, or a better written spec? GENE +-----------------------------------------------------+ | Gene McKenna | | mckenna@cgsd.com CGSD Corporation | | voice 415.903.4928 Software Engineer | | fax 415.967.5252 Webmaster www.cgsd.com | +-----------------------------------------------------+ From guest Mon Apr 29 12:29:29 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA27547; Mon, 29 Apr 1996 10:55:14 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA27544; Mon, 29 Apr 1996 10:55:10 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA06866; Mon, 29 Apr 1996 10:55:10 -0700 Received: from jeeves.icemt.iastate.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA18183; Mon, 29 Apr 1996 10:55:08 -0700 Received: from helser75.res.iastate.edu (helser75.res.iastate.edu [129.186.76.75]) by jeeves.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) with SMTP id MAA21640 for ; Mon, 29 Apr 1996 12:54:38 -0500 Received: by helser75.res.iastate.edu with Microsoft Mail id <01BB35CB.05102D00@helser75.res.iastate.edu>; Mon, 29 Apr 1996 12:54:36 -0500 Message-ID: <01BB35CB.05102D00@helser75.res.iastate.edu> From: Allen Bierbaum To: "'Performer List'" Subject: pfdSpatialize Date: Mon, 29 Apr 1996 12:54:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Status: O Does anyone have a example of pfdSpatialize actually working> Every = time I try it, it just keeps recursing. I need it because I have a very large scene, that I am performing a huge = number of intersections with. The major bottleneck in my app right now = is the intersections. I believe that if I can subdivide the scene into = smaller geoSets, The intersections would perform substantially better. If anyone has an example... even one line, I would appreciate it. -Allen allenb@iastate.edu ISU CAVE++ RA - Carolina Cruz-Neira From guest Mon Apr 29 17:45:06 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id OAA00618; Mon, 29 Apr 1996 14:55:27 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA28876; Mon, 29 Apr 1996 13:48:47 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA16951; Mon, 29 Apr 1996 13:48:46 -0700 Received: from bhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA20465; Mon, 29 Apr 1996 13:48:44 -0700 Received: from poster.cae.ca (poster.cae.ca [142.39.22.1]) by bhole with SMTP (DuhMail/2.0) id QAA03899; Mon, 29 Apr 1996 16:46:32 -0400 Received: from osprey.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA10690; Mon, 29 Apr 1996 16:43:40 -0400 Received: by osprey.cae.ca (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id QAA01663; Mon, 29 Apr 1996 16:45:26 -0400 Date: Mon, 29 Apr 1996 16:45:26 -0400 From: nicolas@cae.ca (Nicolas Gauvin) Message-Id: <199604292045.QAA01663@osprey.cae.ca> To: info-performer@sgi.sgi.com Subject: VR head mounted devices (HMD) for SGI? Status: O I would like to know which VR head mounted devices (HMD) are compatible with SGI hardware. I'm looking for low cost HMD as well as high fidelity ($$) ones. I would also like to know if they can work on all SGI platforms or not (Indys in mono mode for example). I've seen very low cost devices available for PCs (like the VFX1). Can those be hooked to SGIs as well? I would appreciate if some of you could share your experiences in those areas. Thanks in advance. ___/ | ___/ Nicolas Gauvin e-mail: nicolas@cae.ca / / | / Software Developper voice: (514) 341-2000 x2275 / / | __/ CAE Electronics Ltd. fax: (514) 340-5496 / ___ | / 8585 Cote De Liesse, P.O. Box 1800 _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 From guest Mon Apr 29 17:53:56 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA03927; Mon, 29 Apr 1996 15:04:46 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA03924; Mon, 29 Apr 1996 15:04:46 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA21150; Mon, 29 Apr 1996 15:04:45 -0700 Received: from magellan.bgm.link.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA03654; Mon, 29 Apr 1996 15:04:42 -0700 Received: by magellan.bgm.link.com (940816.SGI.8.6.9/930416.SGI) for info-performer@sgi.sgi.com id RAA00918; Mon, 29 Apr 1996 17:02:31 -0500 Date: Mon, 29 Apr 1996 17:02:31 -0500 From: cvillarm@magellan.bgm.link.com (Cris Villarma) Message-Id: <199604292202.RAA00918@magellan.bgm.link.com> Apparently-To: info-performer@sgi.sgi.com Status: O I'm new to using the Performer software and am trying to figure out how to queue mouse events I've found the documentation on getting the mouse position and click positions, but haven't seen anything about setting up a queue. Cris Villarm Hughes Training cvillarm@magellan.bgm.link.com From guest Mon Apr 29 18:00:00 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA03946; Mon, 29 Apr 1996 15:10:17 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA28935; Mon, 29 Apr 1996 14:07:33 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA18108; Mon, 29 Apr 1996 14:07:32 -0700 Received: from cliffy.lfwc.lockheed.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA23756; Mon, 29 Apr 1996 14:07:30 -0700 Received: from skinner.fsl.lfwc.lockheed.com (skinner.lfwc.lockheed.com) by cliffy.lfwc.lockheed.com (5.x/SMI-SVR4) id AB26182; Mon, 29 Apr 1996 16:08:49 -0500 Received: from drdon ([137.32.36.9]) by skinner.fsl.lfwc.lockheed.com (4.1/SMI-4.1) id AA00812; Mon, 29 Apr 96 11:00:15 CDT Received: by drdon (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA06628; Mon, 29 Apr 1996 11:07:43 -0500 From: "Don Smith" Message-Id: <9604291107.ZM6626@drdon> Date: Mon, 29 Apr 1996 11:07:41 -0500 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com, info-performer@sgi.sgi.com Subject: Linking a Performer map into a mixed mode X/Iris GL application Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I have a mixed mode X/Iris GL application which displays a terrain map in a window with GL symbology superimposed on it. Currently the map is drawn with IRIS GL commands. I want to replace this map with a "top-down" view generated by a Performer application, but I want to retain the GL symbology drawn on top of it. This application also has a large number of detailed Motif/X panels, pull-down menus, etc. I need some advice on the best way to integrate the Performer map into the existing X/Motif/GL application. Can the performer map be drawn as a rendered image by calling a function from inside my X application, or does the Performer application need to be "in charge", so to speak? Any guidance or help would be greatly appreciated. Dr. Don Smith Lockheed-Martin Flight Simulation Fort Worth, Texas From guest Mon Apr 29 18:15:44 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA03972; Mon, 29 Apr 1996 15:25:16 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA28861; Mon, 29 Apr 1996 13:47:47 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA16879; Mon, 29 Apr 1996 13:47:46 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA20322; Mon, 29 Apr 1996 13:47:43 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id VAA06265; Mon, 29 Apr 1996 21:45:13 +0100 From: "Angus Dorbie" Message-Id: <9604292145.ZM6263@bitch.reading.sgi.com> Date: Mon, 29 Apr 1996 21:45:13 +0100 In-Reply-To: mckenna@cgsd.com (Gene McKenna) "OpenFlight" (Apr 29, 10:25am) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: mckenna@cgsd.com (Gene McKenna), info-performer@sgi.sgi.com Subject: Re: OpenFlight Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O It'd be simpler and probably more portable to querry the scene graph as loaded, that way you could support any file format which you have a performer loader for. You could delete the loaded graph afterwards if you don't need it. On Apr 29, 10:25am, Gene McKenna wrote: > Subject: OpenFlight > I am trying to read a flight file so that I can copy my > geometry data into my own data format for collision detection, > but I'm having trouble. > > I have a copy of MultiGen's OpenFlight spec, but I find it to > be somewhat lacking. (One little example couldn't be too hard > to include, you would think.) > > A call to MultiGen proved fruitless. I can't imagine that they > don't have a simple parsing code, even just a text dump would > be great. Do they really want this to be an open format? > > For the ridiculous price of MultiGen's software, one would think that > help in using their now "open" file format would be a little easier > to come by. > > OK, enough MultiGen bashing. > > Anyone know where I might find a flight parser, or a better written > spec? > > GENE > > +-----------------------------------------------------+ > | Gene McKenna | > | mckenna@cgsd.com CGSD Corporation | > | voice 415.903.4928 Software Engineer | > | fax 415.967.5252 Webmaster www.cgsd.com | > +-----------------------------------------------------+ > > >-- End of excerpt from Gene McKenna -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Mon Apr 29 18:15:26 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA03964; Mon, 29 Apr 1996 15:22:14 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA03961; Mon, 29 Apr 1996 15:22:14 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id PAA21846; Mon, 29 Apr 1996 15:22:13 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA06381; Mon, 29 Apr 1996 15:22:11 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA23536; Mon, 29 Apr 96 15:22:09 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id PAA01312; Mon, 29 Apr 1996 15:22:07 -0700 From: jrohlf@tubes.asd.sgi.com (John Rohlf) Message-Id: <199604292222.PAA01312@tubes.asd.sgi.com> Subject: Re: Formatting of perfly code To: guest (Greg Edwards, SGI UK.) Date: Mon, 29 Apr 96 15:22:07 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9604280928.ZM11257@cordoba.reading.sgi.com>; from "Greg Edwards, SGI UK." at Apr 28, 96 9:28 am X-Mailer: ELM [version 2.3 PL8] Status: O > > Can the team inform me what formatter is used on perfly and other > Pf example source. It's not my favourite style, but better to > stick with it than scrmable the whole thing and defeat xdiff etc. > > -- > __________________________________________________________________________ > Greg Edwards, Graphics Support/Consulting Group, Silicon Graphics UK Ltd. > Forum 1, Theale, Reading, UK, RG7 4RA. > tel +44 1734 257500, direct +44 1734 257740, fax +44 1734 257553 > gedwards@reading.sgi.com, US vmail 59130, UK vmail 7740#, mailstop IUK-311 > Here are Performer's settings for c++-mode.el: (setq c-auto-newline nil) (setq c-tab-always-indent nil) (setq c-indent-level 4) (setq c-brace-offset -4) (setq c-brace-imaginary-offset 0) (setq c-label-offset -4) (setq c-continued-brace-offset -4) (setq c-continued-statement-offset 4) From guest Mon Apr 29 18:29:25 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA04013; Mon, 29 Apr 1996 15:33:42 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id PAA04004; Mon, 29 Apr 1996 15:33:13 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA24116; Mon, 29 Apr 96 15:32:34 -0700 Received: by babar.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id PAA25217; Mon, 29 Apr 1996 15:31:16 -0700 From: "Michael T. Jones" Message-Id: <9604291531.ZM25215@babar.asd.sgi.com> Date: Mon, 29 Apr 1996 15:31:16 -0700 In-Reply-To: "John Archdeacon" "Re: OpenGVS Benchmark Applic" (Apr 29, 12:10pm) References: <199604291903.MAA23009@gemtech.gemtech.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: info-performer@giraffe.asd.sgi.com Subject: Re: OpenGVS Benchmark Applic Cc: "John Archdeacon" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 29, 12:10pm, John Archdeacon wrote: > Subject: Re: OpenGVS Benchmark Applic > Reply to: RE>OpenGVS Benchmark Applicati > Hello Michael "Testing-and-Benchmarking" Jones: Hi John! > Thanks for your thoughts and comments. I felt it best to not go on-line >with a response to your Performer newsgroup as this discussion is not a >Performer related issue, per se and I don't like to violate the spirit of that >forum (e.g., Performer focus). As such, I'd assume SGI would prefer to keep >this off-line from info-performer; if you don't care, you're certainly free to >forward it there if you want! Well, considering how little your long OpenGVS advertisement had to do with Performer, that we have nothing to hide about our performance, and that the Performer users are probably curious to learn of the relative performances between various IG's and software environments, I'll go ahead and forward it since you say it's OK. Perhaps there are non-Performer users on the mailing list who will speak-up and offer to implement your test databases on their machines/systems and an interesting dialogue will result. > Anyway, some clarifications for you regarding your recent email. You wrote: > > ...The Gemini IG test suite will serve as an interesting benchmark since > > it's open, in the following ways: > : > : 1. It can be run on multiple machines using OpenGVS. It would be a > : way to verify and judge implementation and hardware. This is the > : test that a GVS user would want to make, since it is a measure of > : virtue for the range of available options. > > Comment: the benchmarks are expected to be of interest to both GVS users and >basically *any* other interested party (user, hardware manufacturer, whatever) >since these benchmarks (as you pointed out) will help provide another useful >"data point" as to the potential suitability of the underlying graphics >hardware for computer image generation use. We see this point very differently. The GVS versions only speak to GVS speeds on the machine. They do not measure the machine. That would be like a ISV PHIGS company ranking workstations on drawing a car model based on their PHIGS implementation. The fastest one would be important to that ISV's PHIGS users, but no one else (not even other PHIGS users), unless... > > : 2. It can be run using multiple software libraries (OpenGVS, dVS, > : VistaWorks, SENSE8, Performer, etc.) on the same machine and > : database. This is what an SGI user would want to test since it > : is a measure of virtue for the range of available options. > > Comment: we only run on top of OpenGL, Direct3D, or the manufacturer's native >rendering API for those graphics implementations that support neither natively >(e.g., Real3D, 3DFX). Thus, to clarify, we do *not* run on top of Sense8, dVS, >Performer, or any other higher level APIs as I believe you suggested. Any >hardware manufacturer that uses a DLL under Windows NT or Windows 95 will be >able to run the binaries as long as the DLLs have been installed on their PC >(DLLs are much like SGI's shareable libraries). ...the test environment is as I thought you said before, an open one. This means that there is some database, and some task, where there as a database in OpenFlight, DWB, Wavefront, IV, or some other public format and some set of moving models with a log file of positions for each with time stamps (eyepoints too). There is no need for GVS code, for binaries, etc. Just the databases and example information so that people porting the tests to other environments can make the test measurements fairly. Gemini would implement these tests in OpenGVS (this is test #1) but I would do it in Performer. Companies like SENSE8, Loral, etc. would of course do it in the software environment they produce. This is test #2. Without test #2, your "universal testbed" is merely an OpenGVS test suite and is of no interest to me or Silicon Graphics. With test #2, your work becomes valuable in that the results from test #1 are validated -- a user knows much weight to give to a GVS-mark based on how well GVS does on that machine compared to other toolkits. Based on the GVS-mark, users can extrapolate performance of machines or alternate toolkits by multiplying by the speed of the faster or chosen toolkit by the GVS one on the same machine/database benchmark pair. (The factor would be 1 of course everywhere that OpenGVS is the fastest, so the results will be good for marketing for at least one of the companies participating in the benchmarks.) I have accepted the head-to-head test that you proposed. Are you backing out of it now? I don't see why you would do that after making such a big splash in the Performer mailing list with your original announcement. > You wrote: > : ...I'm eager to get the Gemini Technology test suite and > : have the Performer team get it up and running. If we can get it here > : at SGI in time, we can have numbers for test #2 in time for John > : Archdeacon's presentation at the Image Society meeting in June. > : When can we get the software and databases, what are the methods by > : which timings should be taken (resolution, #samples, etc.) and what else > : do we need to help you compile this data? > > Comment: I plan to run the tests under IRIX 6.2 on a 250 MHz Onyx RE2 with >two RM4 boards (the baseline re2stone as you may recall). At last check, I >don't believe the LA, Irvine, or San Diego offices of SGI have such a system -- >can you arrange to loan us one through Image? If not, I plan to use one of my >customer's systems (which does have the baseline configuration) but your >support in this area would help alot if possible. Second, I do plan to publish >the binaries on-line at our home page in a compressed TAR file format for IRIX >users as well as appropriate versions for Windows NT and '95 users as well. >I'll keep you posted as to when the IRIX version is available (sooner if you >can help us get the right hardware here... if not, a trip to my customer's site >or to Mountain View!) Are we talking about the full, open IG test approach (tests #1 and #2) or the OpenGVS-only approach that you seem to retreating to? If it's the real thing then I think I need to find a way to help you since it could clear up so many misconceptions. > Thanks - John > > >-- End of excerpt from John Archdeacon I hope that I misunderstand your new position. I urge you to follow through with the plan to make the databases and eyepoint/vehicle information avaliable as your test suite. Just printing a list of OpenGVS throughputs and claiming that you've measured the soul of InfiniteReality, CompuScene-VI, ESIG-4000, and so on is not much to base in IMAGE presentation on, nor is it something that SGI, Lockheed-Martin, or E&S would seem likely to embrace (speaking for myself, not for other image generator vendors). Michael Jones -- Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Systems Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 "Du musst Amboss oder Hammer sein" -- Goethe From guest Mon Apr 29 18:39:36 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA04026; Mon, 29 Apr 1996 15:40:17 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id NAA28913; Mon, 29 Apr 1996 13:58:55 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id NAA17344; Mon, 29 Apr 1996 13:58:55 -0700 Received: from netcom5.netcom.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id NAA22142; Mon, 29 Apr 1996 13:58:52 -0700 Received: (from cutt@localhost) by netcom5.netcom.com (8.6.13/Netcom) id NAA17615; Mon, 29 Apr 1996 13:58:42 -0700 Date: Mon, 29 Apr 1996 13:58:41 -0700 (PDT) From: "Paul S. Cutt" Subject: Re: URGENT HELP: Polhemus tracker with Performer To: "Ng Kian Bee, SIT/CS" cc: performer , "Vincent, SGI" , "vincentoh@singapore.sgi.com" In-Reply-To: <31812149@mgate.nyp.ac.sg.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Fri, 26 Apr 1996, Ng Kian Bee, SIT/CS wrote: > Hello, > I need this help ASAP. Millions thanx! > I would like to use the following devices for my project: > - Polhemus FASTRAK motion tracking device by Polhmeus Inc. > - 3D Spaceball 2003 by Spacetec Inc. > The software I'm using is Coryphaeus Software's EasyScene 3.0. Since this > software runs on top of Performer 1.2/2.0, I'm praying that someone here > could > help me. I'm running on my RE2 machine. I need some one to guide me as to > 1. where can I get the drivers for both the Polhemus and Spaceball? Or > anyone here > had tried on the device with their performer? > 2. How do I set the devices up? That is do I just run the driver and it will > work > or do I have to configure my RE2 or ... > > Appreciate any reply. I have what may be of interest to you, our SyncLink virtual reality device driver package. Below is a description. Please let me know if you have any questions. Sincerely, Paul S. Cutt VP Engineering Xtensory Inc Tel: 408/439-0600 Fax: 408/439-8845 Email: cutt@netcom.com -------------------------------------------------- XVS-SyncLink (TM) A Standard Device Interface for Virtual Environments and Applications Benefits XVS-SyncLinkTM is a C++ class library that simplifies adding and maintaining virtual reality (VR) sensor support in existing applications. It provides a standard device interface for including virtual environment devices into applications. Virtual environments have led to the proliferation of 3D devices with multiple degrees of freedom x,y,z,roll,pitch,yaw). Each device has its own strengths and weaknesses, and the creation of new devices brings with it a constant improvement in the capabilities available. However, using these devices in applications is not easy. Many of these devices are mutually incompatible. They have different command sets; they use different command syntax for the same commands; the output they give to the computer follows different binary formats; and the same type of data is presented using different coordinate systems. Until now, the near-total lack of standardization of even the simplest virtual reality functions has discouraged developers from supporting multiple devices, or adding any VR support to their applications at all. SyncLink takes the load off the application developer by providing a standardized and portable object-oriented set of VR device drivers. This lets the developer concentrate on the applications, rather than the idiosyncracies of each VR device. Object Oriented SyncLink provides an object-oriented interface to VR devices. There is a single C++ class hierarchy for VR sensors. This hierarchy currently handles 6-D sensors such as the Polhemus Fastrak, Logitech 3D Mouse, Ascension Flock of Birds, Spaceball 2003, and the VPL Research DataGlove Model 2. A second C++ class for coordinate systems allows the application programmer to translate automatically between the differing coordinate systems used by VR devices, 3D rendering systems, and existing applications and data sets. Common Interface All devices which provide 6-degree of freedom position and orientation data are handled similarly. SyncLink's base sensor class provides standard operations for opening devices, closing devices, and reading position, Euler angles, toggles, and other device data. Common filtering operations are also avaiable in the base class, including origin offset, setting tolerance levels, clipping, modulo, and scaling. Each device may report data in either absolute or relative values, whether it is an isometric device like the Spaceball, or an isotonic device like the Fastrak. While the SyncLink base class provides a common interface to common VR functions across different devices, it does not limit the application programmer to the lowest common denominator. Device-specific functions are also provided. For example, Fastrak and Flock of Birds users can make use of the multistation capabilities of these devices, allowing multiple receivers to be read from a single serial port. DataGlove Model 2 programmers can calibrate the glove and read and write ASCII-formatted calibration tables. Logitech users may access the fringe and out of range settings which warn when the receiver is approaching its line-of-sight limits. Sample application code provided with SyncLink demonstrates how the same source code can be used to control any of the supported sensors. Switching Sensors SyncLink's common interface makes it easy to switch between sensors from within an application. Simply close and delete the old sensor object, create and open a new sensor object, and reapply the application's sensor filters. Even this level of detail can be hidden from the user by the application. No longer do the software incompatibilities between sensors inhibit switching between them from within an application. Customized Support Xtensory provides the services for adding customized device support. Custom devices can then use the same standard object-oriented interface as commercial devices, without losing access to the functionality that makes the device unique. Maintenance Xtensory provides support for upgrades and maintains the drivers as new devices become available. Portability SyncLink provides portability between different UNIX and POSIX platforms. The same C++ class library is available for Silicon Graphics, Kubota Pacific, and Digital Equipment systems. Devices Supported Ascension Flock of Birds General Reality CyberEye General Reality DataGlove Immersion Probe and Personal Digitizer Logitech 3D Mouse, Cyberman and Space Control Mouse/Magellan Origin Instruments DynaSight Polhemus Fastrak, Isotrak, and 3Ball Precision Navigation Wayfinder Spaceball 2003 Virutal I/O i-glasses! Virtual Technologies CyberGlove VPL DataGlove Model 2 5DT 5-Glove System Requirements SyncLink includes a C++ object library, C++ header files, and sample C++ test software. SyncLink requires one of the following operating systems: SGI IRIX 5.2 or later Digital OSF/1 1.3 or later Microsoft Windows NT 3.5 Microsoft Windows 3.1 HP-UX 9.0 or later Sun SyncLink also requires the appropriate C/C++ compiler for the platform: SGI C++ 3.0 Digital C++ 1.3 or later Microsoft Visual C++ HP Sun Contact Xtensory regarding support for VR devices or UNIX/POSIX operating systems not listed above. Xtensory Inc 140 Sunridge Drive Scotts Valley CA 95066 USA Tel 408/439-0600 Fax 408/439-8845 cutt@netcom.com ...opening the doors of perception (TM) From guest Mon Apr 29 16:10:17 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id MAA28030; Mon, 29 Apr 1996 12:14:10 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id MAA28027; Mon, 29 Apr 1996 12:14:06 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id MAA11729; Mon, 29 Apr 1996 12:14:06 -0700 Received: from uu9.psi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA02828; Mon, 29 Apr 1996 12:14:04 -0700 Received: from ivex3d.com by uu9.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA25824 for info-performer@sgi.sgi.com; Mon, 29 Apr 96 15:14:01 -0400 Message-Id: <9604291914.AA25824@uu9.psi.com> From: Hudson Holmes To: info-performer@sgi.sgi.com Date: Mon, 29 Apr 1996 15:12:51 +0000 Subject: Pixel count on Infinite Reality X-Mailer: Pegasus Mail for Windows (v2.20) Status: O I am interested in configuring an Infinite Reality, 3 channel system with 1K x 1K resolution per channel and a user console. I know how to calculate the Raster Manager requirements as described by other users here. What I do not know is if I must include the screen resolution of the user console in that calculation or is that a freebee which does not require use of the RMs in the graphics pipe. Can anyone help me with this? From guest Mon Apr 29 19:00:53 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id PAA04120; Mon, 29 Apr 1996 15:55:16 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id OAA28973; Mon, 29 Apr 1996 14:12:20 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id OAA18454; Mon, 29 Apr 1996 14:12:19 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA24524; Mon, 29 Apr 1996 14:12:16 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id WAA06302; Mon, 29 Apr 1996 22:09:55 +0100 From: "Angus Dorbie" Message-Id: <9604292209.ZM6300@bitch.reading.sgi.com> Date: Mon, 29 Apr 1996 22:09:55 +0100 In-Reply-To: mckenna@cgsd.com (Gene McKenna) "OpenFlight" (Apr 29, 10:25am) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com, mckenna@cgsd.com (Gene McKenna) Subject: Re: OpenFlight (some code) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Oh and incase I haven't convinced you to use the performer loaders, here's some parsing code, it just PARSES a flight file it doesn't really load anything, the last time I checked it worked with flight 14 and I've tried to ensure that it won't break with format updates although it won't recognise new opcodes. It isn't designed for open flight (don't know whats in that, I expect it's mostly just a name change), it just reads a flight file, prints lots of info and draws the vertices in an IrisGL window for fun. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #include #include #include #include #define FLT_HEADER 1 #define FLT_GROUP 2 #define FLT_LOD 3 /* OBSOLETE */ #define FLT_OBJECT 4 #define FLT_POLYGON 5 #define FLT_ABS_VERTEX 7 /* OBSOLETE */ #define FLT_SHA_VERTEX 8 /* OBSOLETE */ #define FLT_NOR_VERTEX 9 /* OBSOLETE */ #define FLT_PU_LEVEL 10 #define FLT_PO_LEVEL 11 #define FLT_DOF 13 /* OBSOLETE */ #define FLT_DOFF 14 #define FLT_PU_SUB 19 #define FLT_PO_SUB 20 #define FLT_COMMENT 31 #define FLT_COLOUR 32 #define FLT_T0 40 #define FLT_T1 41 #define FLT_T2 42 #define FLT_T3 43 #define FLT_T4 44 #define FLT_T5 45 #define FLT_T6 46 #define FLT_T7 47 #define FLT_T8 48 #define FLT_TRANSFORMATION 49 #define FLT_GEOMETRY 50 #define FLT_BOUNDS 51 /* OBSOLETE */ #define FLT_REPLICATION 60 #define FLT_TEXTURE 64 #define FLT_EYE 65 /* OBSOLETE */ #define FLT_MATERIAL 66 #define FLT_VERTEX_TABLE 67 #define FLT_SHA_VERTEXF 68 #define FLT_NOR_VERTEXF 69 #define FLT_NORTEX_VERTEXF 70 #define FLT_TEX_VERTEXF 71 #define FLT_VERTEX_LIST 72 #define FLT_LODD 73 #define FLT_EYE_POINT 83 #define MAXPOOL 5000 /* local functions */ static float *ReadFlight(char *); static void clear_record(FILE *); static void name_and_clear_record(FILE *, int); static void get_vertex(FILE *, int); static void draw_axes(void); static void add_vert(float *); static void draw_verts(void); char *indentations[] = { "", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " ", " " }; static char *indent; static float *vpool; static unsigned long vcount; main() { foreground(); prefsize(500, 500); winopen("Flight File"); RGBmode(); mmode(MVIEWING); winconstraints(); doublebuffer(); zbuffer(FALSE); gconfig(); subpixel(TRUE); pntsize(3.0); pntsmooth(SMP_ON | SMP_SMOOTHER); linesmooth(SML_ON | SML_SMOOTHER | SML_END_CORRECT); blendfunction(BF_SA, BF_MSA); perspective(450.0, 1.0, 1.0, 500.0); translate(0.0, 0.0, -100.0); rot(45.0, 'x'); rot(30.0, 'y'); cpack(0xFF000000); ReadFlight("test.flt"); while(1) draw_verts(); } static float *ReadFlight(char *name) { short code; int size; char buffer[120]; static int indentnum = 0; FILE *flight; indent = indentations[indentnum]; flight = fopen(name, "rb"); if(!flight) { printf("Failed to open file %s\n", name); exit(1); } /* 5000 verts x y z nx ny nx u v */ vpool = (float *)calloc( 8*MAXPOOL, sizeof(float) ); vcount = 0; size = fread((void *)&code, 2, 1, flight); while(size > 0) { draw_verts(); switch(code) { case FLT_HEADER: printf("%sHEADER\n", indent); clear_record(flight); break; case FLT_GROUP: printf("%sGROUP\n", indent); name_and_clear_record(flight, 8); break; case FLT_LOD: printf("%sLOD: OBSOLETE\n", indent); name_and_clear_record(flight, 8); break; case FLT_OBJECT: printf("%sOBJECT\n", indent); name_and_clear_record(flight, 8); break; case FLT_POLYGON: printf("%sPOLYGON\n", indent); name_and_clear_record(flight, 8); break; case FLT_ABS_VERTEX: printf("%sABSOLUTE VERTEX: OBSOLETE\n", indent); clear_record(flight); break; case FLT_SHA_VERTEX: printf("%sSHADED VERTEX: OBSOLETE\n", indent); clear_record(flight); break; case FLT_NOR_VERTEX: printf("%sNORMAL VERTEX: OBSOLETE\n", indent); clear_record(flight); break; case FLT_PU_LEVEL: printf("%s{\n", indent); clear_record(flight); indentnum++; indent = indentations[indentnum]; break; case FLT_PO_LEVEL: clear_record(flight); indentnum--; indent = indentations[indentnum]; printf("%s}\n", indent); if(indentnum < 0) printf("PUSH/POP ERROR\n"); break; case FLT_DOF: printf("%sDEGREE OF FREEDOM: OBSOLETE\n", indent); clear_record(flight); break; case FLT_DOFF: printf("%sDEGREE OF FREEDOM\n", indent); clear_record(flight); break; case FLT_PU_SUB: printf("%sCONTROL: PUSH SUBFACE\n", indent); clear_record(flight); break; case FLT_PO_SUB: printf("%sCONTROL: POP SUBFACE\n", indent); clear_record(flight); break; case FLT_COMMENT: printf("%sCOMMENT\n", indent); fread((void *)&code, 2, 1, flight); size = fread(buffer, (long)code-4, 1, flight); buffer[size] = '\0'; printf("%s%s\n", indent, buffer); break; case FLT_COLOUR: printf("%sCOLOUR TABLE\n", indent); clear_record(flight); break; case FLT_T0: case FLT_T1: case FLT_T2: case FLT_T3: case FLT_T4: case FLT_T5: case FLT_T6: case FLT_T7: case FLT_T8: printf("%sIndividual transformation\n", indent); break; case FLT_TRANSFORMATION: printf("%sTRANSFORMATION MATRIX\n", indent); clear_record(flight); break; case FLT_BOUNDS: printf("%sBOUNDS: OBSOLETE\n", indent); clear_record(flight); break; case FLT_REPLICATION: printf("%sREPLICATION\n", indent); clear_record(flight); break; case FLT_TEXTURE: printf("%sTEXTURE\n", indent); name_and_clear_record(flight, 80); break; case FLT_EYE: printf("%sEYE: OBSOLETE\n", indent); clear_record(flight); break; case FLT_MATERIAL: printf("%sMATERIAL\n", indent); clear_record(flight); break; case FLT_VERTEX_TABLE: printf("%sVERTEX TABLE\n", indent); clear_record(flight); break; case FLT_SHA_VERTEXF: printf("%sSHADED VERTEX\n", indent); get_vertex(flight, FLT_SHA_VERTEXF); break; case FLT_NOR_VERTEXF: printf("%sNORMAL VERTEX\n", indent); get_vertex(flight, FLT_NOR_VERTEXF); break; case FLT_NORTEX_VERTEXF: printf("%sNORMAL TEXTURED VERTEX\n", indent); get_vertex(flight, FLT_NORTEX_VERTEXF); break; case FLT_TEX_VERTEXF: printf("%sTEXTURED VERTEX\n", indent); get_vertex(flight, FLT_TEX_VERTEXF); break; case FLT_VERTEX_LIST: printf("%sVERTEX LIST\n", indent); clear_record(flight); break; case FLT_LODD: printf("%sLEVEL OF DETAIL\n", indent); clear_record(flight); break; case FLT_EYE_POINT: printf("%sEYE POINT\n", indent); clear_record(flight); break; default: printf("%sUNKNOWN RECORD NUMBER: %d\n", indent, code); clear_record(flight); } size = fread((void *)&code, 2, 1, flight); } fclose(flight); } static void clear_record(FILE *flight) { short code; fread((void *)&code, 2, 1, flight); fseek(flight, (long)code-4, SEEK_CUR ); } static void name_and_clear_record(FILE * flight, int size) { short code; char buffer[120]; fread((void *)&code, 2, 1, flight); fread(buffer, size, 1, flight); printf("%sID : %s\n", indent, buffer); fseek(flight, (long)code-size-4, SEEK_CUR ); } static void get_vertex(FILE *flight, int type) { short code; double coords[4]; float newvert[4]; fread((void *)&code, 2, 1, flight); switch(type) { case FLT_SHA_VERTEXF: fseek(flight, (long)code-4, SEEK_CUR ); break; case FLT_NOR_VERTEXF: fseek(flight, (long)4, SEEK_CUR ); fread((void *)coords, 8, 3, flight); fseek(flight, (long)code-32, SEEK_CUR ); newvert[0] = (float) coords[0]; newvert[1] = (float) coords[2]; newvert[2] = -(float) coords[1]; add_vert(newvert); break; case FLT_NORTEX_VERTEXF: fseek(flight, (long)4, SEEK_CUR ); fread((void *)coords, 8, 3, flight); fseek(flight, (long)code-32, SEEK_CUR ); newvert[0] = (float) coords[0]; newvert[1] = (float) coords[2]; newvert[2] = -(float) coords[1]; add_vert(newvert); break; case FLT_TEX_VERTEXF: fseek(flight, (long)code-4, SEEK_CUR ); break; } } static void draw_axes(void) { static float ax[][4] = { { 0.0, 0.0, 0.0, 0.0 }, { 5.0, 0.0, 0.0, 0.0 }, { 0.0, 5.0, 0.0, 0.0 }, { 0.0, 0.0, 5.0, 0.0 }, }; cpack(0xFFFF0000); bgnline(); v3f(ax[1]); v3f(ax[0]); v3f(ax[2]); endline(); bgnline(); v3f(ax[0]); v3f(ax[3]); endline(); } static void add_vert(float *newvert) { if(vcount < (MAXPOOL-1)) { if(vpool) { *(vpool + (vcount * 8)) = *newvert; *(vpool + (vcount * 8 +1)) = *(newvert+1); *(vpool + (vcount * 8 +2)) = *(newvert+2); } vcount ++; } else printf("Ignoring Vertex: maximum of %d exceeded\n", MAXPOOL); } static void draw_verts(void) { int i; float *vert; if(vpool) { cpack(0xFF000000); clear(); rot(0.5, 'y'); cpack(0xFFFF0000); draw_axes(); cpack(0xFFFFFFFF); bgnpoint(); for(i=0, vert = vpool; i Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id UAA05952; Mon, 29 Apr 1996 20:51:20 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id UAA05410; Mon, 29 Apr 1996 20:51:19 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA14677; Mon, 29 Apr 1996 20:51:18 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA11149; Mon, 29 Apr 96 20:51:12 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id UAA17767; Mon, 29 Apr 1996 20:50:12 -0700 From: "Sharon Clay" Message-Id: <9604292050.ZM17765@rose.asd.sgi.com> Date: Mon, 29 Apr 1996 20:50:12 -0700 In-Reply-To: "Ulrich J Lechner" "Intersection" (Feb 17, 11:25am) References: u<824577946Sat-0600.uli@vislab.iastate.edu> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Ulrich J Lechner" , info-performer@sgi.sgi.com Subject: Re: Intersection Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Feb 17, 11:25am, Ulrich J Lechner wrote: > Subject: Intersection ->From guest@holodeck.asd.sgi.com Sat Feb 17 12:52:50 1996 -> ->Hi Performers! -> ->I would like to intersect my scene (on PFTRAV_IS_GEODE or PFTRAV_IS_GSET level) ->with a simple cylinder or a box. What is the standard way to do this? ->I tried to use a pfSegSet without any lines, a bounding cylinder and ->a discriminator function (see pguide 186) ->Result: My disc function is never called. I guess it is because of a missing ->line segment. Did I do something wrong or is there another way to ->test any object against a node. Do I have to use pfSphereContainsSphere ->to test against every bounding volume for every node? We only do segment intersections and we call the discriminator function if there are actual active segments with length > 0. However, you could do an initial test of your own in the a pre-isect callback on the node that should get called for all nodes traversed, even with an empty segment set. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue Apr 30 01:15:15 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id UAA05919; Mon, 29 Apr 1996 20:32:35 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id UAA05916; Mon, 29 Apr 1996 20:32:34 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id UAA04936; Mon, 29 Apr 1996 20:32:34 -0700 Received: from mred.bgm.link.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA13201; Mon, 29 Apr 1996 20:32:31 -0700 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA20537; Mon, 29 Apr 96 22:29:01 -0500 Date: Mon, 29 Apr 96 22:29:01 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9604300329.AA20537@mred.bgm.link.com> To: info-performer@sgi.sgi.com Subject: Re: OpenGVS Benchmark Applic Status: O Well, I have always believed in the maxim: There are lies, Damned lies, and Benchmarks. The trouble with benchmarks is that they are always optimal for one machine and pessimal for another. Take for example, a flight simulation benchmark. Here is a simple database design question: "Are you going to layer forest canopy areas on top of the terrain, or are you going to cut holes in the terrain?" If you do the former, you will be doing a great service to machines like the Compuscene VI and PT 2000 because they have pixel fill rate optimisation hardware that lets you skip over second and subsequent layers of polygon. The SGI hardware will suffer because it doesn't have that feature. If you decide to take pity on the SGI machines and cut holes in the terrain where the forest canopy over laps it - then the polygon count will increase fairly dramatically. The SGI boxes won't care too much about that because they can push a zillion polyons (well, may be a half zillion) without even breaking into a sweat. Of course the Compuscene box will be maxed out on polygons and it's performance will be much poorer. Some E&S machines offer a trade-off between pixel fill rates and hidden surface options. Can we run the database with the Z-buffer (sorry 'R-buffer') disabled for the test? What if a polygon is incorrectly occulted as a result? Does that disqualify the IG from testing? How about texture? Some IG's can do multiple textures per polygon at no extra penalty. The SGI box can do that too - but only if one is a detail texture. If you force the SGI box to do two textures per polygon for real then it'll take twice as long to render the database. Is this a fair test or not? What about DCS's? An SGI box can draw an almost unlimited number of them. Some other boxes impose severe limits - if we make the benchmark have 1000 moving objects then it'll run OK on an SGI box - just about every other IG will choke and die. You see there is no such thing as a fair benchmark. To get the benchmark to be portable at all, it will end up using features that are the lowest common denominator on all the systems you want to test. I have a database (a rollercoaster) that was build in GVS many, many moons ago. It ran quite nicely under GVS. When we switched to Performer (a decision I have never regretted), we just grabbed the flight files and tried to run them. It ran about the same speed as the GVS software did. Later, we restructured the polygons into more smaller objects. The ability of Performer to push culling off onto another CPU made the database run substantially faster because GL had far fewer polygons to process. Later still, we rewote our database loader so that instead of using LoadFlt(), we had our own in-house code. The new loader does a much better job of TMesh construction than the pfUtils functions that LoadFLt() uses - so the database ran noticably faster. We now have four different timings for the RE2 on the "same" database. If we take that database back to GVS, what will happen? Well, since the original version was optimised to death for GVS, it's likely that the single-CPU rendering that GVS uses will probably suffer greatly from the increased cull times, leaving little time left for everything else. Please note, this is NOT a slur on GVS - the Performer version uses an additional CPU, so it's not a fair test. Exactly the same polygons, exactly the same pictures, exactly the same hardware. Wildly differing rendering times. Now what? OK, you may say - we'll simply define how the database should *look* and let the proponents of a given hardware/software combination optimise the database to death - and so long as they don't change it's appearance, the benchmark will still be valid. NO !!! The whole design of the database is rooted in the hardware architecture of the machine. In a low flying aircraft simulation, it is important for the pilot to get a certain degree of speed and altitude cueing. The way that you provide those cues depends on the kind of IG you have. Some IG's can draw lots of polygons - so you get the speed cues by drawing lots and lots of little polygonal trees and bushes out there. On the other hand, if your IG has fewer polygons - but great looking texture, then you can reduce the number of trees and use lots of nice detailed, high contrast texture instead. The ability of the two approaches to train a pilot to fly low and fast is about the same. Benchmarking is just about possible for something as relatively simple as a CPU, basically, the CPU runs the program - you time how long it took - if it goes fast, that's better. (Even that isn't quite true - but that's another argument) With graphics there is also a strong QUALITY consideration. You can usually trade between quality and speed. That makes benchmarking impossible. How nicely does the database have to look in order to count as a 'pass' so that we can measure it's speed? CONCLUSION: I think you are setting an impossible goal - the results will come out heavily biassed towards the machine and the software that the database was first designed for. I suggest you give up on the idea. Steve Steve Baker 817-323-1361 (Vox-Lab) Hughes Training Inc. 817-695-8776 (Vox-Office/vMail) 2200 Arlington Downs Road 817-695-4028 (Fax) Arlington, Texas. TX 76005-6171 steve@mred.bgm.link.com (eMail) From guest Tue Apr 30 04:59:38 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA06649; Tue, 30 Apr 1996 01:04:27 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA06646; Tue, 30 Apr 1996 01:04:18 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA13585; Tue, 30 Apr 1996 01:04:18 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id BAA01849; Tue, 30 Apr 1996 01:04:16 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA16573; Tue, 30 Apr 96 01:04:13 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id BAA18495; Tue, 30 Apr 1996 01:02:26 -0700 From: "Sharon Clay" Message-Id: <9604300102.ZM18493@rose.asd.sgi.com> Date: Tue, 30 Apr 1996 01:02:26 -0700 In-Reply-To: "Michael T. Jones" "Re: Memory management question" (Apr 19, 6:20pm) References: <6093.829945609@MAPS.CS.CMU.EDU> <9604191821.ZM12493@babar.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: "Michael T. Jones" , Stephen_Gifford@MAPS.CS.CMU.EDU, info-performer@sgi.sgi.com Subject: Re: Memory management question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 19, 6:20pm, Michael T. Jones wrote: > Subject: Re: Memory management question ->From guest@holodeck.csd.sgi.com Fri Apr 19 19:00:34 1996 ->From: "Michael T. Jones" ->Date: Fri, 19 Apr 1996 18:20:59 -0700 ->In-Reply-To: Stephen_Gifford@MAPS.CS.CMU.EDU -> "Re: Memory management question" (Apr 19, 4:26pm) ->X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) ->To: Stephen_Gifford@MAPS.CS.CMU.EDU, info-performer@sgi.sgi.com ->Subject: Re: Memory management question -> ->On Apr 19, 4:26pm, Stephen_Gifford@MAPS.CS.CMU.EDU wrote: ->> Subject: Re: Memory management question -> ->> The pfMultiprocess mode has been PFMP_APPCULLDRAW (0) through ->> all of these attempts. Since we're not actually drawing the geometry, ->> only using pf functions to manipulate it, pfDraw is never being ->> called. The program is simply running out of shared memory after ->> growing larger and larger in a linear fashion. -> ->Have you tried libdmalloc as a diagnostic approach? -> ->> This looks to me like a core leak of some kind. I'm curious ->> if anyone else has had success with similar work: processing 200+MB ->> of data in a piece by piece fashion (iterating over a rectangular grid ->> of load modules read in from disk, for example). In particular, ->> anything where a Performer related core leak would cause a real ->> problem. -> ->We don't have known memory leaks, so there is no quick answer of the ->"just get patch nnn and it will be ok" type. We have done extensive ->testing and feel that this should not be a leakage situation from in ->the Performer libraries themselves. I will second the comment that we hve no known memory leaks. However, memory usage can be seen due to several factors: In IRIX 5.3 there was a couple of IRIX bugs that cause cause IRIX itself to grow. If you are having memory management problems, the first thing to do is to run bloatview (for IRIX5.3) or gmemusage (IRIX6.2) and look to see who is actually growing - your app or IRIX. Then, click on your process to see the full display and find out if it is the swap area (which is where we put the shared memory arena) or the sbreak (heap) area of a single process that is growing. Performer almost always allocates data from the arena. If that seems to be growing it may be due to 1) fragmentation 2) the amount of space to hold data as you bring in new files and slowly asynch delete others may be much more than you expect and grow in jumps, but may not actually grow without bound. Things to try first: o set some options to malloc to improve compaction of memory allocation to reduce fragmentation: amallopt(M_MXCHK, 1000000, pfGetSharedArena()); amallopt(M_FREEHD,1,pfGetSharedArena()); o track the growth of the arena to isolate out when it is growing. amallinfo will give you back size info of the arena. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue Apr 30 05:24:47 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA06703; Tue, 30 Apr 1996 01:35:15 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA06700; Tue, 30 Apr 1996 01:35:14 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA14466; Tue, 30 Apr 1996 01:35:14 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id BAA04037; Tue, 30 Apr 1996 01:35:09 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA17114; Tue, 30 Apr 96 01:34:55 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id BAA18590; Tue, 30 Apr 1996 01:33:29 -0700 From: "Sharon Clay" Message-Id: <9604300133.ZM18588@rose.asd.sgi.com> Date: Tue, 30 Apr 1996 01:33:29 -0700 In-Reply-To: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) "pfObject userData" (Feb 19, 7:11pm) References: <199602200311.TAA19639@sgi600.msd.lmsc.lockheed.com> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) Subject: Re: pfObject userData Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Feb 19, 7:11pm, Ken Sakai wrote: > Subject: pfObject userData ->From guest@holodeck Mon Feb 19 19:35:50 1996 ->Date: Mon, 19 Feb 1996 19:11:15 -0800 ->From: sakai@sgi600.msd.lmsc.lockheed.com (Ken Sakai) ->To: info-performer@sgi.sgi.com ->Subject: pfObject userData -> ->Question: Does the userData pointer have to point to a Performer ->reference counted memory? Man page examples always show userData being of that ->type. User data can point to anything BUT static data. If userData points to pfMemory, we can reference count it and delete it when you delete nodes and the reference count goes to 0. Also, if it is pfMemory, it can be saved to a file and reloaded if you are using the new fast-loading pfb loader since you can get the size of it. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue Apr 30 05:22:34 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id BAA06691; Tue, 30 Apr 1996 01:26:43 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id BAA06688; Tue, 30 Apr 1996 01:26:42 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id BAA14145; Tue, 30 Apr 1996 01:26:42 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id BAA03475; Tue, 30 Apr 1996 01:26:40 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.com id AA16967; Tue, 30 Apr 96 01:26:34 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id BAA18559; Tue, 30 Apr 1996 01:25:28 -0700 From: "Sharon Clay" Message-Id: <9604300125.ZM18557@rose.asd.sgi.com> Date: Tue, 30 Apr 1996 01:25:28 -0700 In-Reply-To: gideon "RGBA or ABGR and textures" (Apr 27, 1:14am) References: <199604262314.AA03184@xs1.xs4all.nl> X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: gideon , info-performer@sgi.sgi.com Subject: Re: RGBA or ABGR and textures Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 27, 1:14am, gideon wrote: > Subject: RGBA or ABGR and textures ->From guest@holodeck.csd.sgi.com Fri Apr 26 19:00:00 1996 ->From: gideon ->Subject: RGBA or ABGR and textures ->To: info-performer@sgi.com ->Date: Sat, 27 Apr 1996 01:14:07 +0200 (MET DST) ->X-Mailer: ELM [version 2.4 PL25] -> ->Hi, -> ->I'm trying to download textures from an sgi movie file - using the dmedia ->library. It all seems to work, except for the fact that the packing of ->the pixels is wrong. I've tried a number of things to change the pixel ->packing during transer (like glPixelStorei ...), to no avail. ->Does anyone have a suggestion how to solve this ? ->BTW I'm using Performer 2.0 and OpenGL on a High Impact. All you should need to do is to set the host memory format token in glTexImge2d to be GL_ABGR_EXT. On the current IMPACT sw this can have a 10-20% impact on loading performance of large textures (> 64x64), but this is a known problem that should be fixed for the next release. However, I'd say that whenever reasonable, one should opt for RGBA textures and swap the bytes as they are read in since that is the OpenGL centric way. Sample code to do the byte-reorder as data is read is in the source code for the Inventor loader. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue Apr 30 05:57:23 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA06763; Tue, 30 Apr 1996 02:05:27 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA06760; Tue, 30 Apr 1996 02:05:27 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA15261; Tue, 30 Apr 1996 02:05:27 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA05922; Tue, 30 Apr 1996 02:05:24 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id KAA07569; Tue, 30 Apr 1996 10:02:44 +0100 From: "Angus Dorbie" Message-Id: <9604301002.ZM7567@bitch.reading.sgi.com> Date: Tue, 30 Apr 1996 10:02:43 +0100 In-Reply-To: Hudson Holmes "Pixel count on Infinite Reality" (Apr 29, 3:12pm) References: <9604291914.AA25824@uu9.psi.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Hudson Holmes , info-performer@sgi.sgi.com Subject: Re: Pixel count on Infinite Reality Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O It depends what your question means. If your asking if you have to include it for pixel fill load calculations then the answer is no, unless you redraw the whole thing every frame. Work out how much you are drawing to the console each frame and include that in your calculation. If this is some non custom gui area with expose events etc then you'd want to do this a different way. Also you don't want multiple threads rendering to the same pipe if it can be avoided. For your other calculations (RM Memory, RM-DG bandwidth & DG dac bandwidth) you must include the console unless you are using an ascii terminal of some sort. A remote INDY might be a better way of running a console, even if you only use it as an X server. Rgds, Angus. On Apr 29, 3:12pm, Hudson Holmes wrote: > Subject: Pixel count on Infinite Reality > I am interested in configuring an Infinite Reality, 3 channel system with 1K x 1K > resolution per channel and a user console. I know how to calculate > the Raster Manager requirements as described by other users here. > What I do not know is if I must include the screen resolution of the > user console in that calculation or is that a freebee which does not > require use of the RMs in the graphics pipe. Can anyone help me with > this? >-- End of excerpt from Hudson Holmes -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Tue Apr 30 05:57:27 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA06748; Tue, 30 Apr 1996 02:01:43 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA06745; Tue, 30 Apr 1996 02:01:35 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA15074; Tue, 30 Apr 1996 02:01:34 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA05610; Tue, 30 Apr 1996 02:01:27 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id TAA21083 (8.7.5/IDA-1.6); Tue, 30 Apr 1996 19:01:11 +1000 (EST) Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA03084 (5.65c/IDA-1.5); Tue, 30 Apr 1996 18:37:41 +1000 Received: from murad (murad [8.0.0.108]) by aggro with SMTP id SAA12999 (8.6.12/IDA-1.6); Tue, 30 Apr 1996 18:40:33 +1000 From: Simon Bennett Received: by murad (5.65) id AA15928; Tue, 30 Apr 1996 18:41:17 +1000 Message-Id: <9604300841.AA15928@murad> Subject: Re: Casting shadows with pfLightSource and OpenGL To: bleclerc@cae.ca (Bernard Leclerc) Date: Tue, 30 Apr 1996 18:41:16 +1000 (EST) Cc: info-performer@sgi.sgi.com In-Reply-To: <9602071424.ZM3292@eagle.cae.ca> from "Bernard Leclerc" at Feb 7, 96 02:24:01 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Status: O > Hi, > > This question is really for the Performer development team... With pf2.0, the > example shadows.C works for IrisGL only. Why isn't it possible to have a > pfLightSource casting shadows with OpenGL? > Thanks I gather it's something to do with not being able to do projected texture effects with OGL and Performer 2.0...(doesn't support a texture matrix perhaps?) I remember hearing something about this and IR systems... It will probably work in 2.0.1 or 2.1... +----------------------------------------------------------------------------+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 9981 0611 (x512) Common Sense doesn't seem to be From guest Tue Apr 30 05:57:15 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id CAA06768; Tue, 30 Apr 1996 02:05:58 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id CAA06765; Tue, 30 Apr 1996 02:05:57 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id CAA15265; Tue, 30 Apr 1996 02:05:57 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA05952; Tue, 30 Apr 1996 02:05:52 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.com id AA17569; Tue, 30 Apr 96 02:05:33 -0700 Received: by rose.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id CAA18688; Tue, 30 Apr 1996 02:03:43 -0700 From: "Sharon Clay" Message-Id: <9604300203.ZM18686@rose.asd.sgi.com> Date: Tue, 30 Apr 1996 02:03:43 -0700 In-Reply-To: dwight@ht.com (Dwight Meglan) "fast isect when inside geometry" (Apr 17, 2:54pm) References: X-Mailer: Z-Mail-SGI (3.2S.2 10apr95 MediaMail) To: dwight@ht.com (Dwight Meglan), info-performer@sgi.sgi.com Subject: Re: fast isect when inside geometry Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On Apr 17, 2:54pm, Dwight Meglan wrote: > Subject: fast isect when inside geometry -> ->I would like to get comment on the best way to quickly do intersection ->testing for moving about inside of a large chunk of geometry. By large I ->mean around 50,000 polygons. By moving around I mean that I want to steer ->the camera about at 15-30 Hz (preferably on an Impact but I can fallback to ->an Onyx) and be constrained to within the boundaries of the geometry. If you don't absolutely have to have results every frame, you might consider forcing a forked intersection process so that if the intersections take a long time, they won't be so likely to hold up the drawing. -> ->Originally the geometry was a couple of giant geosets. We have the tools at ->hand to slice and dice them-- Alias as well as Designer's Workbench. My ->first inclination is to break the data up into hierarchically arranged ->zones like octrees but since I know the geometry (which is not equally ->distributed in space) I can manually, though laborously, group it more ->efficiently than that. There are passageways between sections of the ->geometry also but the geometry is not planar so the pfPortals package won't ->help me here. We'll probably try using fog to move the far clip in and ->limit extra drawing. -> ->My reasoning for this arrangement is that if I understand properly how ->Performer's intersect routines for a pfSegSet work, then I will quickly ->find the geoset(s) that are candidates for an intersection by Performer ->doing bounding volume checks hierarchically (I will have nested groups). ->Once the few small bounding volumes down at the bottom of the hierarchy are ->found polygon intersection checks will be done to find the actual contact ->point(s). This is true. And, if you use pfPartitions, your search for the proper pfGeoSet will be _very_ fast indeed. -> ->I am assuming that this is the fastest possible way to do intersects for ->this situation because: -> ->1. Checking bounding volumes is much faster than polygons -- Performer does ->as much bounding volumes as it can before dropping to polygon checks. ->2. Performer is automatically smart about working its way down through a ->hierarchy of bounding volumes -- look at the top level hierarchy bounding ->volume, if a segment touches it check its children's bounding volumes and ->continue on only those that touch the segment then check their children's ->bounding volumes, etc. until a list of the geoset bounding volumes touching ->the segment is constructed. ->3. Performer will not do polygon intersections until the list of bounding ->volume geosets has been selected in a "first pass" by Performer. In addition, you can provide an enclosing cylinder around your segset which we will test before doing segment intersections. If you can group together a bunch of simillarly directioned segments, this can provide another major speedup. -> ->I am curious what the tradeoff between nesting and number of polygons in a ->geoset should be... should I shoot for 10 polygons in a geoset ? 5? 20? 50? ->Will drawing speed become more of a limiting factor than intersections at ->some point because of inefficient tristrips ? Since the size of pfGeoSets is also going to effect your drawing efficiency, you don't want them tooo small. I'd say a minimum of 12 tris per pfGeoSet and this is really assuming that you are on a low-end gfx system that is not easilty host limited. Since you say you are on an IMPACT, I'd expect that you are more likely fill limited. Generally, for high-end systems, I'd say the good range is more like 24-64 tris. -> ->The final complication is that my camera actual has a long cord behind it ->(think of snaking a cable through an irregular maze) which must be ->continuously checked against the geometry for intersections. This means ->that there are a number of segments that must be check. The question here ->is: -> ->Is it better, in terms of intersection calculation efficiency, for the ->above geometry to check: -> 1. one pfSegSet with all the segments for all the joints of the cord in ->it against the entire scenegraph -> 2. check each segment individually with its own pfSegSet against the ->entire scenegraph -> 3. use on pfSegSet with all the segments but mask it for each segment a ->check once for each segment against the scenegraph If the segments have reasonable spatial locality and direction, put them together and put a cylinder around them. Otherwise, use partitions and do them separately so that you don't have to intersect lots of polygons with segments that have no chance of making a hit. One might also ask if _all_ of the segments require polygon intersection information - maybe for some segments you can stop at just PFTRAV_IS_GEODE for bounding sphere or PFTRAV_IS_GSET for bounding box intersections for setting your pfNodeTravMask(). Also, I am sure that you know this but just to be complete, be sure to enable isect caching on static pfGeoSets with the PFTRAV_IS_CACHE bit set in your setMode to pfNodeTravMask(). I hpoe this helps, src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue Apr 30 08:07:33 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id EAA07087; Tue, 30 Apr 1996 04:08:45 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id EAA07084; Tue, 30 Apr 1996 04:08:44 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id EAA18402; Tue, 30 Apr 1996 04:08:43 -0700 Received: from bitch.reading.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id EAA13089; Tue, 30 Apr 1996 04:08:41 -0700 Received: by bitch.reading.sgi.com (940816.SGI.8.6.9/911001.SGI) id MAA07670; Tue, 30 Apr 1996 12:06:00 +0100 From: "Angus Dorbie" Message-Id: <9604301206.ZM7668@bitch.reading.sgi.com> Date: Tue, 30 Apr 1996 12:06:00 +0100 In-Reply-To: steve@mred.bgm.link.com (Steve Baker) "Re: OpenGVS Benchmark Applic" (Apr 29, 10:29pm) References: <9604300329.AA20537@mred.bgm.link.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: steve@mred.bgm.link.com (Steve Baker), info-performer@sgi.sgi.com Subject: Re: OpenGVS Benchmark Applic Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 29, 10:29pm, Steve Baker wrote: > Subject: Re: OpenGVS Benchmark Applic > RE2 on the "same" database. > > If we take that database back to GVS, what will happen? Well, since > the original version was optimised to death for GVS, it's likely that > the single-CPU rendering that GVS uses will probably suffer greatly > from the increased cull times, leaving little time left for everything > else. Please note, this is NOT a slur on GVS - the Performer version > uses an additional CPU, so it's not a fair test. > >-- End of excerpt from Steve Baker An excellent post but I don't see how you can conclude that this test wasn't fair. I think you've possibly come as close as you can get to a fair test for your application by optimising for Performer and GVS and as far as I can see the reasonable conclusion is that with Performer you can better utilise the SMP and that on some platforms & some applications this has an impact upon rendering performance (not exactly news). This is an area where SGI is very strong and is often a factor in the choice of platform. I think comparrisons of different rendering software on a specific Silicon Graphics platform can be usefull provided the benchmark is tunned for each, up to date and you bear in mind that speed isn't the only performance factor. I'm thinking mainly of features here but ease of use is important to a broader community, as are portability and open standards. I would also suggest that as more vendors adopt the OpenGL rendering specification that cross platform benchmarks will become more usefull although this is open to gross abuse(and ignorance), and many will never adopt OpenGL. In any case, many of your objections to this approach would still remain valid. Rgds, Angus. -- Angus Dorbie, The Reality Centre, Silicon Graphics Ltd, UK dorbie@reading.sgi.com From guest Tue Apr 30 10:15:47 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id FAA07212; Tue, 30 Apr 1996 05:59:17 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id FAA07209; Tue, 30 Apr 1996 05:59:16 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id FAA21069; Tue, 30 Apr 1996 05:59:16 -0700 Received: from trident.neiddd.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA19596; Tue, 30 Apr 1996 05:59:12 -0700 Received: from ohio.neiddd.com by trident.neiddd.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for <@trident.neiddd.com:info-performer@sgi.com> id JAA05341; Tue, 30 Apr 1996 09:00:48 -0400 Received: by ohio.neiddd.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id JAA05545; Tue, 30 Apr 1996 09:00:50 -0400 From: "Ray Twiddy" Message-Id: <9604300900.ZM5543@ohio.neiddd.com> Date: Tue, 30 Apr 1996 09:00:48 -0400 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: info-performer@sgi.sgi.com Subject: pfEarthSky Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Does pfEarthSky work only with a positive Z up viewing frusta? My application is based upon a geocentric coordinate system in which the up vector is determined by the location in longitude and latitude. Will I have to transform my terrain model to a positive Z up in order for pfEarthSky to work correctly? -- Ray Twiddy | / ____/ / NEI - Nomura Enterprise Inc. rltwiddy@neiddd.com | / / / 14240-G Sullyfield Circle Bus. (703) 818-1990 / | / ___/ / Chantilly, VA 22021 FAX (703) 818-7626 / / / / ___________________________________________________ __/ __/ _____/ __/ From guest Tue Apr 30 13:08:58 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA08049; Tue, 30 Apr 1996 08:26:03 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA08046; Tue, 30 Apr 1996 08:26:02 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA26679; Tue, 30 Apr 1996 08:26:02 -0700 Received: from dub-img-1.compuserve.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA06018; Tue, 30 Apr 1996 08:26:01 -0700 Received: by dub-img-1.compuserve.com (8.6.10/5.950515) id LAA26688; Tue, 30 Apr 1996 11:25:57 -0400 Date: 30 Apr 96 11:22:55 EDT From: Ian McCallum <100424.1071@CompuServe.COM> To: "(unknown)" Subject: Unsubscribe Message-ID: <960430152255_100424.1071_BHG87-1@CompuServe.COM> Status: O Please Unsubscibe me From guest Tue Apr 30 12:48:56 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id IAA07993; Tue, 30 Apr 1996 08:06:43 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id IAA07990; Tue, 30 Apr 1996 08:06:43 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id IAA25894; Tue, 30 Apr 1996 08:06:42 -0700 Received: from ldsa.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA03408; Tue, 30 Apr 1996 08:06:35 -0700 From: dheskamp@ldsa.com Received: from ldsa.com (dgate) by ldsa.com (5.x/SMI-SVR4) id AA14806; Tue, 30 Apr 1996 11:01:58 -0400 Received: from ldsa (sun294) by ldsa.com (5.x/SMI-SVR4) id AA17637; Tue, 30 Apr 1996 11:06:49 -0400 Received: from pc1197.ldsa by ldsa (5.x/SMI-SVR4) id AA21595; Tue, 30 Apr 1996 11:06:48 -0400 To: info-performer@sgi.sgi.com Subject: BUG in pfdBreakup Date: Tue, 30 Apr 96 11:07:36 EDT Message-Id: <9604301507.244B6C@pc1197.ldsa> X-Mailer: SelectMAIL 1.2 Status: O hello... The man page for pfdBreakup (Performer 2.0-beta) states that it does not work on indexed pfGeoStes. Does pfdBreakup work on indexed pfGeosets in any released version of Performer, (say 2.0 or 2.1)? Dave Heskamp Lockheed Martin Tactical Defense Systems 1210 Massillon Road Akron, Ohio 44315-0001 phone: (330) 796 - 5383 fax: (330) 796 - 7009 email: dheskamp@ldsa.com From guest Tue Apr 30 14:58:56 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA08426; Tue, 30 Apr 1996 10:16:59 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA08423; Tue, 30 Apr 1996 10:16:58 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA02538; Tue, 30 Apr 1996 10:16:57 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA24283; Tue, 30 Apr 1996 10:16:53 -0700 Received: from precious.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA00264; Tue, 30 Apr 96 10:16:51 -0700 Received: (from nemec@localhost) by precious.asd.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA11096; Tue, 30 Apr 1996 10:14:00 -0700 From: "Philip Nemec" Message-Id: <9604301014.ZM11094@precious.asd.sgi.com> Date: Tue, 30 Apr 1996 10:14:00 -0700 In-Reply-To: jrohlf@tubes (John Rohlf) "Re: Formatting of perfly code" (Apr 29, 3:22pm) References: <199604292222.PAA01312@tubes.asd.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: jrohlf@tubes.asd.sgi.com (John Rohlf), guest (Greg Edwards, SGI UK.) Subject: Re: Formatting of perfly code Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O For Emacs 19.30 I've found that: (setq c-file-style "Stroustrup") does the trick. From guest Tue Apr 30 14:55:46 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA08401; Tue, 30 Apr 1996 10:08:09 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA08398; Tue, 30 Apr 1996 10:08:09 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id KAA02260; Tue, 30 Apr 1996 10:08:08 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA22468; Tue, 30 Apr 1996 10:07:36 -0700 Received: from dandan.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA29774; Tue, 30 Apr 96 10:07:18 -0700 Received: by dandan.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA15680; Tue, 30 Apr 1996 10:04:22 -0700 From: "Jenny Zhao" Message-Id: <9604301004.ZM15678@dandan.asd.sgi.com> Date: Tue, 30 Apr 1996 10:04:22 -0700 In-Reply-To: "Sharon Clay" "Re: fast isect when inside geometry" (Apr 30, 2:03am) References: <9604300203.ZM18686@rose.asd.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Sharon Clay" , dwight@ht.com (Dwight Meglan), info-performer@sgi.sgi.com Subject: Re: fast isect when inside geometry Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 30, 2:03am, Sharon Clay wrote: > Subject: Re: fast isect when inside geometry > +>---- On Apr 17, 2:54pm, Dwight Meglan wrote: > > Subject: fast isect when inside geometry > -> > ->The final complication is that my camera actual has a long cord behind it > ->(think of snaking a cable through an irregular maze) which must be > ->continuously checked against the geometry for intersections. This means > ->that there are a number of segments that must be check. The question here > ->is: > -> > ->Is it better, in terms of intersection calculation efficiency, for the > ->above geometry to check: > -> 1. one pfSegSet with all the segments for all the joints of the cord in > ->it against the entire scenegraph > -> 2. check each segment individually with its own pfSegSet against the > ->entire scenegraph > -> 3. use on pfSegSet with all the segments but mask it for each segment a > ->check once for each segment against the scenegraph > > If the segments have reasonable spatial locality and direction, put > them together and put a cylinder around them. > Otherwise, use partitions and do them separately so that you don't have > to intersect lots of polygons with segments that have no chance of making a hit. > > One might also ask if _all_ of the segments require polygon intersection > information - maybe for some segments you can stop at just PFTRAV_IS_GEODE > for bounding sphere or PFTRAV_IS_GSET for bounding box intersections for > setting your pfNodeTravMask(). > > Also, I am sure that you know this but just to be complete, be sure > to enable isect caching on static pfGeoSets with the PFTRAV_IS_CACHE bit > set in your setMode to pfNodeTravMask(). > > > I hpoe this helps, > src. > an additional thought i have on this point is that since your cord is a "snake", the body of the snake must follow the rough path of the head of snake. so if you can add a thick cylinder (the size of which depends on the size of your path way) at the head of the snake and remember the objects that intersected the cylinder, then all the joints in the body of the snake only need to intersect with these objects instead of the whole scene. it is extra work, but it probably will save you time with your big database. jenny zhao > -- > -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ > Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev. > src@sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590 > -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ > >-- End of excerpt from Sharon Clay From guest Tue Apr 30 15:22:54 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id KAA08469; Tue, 30 Apr 1996 10:37:37 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.csd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id KAA08462; Tue, 30 Apr 1996 10:36:37 -0700 Received: from sgi.engr.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.csd.sgi.com id AA01544; Tue, 30 Apr 96 10:35:49 -0700 Received: from gemtech.gemtech.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id KAA27857; Tue, 30 Apr 1996 10:35:40 -0700 Received: from mac-server.gemtech.com by gemtech.gemtech.com via SMTP (950911.SGI.8.6.12.PATCH825/940406.SGI) id KAA27075; Tue, 30 Apr 1996 10:33:12 -0700 Message-Id: <199604301733.KAA27075@gemtech.gemtech.com> Date: 30 Apr 1996 10:44:48 -0800 From: "John Archdeacon" Subject: Re: OpenGVS Benchmark Appli To: "Michael T. Jones" Cc: "info-performer@giraffe.asd.sgi." Status: O Reply to: RE>>OpenGVS Benchmark Applic Hello all. Michael Jones wrote the following regarding the proposed OpenGVS Benchmarks to the Performer news group: > Well, considering how little your long OpenGVS advertisement had to do with > Performer ... I'll go ahead and forward it (to info-perfomer) since you say it's OK. Clarification: I was *not* sending out any advertisements as I respect the spirit of a technical news group such as info-performer; Gemini was simply responding to a couple of emails from *Performer users* that brought up questions about cross platform solutions and an OpenGVS *direct reference* from the United States Army. Michael Jones also wrote: > The GVS versions only speak to GVS speeds on the machine. > They do not measure the machine. That would be like a ISV PHIGS > company ranking workstations on drawing a car model based on their PHIGS > implementation... There is no need for GVS code, for binaries, etc. Just the > databases and example information so that people porting the tests to other > environments can make the test measurements fairly. First, OpenGVS does not use PHIGS as you know; it uses OpenGL for machines which natively implement it (SGI workstations, Intergraph Pentium workstations, Pentiums with 3DLabs GLINT accelerators, and so on). As you also know, OpenGL was invented by SGI and we use it because it is *good* and it offers users (OpenGVS and others) great *portability*. An OpenGVS implementation on any OpenGL machine is *very* close, making OpenGVS (and the proposed benchmarks) an ideal environment (in our minds) for evaluating *relative* performance between different systems since the underlying implementation, databases, and application software are essentially *identical* (note: we do conditionally use OpenGL extensions on systems like RE2 or Integraph if those extensions improve graphics performance...). Although we believe OpenGVS to be extremely efficient with a proper utilization of the underyling OpenGL graphics hardware, we recognize and have never claimed that these benchmarks represent the final word in performance f or any system, just *relative* performance where the popular and well recognized performance of a single-pipe, single-CPU RE2 represents our normalized 1.0 metric in a realistic "workload" (not simply spinning tea pots or single car models). This simple foundation using common workload is the *basis* of this proposed benchmark (at least Version 1.0). Second, we are not proposing rendering a car model; we are proposing real-world benchmarks where the OpenGVS is used (not just a database) so one *can* measure relative performance easily since we have near *identical* workload. In case you haven't had a chance to read the final benchmark proposal (which should help clarify the intent of the paper), it has been published on the web at: http://www.gemtech.com/rwbench/proposal.html Michael Jones wrote: > I have accepted the head-to-head test that you proposed. > Are you backing out of it now? I don't see why you would do that after making > such a big splash in the Performer mailing list with your original announcement. > I hope that I misunderstand your new position. I urge you to follow through > with the plan to make the databases and eyepoint/vehicle information avaliable > as your test suite... First, this is not a contest between OpenGVS and Performer; sorry you see it that way. Again, just to make sure we are communicating, Gemini will also immediately *stop* responses to your private Performer news group when there are no more open forum questions/responses made to Gemini and our products. I offered to do this in my last response as you know... Second, Gemini has *not* changed to a new position as you have suggested. The version 1.0 benchmark suite as proposed (again, the paper is on the web) will be designed and implemented using OpenGVS. Any "version 2.0" extensions to the benchmark suite can and will be addressed later and SGI's (and other) comments or suggestions can be considered later. Thanks for your suggestions though. Cheers! John Archdeacon From guest Tue Apr 30 16:39:58 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id LAA08734; Tue, 30 Apr 1996 11:53:28 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id LAA08731; Tue, 30 Apr 1996 11:53:18 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id LAA08000; Tue, 30 Apr 1996 11:53:17 -0700 Received: from buggy.coryphaeus.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA12681; Tue, 30 Apr 1996 11:53:14 -0700 Received: by buggy.coryphaeus.com (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA01268; Tue, 30 Apr 1996 11:47:23 -0700 Date: Tue, 30 Apr 1996 11:47:23 -0700 From: kowsik@coryphaeus.com (Kowsik Guruswamy) Message-Id: <9604301147.ZM1266@buggy.coryphaeus.com> In-Reply-To: "Sharon Clay" "Re: fast isect when inside geometry" (Apr 30, 2:03am) References: <9604300203.ZM18686@rose.asd.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Sharon Clay" , dwight@ht.com (Dwight Meglan), info-performer@sgi.sgi.com Subject: Re: fast isect when inside geometry Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On Apr 30, 2:03am, Sharon Clay wrote: > Subject: Re: fast isect when inside geometry > +>---- On Apr 17, 2:54pm, Dwight Meglan wrote: > > Subject: fast isect when inside geometry > -> > ->I would like to get comment on the best way to quickly do intersection > ->testing for moving about inside of a large chunk of geometry. By large I > ->mean around 50,000 polygons. By moving around I mean that I want to steer > ->the camera about at 15-30 Hz (preferably on an Impact but I can fallback to > ->an Onyx) and be constrained to within the boundaries of the geometry. > > If you don't absolutely have to have results every frame, you might consider > forcing a forked intersection process so that if the intersections > take a long time, they won't be so likely to hold up the drawing. > [snip] > This is true. And, if you use pfPartitions, your search for the proper > pfGeoSet will be _very_ fast indeed. > [snip] > Since the size of pfGeoSets is also going to effect your drawing efficiency, > you don't want them tooo small. I'd say a minimum of 12 tris per > pfGeoSet and this is really assuming that you are on a low-end gfx system > that is not easilty host limited. Since you say you are on an IMPACT, I'd > expect that you are more likely fill limited. Generally, for high-end > systems, I'd say the good range is more like 24-64 tris. [snip] > If the segments have reasonable spatial locality and direction, put > them together and put a cylinder around them. > Otherwise, use partitions and do them separately so that you don't have > to intersect lots of polygons with segments that have no chance of making a hit. > > One might also ask if _all_ of the segments require polygon intersection > information - maybe for some segments you can stop at just PFTRAV_IS_GEODE > for bounding sphere or PFTRAV_IS_GSET for bounding box intersections for > setting your pfNodeTravMask(). > > Also, I am sure that you know this but just to be complete, be sure > to enable isect caching on static pfGeoSets with the PFTRAV_IS_CACHE bit > set in your setMode to pfNodeTravMask(). If I may add, since Performer uses separate masks for APP, CULL, DRAW and ISECT and because of the fact that a set of geometry that's tuned for rendering may not be the most efficient set for collision, you might think about a simplified set of geometry [with lesser number of polygons] for the ISECT process. This definitely means more memory, but the benefits of having a specialized set of geometry just for collision might be worthwhile considering. K. -- kowsik@coryphaeus.com | pirts suiboM a hguorht neeb sah txet sihT http://www.coryphaeus.com | | You are not you, you are me! - arnie work: (408)-395-4537 e201 | From guest Wed May 1 00:11:57 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id RAA11851; Tue, 30 Apr 1996 17:48:24 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id RAA11848; Tue, 30 Apr 1996 17:48:09 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id RAA27552; Tue, 30 Apr 1996 17:48:09 -0700 Received: from netcom11.netcom.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA11804; Tue, 30 Apr 1996 17:48:03 -0700 Received: (from cutt@localhost) by netcom11.netcom.com (8.6.13/Netcom) id RAA07963; Tue, 30 Apr 1996 17:47:57 -0700 Date: Tue, 30 Apr 1996 17:47:57 -0700 (PDT) From: "Paul S. Cutt" Subject: Re: VR head mounted devices (HMD) for SGI? To: Nicolas Gauvin cc: info-performer@sgi.sgi.com In-Reply-To: <199604292045.QAA01663@osprey.cae.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O We make device drivers and have a device API for HMDs. One we recommend is Virtual IO i-glasses (we did the device API for them). paul On Mon, 29 Apr 1996, Nicolas Gauvin wrote: > > I would like to know which VR head mounted devices (HMD) are compatible > with SGI hardware. I'm looking for low cost HMD as well as high fidelity ($$) > ones. I would also like to know if they can work on all SGI platforms or not > (Indys in mono mode for example). I've seen very low cost devices > available for PCs (like the VFX1). Can those be hooked to SGIs as well? > > I would appreciate if some of you could share your experiences in those > areas. > > Thanks in advance. > ___/ | ___/ Nicolas Gauvin e-mail: nicolas@cae.ca > / / | / Software Developper voice: (514) 341-2000 x2275 > / / | __/ CAE Electronics Ltd. fax: (514) 340-5496 > / ___ | / 8585 Cote De Liesse, P.O. Box 1800 > _____/ _/ _| _____/ Saint-Laurent, Quebec, Canada, H4L-4X4 > XVS-SyncLink (TM) A Standard Device Interface for Virtual Environments and Applications Benefits XVS-SyncLinkTM is a C++ class library that simplifies adding and maintaining virtual reality (VR) sensor support in existing applications. It provides a standard device interface for including virtual environment devices into applications. Virtual environments have led to the proliferation of 3D devices with multiple degrees of freedom x,y,z,roll,pitch,yaw). Each device has its own strengths and weaknesses, and the creation of new devices brings with it a constant improvement in the capabilities available. However, using these devices in applications is not easy. Many of these devices are mutually incompatible. They have different command sets; they use different command syntax for the same commands; the output they give to the computer follows different binary formats; and the same type of data is presented using different coordinate systems. Until now, the near-total lack of standardization of even the simplest virtual reality functions has discouraged developers from supporting multiple devices, or adding any VR support to their applications at all. SyncLink takes the load off the application developer by providing a standardized and portable object-oriented set of VR device drivers. This lets the developer concentrate on the applications, rather than the idiosyncracies of each VR device. Object Oriented SyncLink provides an object-oriented interface to VR devices. There is a single C++ class hierarchy for VR sensors. This hierarchy currently handles 6-D sensors such as the Polhemus Fastrak, Logitech 3D Mouse, Ascension Flock of Birds, Spaceball 2003, and the VPL Research DataGlove Model 2. A second C++ class for coordinate systems allows the application programmer to translate automatically between the differing coordinate systems used by VR devices, 3D rendering systems, and existing applications and data sets. Common Interface All devices which provide 6-degree of freedom position and orientation data are handled similarly. SyncLink's base sensor class provides standard operations for opening devices, closing devices, and reading position, Euler angles, toggles, and other device data. Common filtering operations are also avaiable in the base class, including origin offset, setting tolerance levels, clipping, modulo, and scaling. Each device may report data in either absolute or relative values, whether it is an isometric device like the Spaceball, or an isotonic device like the Fastrak. While the SyncLink base class provides a common interface to common VR functions across different devices, it does not limit the application programmer to the lowest common denominator. Device-specific functions are also provided. For example, Fastrak and Flock of Birds users can make use of the multistation capabilities of these devices, allowing multiple receivers to be read from a single serial port. DataGlove Model 2 programmers can calibrate the glove and read and write ASCII-formatted calibration tables. Logitech users may access the fringe and out of range settings which warn when the receiver is approaching its line-of-sight limits. Sample application code provided with SyncLink demonstrates how the same source code can be used to control any of the supported sensors. Switching Sensors SyncLink's common interface makes it easy to switch between sensors from within an application. Simply close and delete the old sensor object, create and open a new sensor object, and reapply the application's sensor filters. Even this level of detail can be hidden from the user by the application. No longer do the software incompatibilities between sensors inhibit switching between them from within an application. Customized Support Xtensory provides the services for adding customized device support. Custom devices can then use the same standard object-oriented interface as commercial devices, without losing access to the functionality that makes the device unique. Maintenance Xtensory provides support for upgrades and maintains the drivers as new devices become available. Portability SyncLink provides portability between different UNIX and POSIX platforms. The same C++ class library is available for Silicon Graphics, Kubota Pacific, and Digital Equipment systems. Devices Supported Ascension Flock of Birds General Reality CyberEye General Reality DataGlove Immersion Probe and Personal Digitizer Logitech 3D Mouse, Cyberman and Space Control Mouse/Magellan Origin Instruments DynaSight Polhemus Fastrak, Isotrak, and 3Ball Precision Navigation Wayfinder Spaceball 2003 Virutal I/O i-glasses! Virtual Technologies CyberGlove VPL DataGlove Model 2 5DT 5-Glove System Requirements SyncLink includes a C++ object library, C++ header files, and sample C++ test software. SyncLink requires one of the following operating systems: SGI IRIX 5.2 or later Digital OSF/1 1.3 or later Microsoft Windows NT 3.5 Microsoft Windows 3.1 HP-UX 9.0 or later Sun SyncLink also requires the appropriate C/C++ compiler for the platform: SGI C++ 3.0 Digital C++ 1.3 or later Microsoft Visual C++ HP Sun Contact Xtensory regarding support for VR devices or UNIX/POSIX operating systems not listed above. Xtensory Inc 140 Sunridge Drive Scotts Valley CA 95066 USA Tel 408/439-0600 Fax 408/439-8845 cutt@netcom.com ...opening the doors of perception (TM) From guest Wed May 1 02:14:26 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id TAA12225; Tue, 30 Apr 1996 19:53:05 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id TAA12222; Tue, 30 Apr 1996 19:52:55 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id TAA02255; Tue, 30 Apr 1996 19:52:54 -0700 Received: from mred.bgm.link.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id TAA23806; Tue, 30 Apr 1996 19:52:43 -0700 Received: by mred.bgm.link.com (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA22917; Tue, 30 Apr 96 21:49:14 -0500 Date: Tue, 30 Apr 96 21:49:14 -0500 From: steve@mred.bgm.link.com (Steve Baker) Message-Id: <9605010249.AA22917@mred.bgm.link.com> To: info-performer@sgi.sgi.com Subject: Re: OpenGVS Benchmark Appli Status: O > First, this is not a contest between OpenGVS and Performer; > Second, Gemini has *not* changed to a new position as you have suggested. What exactly *are* you proposing? It's beginning to sound a lot like you are only really producing an OpenGL performance suite. If you are really aiming at the latter, then may I suggest that you pool your efforts with those already attacking this problem: Check out the OpenGL Performance Characterization (OPC) Project Proposal at http://sunsite.unc.edu/gpc/opc.html ...and the Viewperf OpenGL benchmark code at http://www.sgi.com/Technology/openGL/OPC.html I'm sure that most simulation people will tell you that raw OpenGL thoughput doesn't tell you much about the overall performance of a system in normal use. ---oooOOOooo--- This discussion is getting nowhere fast. I'm getting the impression that no two people agree on what they think they will get from this so-called benchmark suite. Would John Archdeacon please answer the following questions as simply as possible so that we can all understand what he is trying to achieve:- ---oooOOOooo--- 1) What are you attempting to compare using your benchmark suite? a) All IG's? b) Only IG's that currently run OpenGL? c) Only IG's that currently run OpenGVS? d) Only IG's that currently run OpenGVS on top of OpenGL? 2) For a benchmark to be meaningful, all the systems under test must presumably produce essentially the same end result. What end results are required in order to be considered as having sucessfully run the benchmark? There must be some kind of standard or else I can get really good times just by halving all the LOD transition ranges, or ignoring the textures or not bothering to Gouraud shade anything. 3) Am I allowed to restructure the database in order to get it to run faster? If so, to what degree? I have often managed to get a 4:1 performance improvement by restructuring the database to better suite the IG's inner workings. 4) Is the only test software that we are allowed to use OpenGVS? If so, what benchmark figure does a single-pipe, two-CPU RE2 and a single-pipe, four-CPU RE2 achieve? If the answer is anything close to 1.0 then I think we can all end this discussion right now since the ability to make use of multiple CPUs in the image generation process is a really critical issue in IG performance. Thanks John. ---oooOOOooo--- BTW: I know that Gemini are in favour of standards and portability - it's a shame that their web page: http://www.gemtech.com/rwbench/rwbv1.pdf is formatted in a format that I can't read on anything except a PC or a Mac. Ghostscript choked and died when I fed it the postscript version. How about an HTML version guys! Steve Baker 817-323-1361 (Vox-Lab) Hughes Training Inc. 817-695-8776 (Vox-Office/vMail) 2200 Arlington Downs Road 817-695-4028 (Fax) Arlington, Texas. TX 76005-6171 steve@mred.bgm.link.com (eMail) From guest Wed May 1 05:24:42 1996 Received: by holodeck.csd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for info-performer-dist id XAA12641; Tue, 30 Apr 1996 23:55:46 -0700 Return-Path: Received: from rock.csd.sgi.com by holodeck.csd.sgi.com via ESMTP (950413.SGI.8.6.12/940406.SGI.AUTO) for id XAA12638; Tue, 30 Apr 1996 23:55:24 -0700 Received: from sgi.sgi.com by rock.csd.sgi.com via ESMTP (950413.SGI.8.6.12/910805.SGI) for id XAA08867; Tue, 30 Apr 1996 23:55:27 -0700 Received: from giraffe.asd.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id XAA11083; Tue, 30 Apr 1996 23:55:25 -0700 Received: from kid.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA07448; Tue, 30 Apr 96 23:54:48 -0700 Received: from localhost by kid.asd.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) id XAA18168; Tue, 30 Apr 1996 23:54:36 -0700 Message-Id: <199605010654.XAA18168@kid.asd.sgi.com> To: bleclerc@cae.ca Cc: info-performer@sgi.sgi.com Subject: Re: (Fwd) Re: shadows in performer In-Reply-To: Your message of "Mon, 29 Apr 96 22:04:59 PDT." <9604292204.ZM18044@rose.asd.sgi.com> Date: Tue, 30 Apr 96 23:54:36 -0700 From: Simon Hui Status: O > From: "Bernard Leclerc" > Subject: Re: shadows in performer > > John Rolf from SGI sent me the following concerning shadows on Infinite > Reality. One question remains: Is this comment still valid considering the > soon-to-come release of Irix 6.2 and Performer 2.1? Yes, the comment about shadows is still valid for Irix 6.2 and Performer 2.1. (Performer 2.1 does take advantage of a number of hardware features of InfiniteReality, but shadows is not one of them). Support for shadows under OpenGL did not make it into Performer 2.1. It will be added in the next Performer release. regards, Simon > --- Forwarded mail from jrohlf@tubes.asd.sgi.com (John Rohlf) > > From: jrohlf@tubes.asd.sgi.com (John Rohlf) > Subject: Re: Performer 2.0 on InfiniteReality > > Performer 2.0 does not yet take full advantage of the new > InfiniteReality OpenGL-based Hardware since some OpenGL extensions > which access the hardware have not yet been implemented. > The shadow extension has not been implemented yet and even if it > makes it for the InfiniteReality release, 2.0 will not be able > to use it.