From guest Mon May 1 11:16:28 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA00751; Mon, 1 May 1995 11:12:01 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA00748; Mon, 1 May 1995 11:12:01 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04370; Mon, 1 May 95 11:11:59 -0700 Received: from flipper.gcs.redstone.army.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA18550; Mon, 1 May 1995 11:11:58 -0700 Received: by flipper.gcs.redstone.army.mil (931110.SGI/930416.SGI) for info-performer@sgi.com id AA20001; Mon, 1 May 95 13:21:09 -0500 From: "Jeffrey A. Biggs" Message-Id: <9505011321.ZM19999@flipper.gcs.redstone.army.mil> Date: Mon, 1 May 1995 13:21:08 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: DFAD Reader Cc: biggs@flipper.gcs.redstone.army.mil Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi, We are interested in using a subset of DMA DFAD with Performer. Any DFAD readers/processor source code would be greatly appreciated. Regards, -- -------------------------------------------------------------------------------- Jeffrey A. Biggs ************** U.S. Army Missile Command ****************** 205/842.6909 (voice) ** ** 205/876.7165 (fax) ** *\ /* ** ** **\ /** ** ** ***\ /*** ** ** ***/ \*** ** ** *** *** ** ** ****** ** ** **** ** biggs@flipper.gcs.redstone.army.mil ** ** ** ** ** ****** -------------------------------------------------------------------------------- From guest Mon May 1 15:54:48 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA01564; Mon, 1 May 1995 15:51:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA01561; Mon, 1 May 1995 15:51:47 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18637; Mon, 1 May 95 15:51:45 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA20383; Mon, 1 May 1995 15:51:43 -0700 Received: from eclipse.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA22153; Mon, 1 May 95 18:53:12 EDT From: hall@vsl.ist.ucf.edu (Gary Hall - (Kimberly Abel)) Received: by eclipse.vsl.ist.ucf.edu (4.1) id AA04497; Mon, 1 May 95 18:50:52 EDT Message-Id: <9505012250.AA04497@eclipse.vsl.ist.ucf.edu> Subject: Re: Reduction of 3-D geometric complexity To: guest (Stella M. Yu 333 - 6799/483 - 1690) Date: Mon, 1 May 95 18:50:52 EDT Cc: info-performer@sgi.sgi.com In-Reply-To: <01HPZVV5A1USQO7JR6@ASD2.JSC.NASA.GOV>; from "Stella M. Yu 333 - 6799/483 - 1690" at May 1, 95 9:52 pm X-Mailer: ELM [version 2.3 PL0] Status: O > > Hi, > > I want to apologize for this non-Performer related question. We are > looking for some software package that will reduce the number of faces of 3-D > polygonal models. If anyone has some information, please send a message to > yu@asd1.jsc.nasa.gov > > Your help is greatly appreciated. > > Stella Yu > Lockheed Martin, Houston > > > > Packages like Wavefront are very good at polygon reduction. You can you use Wavefront to generate say 5 different versions of a model and then put them all together into say one file format that supports level of details like Designer's workbench (DWB) or Multigen which only have limited polygon reduction techniques. Also DWB can read in Wavefront files directly. -- Gary Hall 407-658-0041 Coryphaeus Software gary@coryphaeus.com Orlando, FL From guest Mon May 1 15:18:35 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA01384; Mon, 1 May 1995 15:15:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA01381; Mon, 1 May 1995 15:15:17 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16982; Mon, 1 May 95 15:15:15 -0700 Received: from ASD2.JSC.NASA.GOV by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA12645; Mon, 1 May 1995 15:15:09 -0700 Received: with SMTP-MR; Mon, 1 May 1995 23:13:11 CDT Mr-Received: by mta ASD1; Relayed; Mon, 01 May 1995 23:13:11 -0500 (CDT) Alternate-Recipient: prohibited Disclose-Recipients: prohibited Date: Mon, 1 May 1995 21:52:00 CDT From: "Stella M. Yu 333 - 6799/483 - 1690" Subject: Reduction of 3-D geometric complexity To: info-performer@sgi.sgi.com Message-Id: <01HPZVV5A1USQO7JR6@ASD2.JSC.NASA.GOV> Mime-Version: 1.0 Content-Type: TEXT/PLAIN Posting-Date: Mon, 1 May 1995 22:05:00 CDT Importance: normal X400-Mts-Identifier: [;11313210505991/443671@ASD] A1-Type: MAIL Hop-Count: 0 Status: O Hi, I want to apologize for this non-Performer related question. We are looking for some software package that will reduce the number of faces of 3-D polygonal models. If anyone has some information, please send a message to yu@asd1.jsc.nasa.gov Your help is greatly appreciated. Stella Yu Lockheed Martin, Houston From guest Tue May 2 02:41:12 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA03276; Tue, 2 May 1995 02:38:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA03273; Tue, 2 May 1995 02:38:35 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06846; Tue, 2 May 95 02:38:34 -0700 Received: from caliban by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA28570; Tue, 2 May 1995 02:37:43 -0700 Received: by caliban (931110.SGI/921111.SGI) for info-performer@sgi.com id AA11795; Tue, 2 May 95 10:33:30 +0100 From: "Angus Dorbie" Message-Id: <9505021033.ZM11793@caliban> Date: Tue, 2 May 1995 10:33:30 +0100 In-Reply-To: "Stella M. Yu 333 - 6799/483 - 1690" "Reduction of 3-D geometric complexity" (May 1, 9:52pm) References: <01HPZVV5A1USQO7JR6@ASD2.JSC.NASA.GOV> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: yu@asd1.jsc.nasa.gov Subject: Re: Reduction of 3-D geometric complexity Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O There's a load of C++ source code for the 1993 SigGraph paper "Mesh Optimisation" by Hughes Hopp, Tony DeRose, Tom Duchamp, John MacDonald and Werner Stuetzle @ University of Washington. The meshing code is also closely related to a couple of SigGraph reconstruction papers. I have it on good authority that this algorithm is the dogs bollocks. http://www.cs.washimgton.edu:80/homes/derose/grail/materials.html This page points to the files you may be interested in. -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.demon.co.uk UK From guest Tue May 2 02:55:37 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA03289; Tue, 2 May 1995 02:51:55 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA03286; Tue, 2 May 1995 02:51:51 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07027; Tue, 2 May 95 02:51:47 -0700 Received: from gate.demon.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA29402; Tue, 2 May 1995 02:51:45 -0700 Received: from division.demon.co.uk by gate.demon.co.uk id aa05739; 2 May 95 10:49 GMT-60:00 Received: from caliban.division.demon.co.uk by division.demon.co.uk (AIX 3.2/UCB 5.64/4.03) id AA11493; Tue, 2 May 1995 10:54:45 +0100 Received: by caliban (931110.SGI/921111.SGI) for info-performer@sgi.com id AA11862; Tue, 2 May 95 10:54:45 +0100 From: Angus Dorbie Message-Id: <9505021054.ZM11860@caliban> Date: Tue, 2 May 1995 10:54:44 +0100 In-Reply-To: "Stella M. Yu 333 - 6799/483 - 1690" "Reduction of 3-D geometric complexity" (May 1, 9:52pm) References: <01HPZVV5A1USQO7JR6@ASD2.JSC.NASA.GOV> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Reduction of 3-D geometric complexity Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O There's a load of C++ source code for the 1993 SigGraph paper "Mesh Optimisation" by Hughes Hopp, Tony DeRose, Tom Duchamp, John MacDonald and Werner Stuetzle @ University of Washington. The meshing code is also closely related to a couple of SigGraph reconstruction papers. I have it on good authority that this algorithm is the dogs bollocks. http://www.cs.washimgton.edu:80/homes/derose/grail/materials.html This page points to the files you may be interested in. -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.demon.co.uk UK From guest Tue May 2 06:27:44 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA03785; Tue, 2 May 1995 06:25:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA03782; Tue, 2 May 1995 06:25:33 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10626; Tue, 2 May 95 06:25:32 -0700 Received: from holodeck.gsfc.nasa.gov by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA12770; Tue, 2 May 1995 06:25:30 -0700 Received: by holodeck.gsfc.nasa.gov (940816.SGI.8.6.9/930416.SGI.AUTO) id JAA11819; Tue, 2 May 1995 09:25:26 -0400 From: maher@holodeck.gsfc.nasa.gov (Stephen Maher) Message-Id: <199505021325.JAA11819@holodeck.gsfc.nasa.gov> Subject: Re: Reduction of 3-D geometric complexity To: angus@caliban.gsfc.nasa.gov (Angus Dorbie) Date: Tue, 2 May 1995 09:25:22 -0400 (EDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <9505021033.ZM11793@caliban> from "Angus Dorbie" at May 2, 95 10:33:30 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 946 Status: O > > There's a load of C++ source code for the 1993 SigGraph paper > "Mesh Optimisation" by Hughes Hopp, Tony DeRose, Tom Duchamp, > John MacDonald and Werner Stuetzle @ University of Washington. > The meshing code is also closely related to a couple of > SigGraph reconstruction papers. > > I have it on good authority that this algorithm is the > dogs bollocks. I'm sorry, but "bollocks" is not in my Webster's Ninth Collegiate and I haven't spent much time in the UK. If someone calls me the "dogs bollocks" should I punch him or shake his hand? Steve.Maher@gsfc.nasa.gov > > http://www.cs.washimgton.edu:80/homes/derose/grail/materials.html > > This page points to the files you may be interested in. > > -- > Angus Dorbie Division Ltd, > Software Engineer 19 Apex Court, > Tel: (01454)615554 Woodlands, > Fax: (01454)615532 Bristol BS12 4JT, > angus@division.demon.co.uk UK > > From guest Tue May 2 06:54:53 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA03826; Tue, 2 May 1995 06:52:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA03823; Tue, 2 May 1995 06:52:59 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11171; Tue, 2 May 95 06:52:58 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id GAA15039; Tue, 2 May 1995 06:52:56 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) id GAA27996; Tue, 2 May 1995 06:52:54 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id OAA07590; Tue, 2 May 1995 14:48:12 +0100 From: "Rob Jenkins" Message-Id: <9505021448.ZM7588@barney.reading.sgi.com> Date: Tue, 2 May 1995 14:48:12 +0100 In-Reply-To: deepa@tcsernet.tcs.ernet.in "Perfly bug?" (May 2, 5:39pm) References: <9505021739.AA03986@tcsernet.tcs.ernet.in> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: deepa@tcsernet.tcs.ernet.in, info-performer@sgi.sgi.com Subject: Re: Perfly bug? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Can you try adjusting the near clipping plane closer to you ( via the GUI in perfly ) and see if it helps. Note - remember that in an application it's always good to keep the ratio of near:far clipping planes down to help zbuffer resolution and moving the near plane closer to the eye can drastically effect that ratio. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Tue May 2 07:00:25 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA03837; Tue, 2 May 1995 06:58:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA03834; Tue, 2 May 1995 06:58:17 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11274; Tue, 2 May 95 06:58:16 -0700 Received: from thor.ats.qc.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA15617; Tue, 2 May 1995 06:58:14 -0700 Received: (from jaydee@localhost) by thor.ats.qc.ca (8.6.12/atsgw-mf1) id JAA21752; Tue, 2 May 1995 09:57:46 -0400 Message-Id: <199505021357.JAA21752@thor.ats.qc.ca> From: jaydee@thor.ats.qc.ca (Jean Daigle) Date: Tue, 2 May 1995 09:57:46 -0400 In-Reply-To: deepa@tcsernet.tcs.ernet.in "Perfly bug?" (May 2, 5:39pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: deepa@tcsernet.tcs.ernet.in Subject: Re: Perfly bug? Cc: info-performer@sgi.sgi.com Status: O Hello, On May 2, 5:39pm, deepa@tcsernet.tcs.ernet.in wrote: ... } I noticed a problem with perfly and am wondering if anybody else } has noticed it too. This occurs when one reads in a model of house for example } and moves through it using perfly. After colliding with a wall, if one tries to move at a very small angle to this wall or along it, the wall } starts disappearing and one can see the other side. } But at this stage collision is still working } because though one can see the other side one cannot cross over (atleast most } of the time). } } Does anyone have any idea why this happens? } ... }-- End of excerpt from deepa@tcsernet.tcs.ernet.in It sounds as though your near clipping plane is far enough from the viewpoint that the wall (or other object you are colliding with) is not being drawn. The wall is outside the view volume and is culled from the scene, allowing an unobstructed view of objects and/or terrain on the other side. Since the intersection traversal is separate from the cull traversal of your scene graph, the collision detection works as you expect. This isn't, as far as I can tell, a bug in Performer so much as an unanticipated interaction of some of its features. Perhaps you could try intersecting a set of segments defining the frustum from the eyepoint to the near clipping plane against scene geometry. The man pages for pfHit and pfSegsIsectNode might be helpful. Regards, Jean Daigle. ----------------------------------------------------------------- | Jean Daigle ATS Aerospace Inc. | | Software Designer 1250 Boul Marie-Victorin | | St. Bruno, QC J3V 6B8 | | jaydee@ats.qc.ca Tel: (514) 441-9000 Fax: (514) 441-6789 | ----------------------------------------------------------------- From guest Tue May 2 07:10:55 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA03866; Tue, 2 May 1995 07:09:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA03863; Tue, 2 May 1995 07:09:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11583; Tue, 2 May 95 07:09:05 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id HAA17070; Tue, 2 May 1995 07:09:04 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) id HAA29084; Tue, 2 May 1995 07:09:01 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id PAA07610; Tue, 2 May 1995 15:04:44 +0100 From: "Rob Jenkins" Message-Id: <9505021504.ZM7608@barney.reading.sgi.com> Date: Tue, 2 May 1995 15:04:43 +0100 In-Reply-To: maher@holodeck.gsfc.nasa.gov (Stephen Maher) "Re: Reduction of 3-D geometric complexity" (May 2, 9:25am) References: <199505021325.JAA11819@holodeck.gsfc.nasa.gov> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: maher@holodeck.gsfc.nasa.gov (Stephen Maher) Subject: Re: Reduction of 3-D geometric complexity Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Steve Angus Dorbie's reference to canine anatomy is complimentary to the mesh resolution algorithm he mentioned. Translated, Angus is saying that he thought the alogithm was 'really rather good'. If you haven't worked it out Angus is refering to the parts of the body that only a dog can reach and even the most supple human can't. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Tue May 2 07:54:38 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA04049; Tue, 2 May 1995 07:52:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA04046; Tue, 2 May 1995 07:51:59 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12831; Tue, 2 May 95 07:51:58 -0700 Received: from disperse.demon.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA22459; Tue, 2 May 1995 07:51:54 -0700 Received: from post.demon.co.uk by disperse.demon.co.uk id aa05366; 2 May 95 15:50 GMT-60:00 Received: from division.demon.co.uk by post.demon.co.uk id aa00247; 2 May 95 15:50 GMT-60:00 Received: from caliban.division.demon.co.uk by division.demon.co.uk (AIX 3.2/UCB 5.64/4.03) id AA15206; Tue, 2 May 1995 15:15:29 +0100 Received: by caliban (931110.SGI/921111.SGI) for info-performer@sgi.com id AA12730; Tue, 2 May 95 15:15:28 +0100 From: Angus Dorbie Message-Id: <9505021515.ZM12728@caliban> Date: Tue, 2 May 1995 15:15:27 +0100 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: yu@asd1.jsc.nasa.gov Subject: P.S. Reduction of 3-D geometric complexity Status: O Cc: info-performer@sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 I made a spelling mistake in that washington URL address, http://www.cs.washington.edu:80/homes/derose/grail/ also materials.html isn't there so my info is out of date. You'd probably be able to find this stuff if you surf around the washington site. I have a copy of the source code and could try to upload it to the sgi site if there is sufficient interest. Here's the README file which came with the information. _____________________________________________________________ /* * Copyright (c) 1992, 1993, 1994, Hugues Hoppe, University of Washington. * Copying, use, and development for non-commercial purposes permitted. * All rights for commercial use reserved. */ Herein is source code for the algorithms described in: H. Hoppe, T. DeRose, T. DuChamp, J. McDonald, and W. Stuetzle. Surface reconstruction from unorganized points. Proceedings of SIGGRAPH '92 (Chicago, Illinois, July 26--31, 1992). In {\em Computer Graphics} 26(2) (July 1992), 71--78. H. Hoppe, T. DeRose, T. DuChamp, J. McDonald, and W. Stuetzle. Mesh optimization. Proceedings of SIGGRAPH '93 (Annaheim, California, August 1--6, 1993). In {\em Computer Graphics} Proceedings, Annual Conference Series, 1993, 19--26. H. Hoppe, T. DeRose, T. DuChamp, M. Halstead, H. Jin, J. McDonald, J. Schweitzer, and W. Stuetzle. Piecewise smooth surface reconstruction. Proceedings of SIGGRAPH '94 (Orlando, Florida, July 24--29, 1994). In {\em Computer Graphics} Proceedings, Annual Conference Series, 1994. Hugues Hoppe. Surface reconstruction from unorganized points. PhD thesis, Department of Computer Science and Engineering, University of Washington, in preparation, 1994. The source code is written in C++; it is contained in ./src Since it makes advance use of templates, it requires a C++ compiler version 3.0 or better (in Stroustrup's classification). The code compiled successfully under both: - DEC's cxx compiler (on both mips/Ultrix and alpha/Ultrix) what `which cxx`: cxxdrv.c 1.12 DEC C++ Compiler 2/9/93 - GNU g++ versions 2.4.5 and 2.5.8 (on both mips/Ultrix and sgi/Irix) Note: the code does not successfully compile on many current AT&T based compilers, such as SGI's C++ compiler because of inlining restrictions. To compile: 1) Edit the src/C/h++ file to set options for your C++ compiler if it is not g++. 2) Then, run make. The siggraph '92 module is called 'Recon'. The siggraph '93 module is called 'Meshfit'. The siggraph '94 module is called 'Subdivfit'. Two other programs, 'Filtermesh' and 'Filtera3d' let you manipulate meshes and streams of geometric primitives, respectively. The program 'Polyfit' is a specialization of mesh optimization (Meshfit) to curve fitting in 2D. See the directory ./examples for some test data and expected results. Refer to the files Reconstruct and Simplify for a brief description of parameters, and some sample uses. -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.demon.co.uk UK From guest Tue May 2 07:22:36 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA03914; Tue, 2 May 1995 07:16:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA03911; Tue, 2 May 1995 07:16:09 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11773; Tue, 2 May 95 07:16:00 -0700 Received: from esiris3.vss.fsi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA17788; Tue, 2 May 1995 07:15:58 -0700 Received: by esiris3.vss.fsi.com id AA01658 (5.67a/IDA-1.5 for info-performer@sgi.com); Tue, 2 May 1995 09:17:58 -0500 Date: Tue, 2 May 1995 09:17:58 -0500 From: Milton Fulghum Message-Id: <199505021417.AA01658@esiris3.vss.fsi.com> To: Angus Dorbie Subject: Re: Reduction of 3-D geometric complexity Cc: info-performer@sgi.sgi.com Reply-To: fulghum@vss.fsi.com References: <01HPZVV5A1USQO7JR6@ASD2.JSC.NASA.GOV> Status: O Angus Dorbie wrote: >Date: Tue, 2 May 1995 10:54:44 +0100 >Subject: Re: Reduction of 3-D geometric complexity > >There's a load of C++ source code for the 1993 SigGraph paper >"Mesh Optimisation" by Hughes Hopp, Tony DeRose, Tom Duchamp, >John MacDonald and Werner Stuetzle @ University of Washington. >The meshing code is also closely related to a couple of >SigGraph reconstruction papers. > >I have it on good authority that this algorithm is the >dogs bollocks. > >http://www.cs.washimgton.edu:80/homes/derose/grail/materials.html > >This page points to the files you may be interested in. > Well, it seems that the above page no longer exists. However, perhaps the material at the following page is the same. http://www.cs.washington.edu/homes/derose/grail/treasure_bags.html Well, at least this one leads to something. :-) ----------------------------------------------------------------------------- Milton L. Fulghum PHONE: (314) 551-8576 FlightSafety International, Inc. FAX: (314) 551-8444 5695 Campus Parkway E-Mail: fulghum@vss.fsi.com Saint Louis, Missouri, USA 63042-2338 From guest Tue May 2 08:16:09 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA04090; Tue, 2 May 1995 08:12:29 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA04087; Tue, 2 May 1995 08:12:28 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13425; Tue, 2 May 95 08:12:27 -0700 Received: from falcon by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA25156; Tue, 2 May 1995 08:12:25 -0700 Received: by falcon (4.1/SMI-4.1) id AA02711; Tue, 2 May 95 11:13:25 EDT Date: Tue, 2 May 95 11:13:25 EDT From: arch@falcon.fp.trw.com (Hillel Steinberg) Message-Id: <9505021513.AA02711@falcon> To: info-performer@sgi.sgi.com Subject: Subscribe Status: O subscribe From guest Tue May 2 11:31:45 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA04614; Tue, 2 May 1995 11:27:55 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA04611; Tue, 2 May 1995 11:27:54 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23532; Tue, 2 May 95 11:27:53 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id LAA06854; Tue, 2 May 1995 11:27:49 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id LAA10702; Tue, 2 May 1995 11:27:47 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:deepa@tcsernet.tcs.ernet.in id AA23513; Tue, 2 May 95 11:27:44 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA17155; Tue, 2 May 1995 11:27:43 -0700 Message-Id: <199505021827.LAA17155@surreal.asd.sgi.com> To: deepa@tcsernet.tcs.ernet.in Cc: info-performer@sgi.sgi.com, javier@surreal, nacho@comarts.es Subject: Re: Mapping terrain texture over a DEM In-Reply-To: Your message of "Tue, 02 May 95 17:48:39 EDT." <9505021748.AA04087@tcsernet.tcs.ernet.in> Date: Tue, 02 May 95 11:27:43 -0700 From: Jim Helman Status: O At ITEC, Computer Arts and Developments demonstrated a solid 60Hz fly over of the San Francisco Bay Area using both 1m and 10m image data. On RealityEngine texture paging is a bit tricky, because subtexload only works for non-mipmapped textures. Hence, one must use bilinear and handle texture LOD yourself. CAD did this beautifully paging in textures every frame and blending them very smoothly. Using this approach, tile boundaries between images of the same LOD can be made pretty seamless by ensuring that your own texture LOD generation appropriately includes samples from adjacent tiles. Tile boundaries between images of differing LODs will still show seams, but this will not be as noticeable and can be mitigated using blending. Javier Castellar (javier@asd.sgi.com) or Nacho Sanchez (nacho@comarts.es) might be able to provide more details. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue May 2 05:08:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA03595; Tue, 2 May 1995 05:06:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA03592; Tue, 2 May 1995 05:06:26 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09102; Tue, 2 May 95 05:06:25 -0700 Received: from tcsernet.tcs.ernet.in by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA06368; Tue, 2 May 1995 05:06:21 -0700 From: deepa@tcsernet.tcs.ernet.in Message-Id: <9505021739.AA03986@tcsernet.tcs.ernet.in> Subject: Perfly bug? To: info-performer@sgi.sgi.com Date: Tue, 2 May 95 17:39:08 EDT Content-Length: 605 Content-Type: text X-Mailer: ELM [version 2.3 PL2] Status: O I noticed a problem with perfly and am wondering if anybody else has noticed it too. This occurs when one reads in a model of house for example and moves through it using perfly. After colliding with a wall, if one tries to move at a very small angle to this wall or along it, the wall starts disappearing and one can see the other side. But at this stage collision is still working because though one can see the other side one cannot cross over (atleast most of the time). Does anyone have any idea why this happens? Deepa Krishnan Tata Consultancy Services e-mail: deepa@tcsernet.tcs.ernet.in From guest Tue May 2 05:18:20 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA03613; Tue, 2 May 1995 05:16:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA03610; Tue, 2 May 1995 05:16:09 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09263; Tue, 2 May 95 05:16:08 -0700 Received: from tcsernet.tcs.ernet.in by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA07034; Tue, 2 May 1995 05:15:57 -0700 From: deepa@tcsernet.tcs.ernet.in Message-Id: <9505021748.AA04087@tcsernet.tcs.ernet.in> Subject: Mapping terrain texture over a DEM To: info-performer@sgi.sgi.com Date: Tue, 2 May 95 17:48:39 EDT Content-Length: 566 Content-Type: text X-Mailer: ELM [version 2.3 PL2] Status: O I have a large DEM (of an entire country say) and I also have a very large SPOT image to be texture mapped over it. I need to fly over this using Performer. I don't want to load all this data right at the beginning but want to load part by part and visualize it as I fly-through. Is there any way to do this efficiently? How can I tile and texture map this image without the discontinuity at the edge becoming conspicuos? Can ImageVision be used along with Performer to achieve this? Deepa Krishnan Tata Consultancy Services e-mail:deepa@tcsernet.tcs.ernet.in From guest Tue May 2 08:35:31 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA04157; Tue, 2 May 1995 08:28:55 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA04154; Tue, 2 May 1995 08:28:55 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13946; Tue, 2 May 95 08:28:53 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA28647; Tue, 2 May 1995 08:28:53 -0700 From: performer@relay.milan.sgi.com Received: from relay.milan.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id IAA07077; Tue, 2 May 1995 08:28:49 -0700 Received: from relay by relay.milan.sgi.com via UUCP (940816.SGI.8.6.9/911001.SGI) for sgimil!sgi.sgi.com!info-performer id RAA03280; Tue, 2 May 1995 17:28:43 +0200 Received: by relay.rome.sgi.com (940816.SGI.8.6.9/920502.SGI) id PAA29631; Tue, 2 May 1995 15:59:05 +0200 Message-Id: <9505021559.ZM29629@relay.rome.sgi.com> Date: Tue, 2 May 1995 15:59:04 -0600 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: add baini@univ.it to performer mailing list Cc: annibale@relay.milan.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Please can someone of you add the address baini@univ.it to performer mailing list ? Thanks in advance Annibale annibale@rome.sgi.com From guest Tue May 2 05:40:58 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA03688; Tue, 2 May 1995 05:39:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA03685; Tue, 2 May 1995 05:38:59 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09617; Tue, 2 May 95 05:38:58 -0700 Received: from tcsernet.tcs.ernet.in by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA08625; Tue, 2 May 1995 05:38:54 -0700 From: deepa@tcsernet.tcs.ernet.in Message-Id: <9505021811.AA04659@tcsernet.tcs.ernet.in> Subject: Multigen models To: info-performer@sgi.sgi.com Date: Tue, 2 May 95 18:11:41 EDT Content-Length: 162 Content-Type: text X-Mailer: ELM [version 2.3 PL2] Status: O Is there any public domain site where I can get access to MultiGen (.flt) models? Deepa Krishnan Tata Consultancy Services e-mail: deepa@tcsernet.tcs.ernet.in From guest Tue May 2 18:16:49 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA05855; Tue, 2 May 1995 18:07:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA05852; Tue, 2 May 1995 18:07:02 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04780; Tue, 2 May 95 18:06:50 -0700 Received: from taurus.cs.nps.navy.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id SAA24193; Tue, 2 May 1995 18:06:58 -0700 Received: from cool.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA01448; Tue, 2 May 95 18:07:00 PDT Received: by cool.cs.nps.navy.mil (950215.SGI.8.6.10/940406.SGI) for info-performer@sgi.com id SAA27727; Tue, 2 May 1995 18:07:00 -0700 From: mcmillan@cool.cs.nps.navy.mil (Scott McMillan) Message-Id: <199505030107.SAA27727@cool.cs.nps.navy.mil> Subject: Performer intersection problem (maybe?) To: info-performer@sgi.sgi.com Date: Tue, 2 May 1995 18:06:59 -0700 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2004 Status: O I have been trying to track down a nasty bug in my performer application, and I need help. My program simulates a bunch of robots that have sensors implemented with intersection segments to allow the robots to "see" obstacles like rocks and bushes (flt models) in their path. Every once in a while the program will almost hang: the rendering updates drop from about 10 updates per second to around 1 update per 10 seconds because the application load goes sky high. So far I have been able to determine that one of the manifestations of the problem is the PFQHIT_POINT information and the position information of the PFQHIT_XFORM matrix is coming back with NAN's. Actually the intersection information for all of the robots is corrupted after this happens. I have pfNotifyLevel(PFNFY_DEBUG) set but there are no messages and I do check the PFQHIT_POINT and PFQHIT_XFORM flags to make sure the info is valid as follows: if (pfSegsIsectNode(G_shared->scene, &segment, hits)) { long flags; pfQueryHit(*hits[0], PFQHIT_FLAGS, &flags); // Make sure point is valid. if (flags&PFHIT_POINT) { pfVec3 pnt; pfQueryHit(*hits[0], PFQHIT_POINT, &pnt); // if the object is attached via some DCS -- must get Xform // matrix: if (flags & PFHIT_XFORM) { pfMatrix xform; pfQueryHit(*hits[0], PFQHIT_XFORM, &xform); pfXformPt3(pnt, pnt, xform); } return pnt[PF_Z]; } etc... Has anybody else run into this sort of problem? If so, what did you do to solve it? OR Does anybody know of other things in Performer (or elsewhere) that could go wrong that would affect intersection information? Any advice on how to tackle this problem is appreciated. scott -- Scott McMillan, Ph.D. (408) 656-3316 mcmillan@cs.nps.navy.mil Dept. of Computer Science/Naval Postgraduate School/Monterey, CA 93943 NEW URL: http://taurus.cs.nps.navy.mil/people/faculty/mcmillan/ From guest Tue May 2 19:35:45 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA06486; Tue, 2 May 1995 19:32:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA06483; Tue, 2 May 1995 19:32:59 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07728; Tue, 2 May 95 19:32:37 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id TAA05283; Tue, 2 May 1995 19:32:55 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id TAA03867; Tue, 2 May 1995 19:32:54 -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 AA07721; Tue, 2 May 95 19:32:32 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id TAA28870; Tue, 2 May 1995 19:30:34 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199505030230.TAA28870@tubes.asd.sgi.com> Subject: Re: Single-processor, fixing frame rate To: guest (Eric S. Hirschorn) Date: Tue, 2 May 95 19:30:34 PDT Cc: info-performer@sgi.sgi.com, erich@pike.cecer.army.mil In-Reply-To: <199504280425.XAA14993@pike.cecer.army.mil>; from "Eric S. Hirschorn" at Apr 27, 95 11:23 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > We're trying to get a Performer 1.2 application to stop doing a "free > run" on a single processor Crimson (IRIX 5.2), but without success. > The code we're testing is a modified perfly. Our method of testing is > to set up pfSync or pfVClockSync so as to make the simulation run at 1 > Hz, so it should appear to run really slow. > > We've tried using pfSync with pfPhase(PFPHASE_LOCK), > pfPhase(PFPHASE_LIMIT), and setting the pfFrameRate. Also, we have > tried pfVClockSync. > > Do all of the Performer real-time synchronization routines assume a > multiprocessor machine? > > Or should we be falling back on IRIX Real-time features such as > interval timers, signals, and so forth? > > Eric > erich@pike.cecer.army.mil > In 1.2, single process mode did not support fixed frame rate operation but soon-to-be-released 2.0 will. For now you can simply call swapinterval(fields) in your draw callback to limit your frame rate to (video rate / fields) Hz. From guest Tue May 2 19:50:43 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA06556; Tue, 2 May 1995 19:48:24 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA06553; Tue, 2 May 1995 19:48:23 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08204; Tue, 2 May 95 19:48:00 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id TAA07273; Tue, 2 May 1995 19:48:20 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id TAA04917; Tue, 2 May 1995 19:48:19 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:mcmillan@cool.cs.nps.navy.mil id AA08191; Tue, 2 May 95 19:47:55 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id TAA18726; Tue, 2 May 1995 19:48:16 -0700 Message-Id: <199505030248.TAA18726@surreal.asd.sgi.com> To: mcmillan@cool.cs.nps.navy.mil (Scott McMillan) Cc: info-performer@sgi.sgi.com Subject: Re: Performer intersection problem (maybe?) In-Reply-To: Your message of "Tue, 02 May 95 18:06:59 PDT." <199505030107.SAA27727@cool.cs.nps.navy.mil> Date: Tue, 02 May 95 19:48:16 -0700 From: Jim Helman Status: O The dramatic increase in intersection time is probably caused by floating point exceptions during the traversal. What's causing these is another matter. Something is probably either corrupted in the pfSegSet (or part of the traverser) or in the scene graph, such as a bogus DCS matrix or something trashing the cached pfGeoSet triangle caches. Since it takes *so* long, I'd probably guess something in the traverser or segset. If it the frame rate recovers, it could be some problem being caused by a set of FP values you are specifying (singular matrix, etc.) or a memory stomp of something which you're eventually causing to be rewritten. But if it never recovers even when you restore all of the scene graph state and make an identical intersection request, it's probably a memory stomp deep down in something like the triangle caches or some static Performer data such as the identity matrix. The question is who's stomping whom. And that's often a tricky one to answer. We've had no other reports of such things, so first I'd check your code carefully for any possible stray writing. If not, the it's time for debugging. Since the impact is felt inside Performer, the only strategy I know is to keep twiddling things until you can easily reproduce it and reduce it to a small test case. At that point, we should be able to track the stomper down with a bit of dbxing and searching. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed May 3 07:49:06 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA07816; Wed, 3 May 1995 07:46:40 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA07813; Wed, 3 May 1995 07:46:40 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22327; Wed, 3 May 95 07:45:36 -0700 Received: from satchmo.virtualprototypes.ca by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA28078; Wed, 3 May 1995 07:46:34 -0700 Received: from floyd.virtualprototypes.ca by satchmo.virtualprototypes.ca via SMTP (931110.SGI/911001.satchmo.VirtualPrototypes.CA) for info-performer@holodeck.asd.sgi.com id AA15336; Wed, 3 May 95 10:47:15 -0400 Received: from yes.virtualprototypes.ca by floyd via SMTP (931110.SGI/930416.SGI.AUTO) for @satchmo.virtualprototypes.ca:info-performer@holodeck.asd.sgi.com id AA16280; Wed, 3 May 95 10:47:09 -0400 Received: by yes.VirtualPrototypes.CA (5.x/SMI-SVR4) id AA25222; Wed, 3 May 1995 10:47:05 -0400 Date: Wed, 3 May 1995 10:47:05 -0400 From: svorcsek@floyd.virtualprototypes.ca (Sid Svorcsek) Message-Id: <9505031447.AA25222@yes.VirtualPrototypes.CA> To: info-performer Subject: help Status: O help From guest Wed May 3 08:38:02 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA07904; Wed, 3 May 1995 08:34:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA07901; Wed, 3 May 1995 08:34:33 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23856; Wed, 3 May 95 08:33:27 -0700 Received: from nova.unix.portal.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA04980; Wed, 3 May 1995 08:34:28 -0700 Received: from uucp1.unix.portal.com (uucp1.unix.portal.com [156.151.1.100]) by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id IAA27872 for ; Wed, 3 May 1995 08:33:46 -0700 Received: from cory.UUCP (uucp@localhost) by uucp1.unix.portal.com (8.6.11/8.6.5) with UUCP id IAA03568 for portal!sgi.com!info-performer; Wed, 3 May 1995 08:24:26 -0700 Received: by cory (920330.SGI/911001.SGI) for portal!sgi.com!info-performer id AA08963; Wed, 3 May 95 08:21:47 -0700 Date: Wed, 3 May 95 08:21:47 -0700 From: kowsik@cory.coryphaeus.com (Kowsik Guruswamy) Message-Id: <9505031521.AA08963@cory> To: info-performer@sgi.sgi.com Subject: Intersection process... Status: O I have a question about the intersection process. I am using pfIsectFunc() and pfPassIsectData() to pass intersection data to the ISECT process [and back? - that's the question...]... Well, my understanding of pfPassIsectData() is that it makes a copy of the data allocated and sends it to the isectFunc(). I also noticed that the example in the Performer Reference pages uses a IsectStuff structure that has a collisionResults field. If the isectFunc gets a copy of the isectdata, when and how is it passed back to the APP process [ if at all it's done? ]. Any modifications will be done to its local copy... I know I can work around this by directly accessing the pointer returned by pfAllocIsectData(), in which case I don't need pfPassIsectData() at all. I have tried this and it works. How do I do it *WITHOUT* bypassing pfPassIsectData()? Thanks for any insights, K. From guest Wed May 3 08:39:10 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA07909; Wed, 3 May 1995 08:35:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA07906; Wed, 3 May 1995 08:35:00 -0700 Received: from death.reading.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23892; Wed, 3 May 95 08:33:53 -0700 Received: by death.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id QAA22211; Wed, 3 May 1995 16:30:52 +0100 From: "Angus Henderson" Message-Id: <9505031630.ZM22209@death.reading.sgi.com> Date: Wed, 3 May 1995 16:30:51 +0100 In-Reply-To: svorcsek@floyd.virtualprototypes.ca (Sid Svorcsek) "help" (May 3, 10:47am) References: <9505031447.AA25222@yes.VirtualPrototypes.CA> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: svorcsek@floyd.virtualprototypes.ca (Sid Svorcsek), info-performer Subject: Re: help Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O somebody help VPI port their software to RGBMode From guest Wed May 3 10:31:09 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA08159; Wed, 3 May 1995 10:24:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA08156; Wed, 3 May 1995 10:24:21 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29063; Wed, 3 May 95 10:23:05 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA24062; Wed, 3 May 1995 10:24:17 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) for id KAA11089; Wed, 3 May 1995 10:24:16 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgi.sgi.com id AA29052; Wed, 3 May 95 10:22:59 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA00654; Wed, 3 May 1995 10:21:56 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199505031721.KAA00654@tubes.asd.sgi.com> Subject: Re: Intersection process... To: guest (Kowsik Guruswamy) Date: Wed, 3 May 95 10:21:56 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9505031521.AA08963@cory>; from "Kowsik Guruswamy" at May 3, 95 8:21 am X-Mailer: ELM [version 2.3 PL8] Status: O > > I have a question about the intersection process. I am using > pfIsectFunc() and pfPassIsectData() to pass intersection data to the ISECT > process [and back? - that's the question...]... > > Well, my understanding of pfPassIsectData() is that it makes a copy of the > data allocated and sends it to the isectFunc(). I also noticed that the example > in the Performer Reference pages uses a IsectStuff structure that has a > collisionResults field. > > If the isectFunc gets a copy of the isectdata, when and how is it passed > back to the APP process [ if at all it's done? ]. Any modifications will be > done to its local copy... > > I know I can work around this by directly accessing the pointer returned by > pfAllocIsectData(), in which case I don't need pfPassIsectData() at all. I > have tried this and it works. > > How do I do it *WITHOUT* bypassing pfPassIsectData()? > > Thanks for any insights, There is currently no mechanism for propagating info "upstream" from either the ISECT or CULL/DRAW back to the APP. The man page does imply otherwise so I'll change it. The pfPass* API provides frame-accurate data propagation downsream only. Upstream data migration is a bit nastier and we haven't tackled it yet. A reasonable solution for the ISECT is to use a chunk of shared memory which the ISECT writes and the APP reads. You can use locks and framestamps to ensure data exclusion and frame-accurate behavior. From guest Wed May 3 12:05:44 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA08273; Wed, 3 May 1995 11:48:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA08270; Wed, 3 May 1995 11:48:08 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03629; Wed, 3 May 95 11:46:32 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id LAA11772; Wed, 3 May 1995 11:47:49 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id LAA28512; Wed, 3 May 1995 11:47:46 -0700 Received: from mauritius.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:YU_STELLA@ASDA1.JSC.NASA.GOV id AA03609; Wed, 3 May 95 11:46:18 -0700 Received: from localhost by mauritius.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA02673; Wed, 3 May 1995 11:47:40 -0700 Message-Id: <199505031847.LAA02673@mauritius.asd.sgi.com> To: "Stella M. Yu 333 - 6799/483 - 1690" Cc: info-performer@sgi.sgi.com Subject: Re: Reduction of 3-D geometric complexity In-Reply-To: Your message of "Mon, 01 May 95 21:52:00 CDT." <01HPZVV5A1USQO7JR6@ASD2.JSC.NASA.GOV> Date: Wed, 03 May 95 11:47:40 -0700 From: "H. B. Siegel" Status: O There is a program from Wavefront, available as part of the "GameWare" or "Advanced Visualizer" bundles called "Model" that has the capability to read in polygonal models in OBJ format and interactively reduce the polygon counts to either a fixed number of polygons or a fixed resolution. Alias also has a polygon reduction tool built into their modelling system. If you want to roll your own there are a couple of good SIGGRAPH papers ('93? '94?) that have some interesting algorithms. Note that there is no one "good" solution for all kinds of models. From guest Wed May 3 14:14:27 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA08664; Wed, 3 May 1995 14:04:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA08661; Wed, 3 May 1995 14:04:18 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02278; Wed, 3 May 95 14:04:13 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id OAA11197; Wed, 3 May 1995 14:04:09 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id OAA05684; Wed, 3 May 1995 14:04:08 -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 AA02257; Wed, 3 May 95 14:03:59 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA01554; Wed, 3 May 1995 14:01:40 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199505032101.OAA01554@tubes.asd.sgi.com> Subject: Re: how does pfGetTravNode() work? To: guest (Fred Clyne) Date: Wed, 3 May 95 14:01:40 PDT Cc: info-performer@sgi.sgi.com, fred@octave.cambridge.com In-Reply-To: <199502222320.XAA02875@octave.cambridge.com>; from "Fred Clyne" at Feb 22, 95 11:20 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > I am looking for an explanation as to why this does not work. > I created a preCull and postCull callback routine and assigned > them to all my nodes (in a test program). Their function is > to echo the node's name during the preCull and to print the cull > result on postCull. The pre works fine. The post does not seem > to understand the node it is in. It always prints the the last > node in the tree. Is the node returned by pfGetTravNode() not > valid during a post cull process? This is indeed a bug in the traversal logic. As a workaround, you could maintain a stack of node pointers in the cull callbacks, i.e. - push in the pre and pop in the post. Sorry. From guest Wed May 3 14:46:16 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA08809; Wed, 3 May 1995 14:33:28 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA08806; Wed, 3 May 1995 14:33:28 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03772; Wed, 3 May 95 14:33:21 -0700 Received: from taurus.cs.nps.navy.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA17678; Wed, 3 May 1995 14:33:08 -0700 Received: from aquarius.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA06397; Wed, 3 May 95 14:32:52 PDT Date: Wed, 3 May 1995 14:32:51 -0700 (PDT) From: Michael Macedonia To: Jim Helman Cc: Scott McMillan , info-performer@sgi.sgi.com Subject: Re: Performer intersection problem (maybe?) In-Reply-To: <199505030248.TAA18726@surreal.asd.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Jim, I talked this over with Scott. Since the slow down is in the app could the problem be in the Performer trig functions (tables) feeding bad data, e.g. wrapping around 360? Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From guest Wed May 3 17:59:54 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA09980; Wed, 3 May 1995 17:36:43 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA09977; Wed, 3 May 1995 17:36:38 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14561; Wed, 3 May 95 17:36:45 -0700 Received: from sgigate.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id RAA00158; Wed, 3 May 1995 17:36:36 -0700 Received: from tacom-emh1.army.mil by sgigate.sgi.com via ESMTP (950221.405.SGI.8.6.10/911001.SGI) for id RAA14776; Wed, 3 May 1995 17:36:35 -0700 From: tidrowd@cc.tacom.army.mil Received: from cc-gw.tacom.army.mil by tacom-emh1.army.mil (8.6.11/8.6.11-kbp) with SMTP id UAA19387; Wed, 3 May 1995 20:36:33 -0400 Received: from ccMail by cc-gw.tacom.army.mil (IMA Internet Exchange 1.04b beta) id fa820b80; Wed, 3 May 95 20:32:56 -0400 Mime-Version: 1.0 Date: Wed, 3 May 1995 18:16:16 -0400 Message-Id: Subject: More questions on intersections To: info-performer@sgihub.corp.sgi.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Status: O Since this week's topic seems to be intersections, here's my question - pfQueryHit is segfaulting in the following discriminator callback: long projDiscFunc( pfHit* hit ) { static pfGeoSet* gset; ... pfQueryHit( hit, PFQHIT_GSET, gset ); ... } The thing I don't understand is why pfMQueryHit works (and apparently not pfQueryHit). The following code works fine: long HitQuery[] { PFQHIT_FLAGS, PFQHIT_GSET, PFQHIT_NODE }; struct HitData { long flags; pfGeoSet* gset; pfNode* node; }; long projDiscFunc( pfHit* hit ) { static HitData hit_data; ... pfMQueryHit( hit, HitQuery, &hit_data ); ... } Is there something obvious I'm missing, or is this a known bug??? In addition, how do you determine how many intersections occurred along a single segment (assuming that the disc. callback turns off segment clipping)? Any enlightenment would be greatly appreciated! Don Tidrow Visual Simulation Developer US Army Tank-automotive and Armaments Command (imagine pithy saying here) From guest Wed May 3 22:45:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA14950; Wed, 3 May 1995 22:12:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA14947; Wed, 3 May 1995 22:12:26 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23434; Wed, 3 May 95 22:12:41 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id WAA02813; Wed, 3 May 1995 22:12:23 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id WAA24562; Wed, 3 May 1995 22:12:22 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:macedoni@cs.nps.navy.mil id AA23414; Wed, 3 May 95 22:12:17 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA14812; Wed, 3 May 1995 22:11:53 -0700 Message-Id: <199505040511.WAA14812@surreal.asd.sgi.com> To: Michael Macedonia Cc: Scott McMillan , info-performer@sgi.sgi.com Subject: Re: Performer intersection problem (maybe?) In-Reply-To: Your message of "Wed, 03 May 95 14:32:51 PDT." Date: Wed, 03 May 95 22:11:52 -0700 From: Jim Helman Status: O > I talked this over with Scott. Since the slow down is in > the app could the problem be in the Performer trig > functions (tables) feeding bad data, e.g. wrapping around > 360? I'm not aware of pfSinCos generating bad data from valid FP input. Unlike pfSqrt which does use a table, pfSinCos has no table to fall of the end of. It is true that applications should wrap angles which continuously increase or decrease simply because of the FP precision issues, i.e. 10 degrees out of 1.0e6. But large values should cause quantization, i.e. jerkiness, not bogus FP results. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed May 3 22:53:50 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA14994; Wed, 3 May 1995 22:19:46 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA14990; Wed, 3 May 1995 22:19:42 -0700 Received: from sgihub.corp.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23593; Wed, 3 May 95 22:19:59 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id WAA26120; Wed, 3 May 1995 22:19:37 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:tidrowd@cc.tacom.army.mil id AA23577; Wed, 3 May 95 22:19:45 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA14832; Wed, 3 May 1995 22:19:15 -0700 Message-Id: <199505040519.WAA14832@surreal.asd.sgi.com> To: tidrowd@cc.tacom.army.mil Cc: info-performer@sgihub.corp.sgi.com Subject: Re: More questions on intersections In-Reply-To: Your message of "Wed, 03 May 95 18:16:16 EDT." Date: Wed, 03 May 95 22:19:03 -0700 From: Jim Helman Status: O > pfQueryHit is segfaulting in the following discriminator callback: > > static pfGeoSet* gset; > pfQueryHit( hit, PFQHIT_GSET, gset ); This should read: pfQueryHit( hit, PFQHIT_GSET, &gset ); > In addition, how do you determine how many intersections occurred > along a single segment (assuming that the disc. callback turns off > segment clipping)? You'll need to keep a count of how many times the discriminator was invoked for that segment. In the future, there will be an option to have pfSegsIsectNode(pfNode *node, pfSegSet *segSet, pfHit **hits[]); return all hits along each segment. Hence the 2D hit array, hits[iseg][jhit], in the API, although currently only jhit=0 is useful. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu May 4 01:36:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA15504; Thu, 4 May 1995 01:14:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA15501; Thu, 4 May 1995 01:14:19 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26661; Thu, 4 May 95 01:14:41 -0700 Received: from redgate.vislab.su.edu.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA14936; Thu, 4 May 1995 01:13:58 -0700 Received: by redgate.vislab.su.edu.au (950215.SGI.8.6.10/940406.SGI) for info-performer@sgi.com id SAA10719; Thu, 4 May 1995 18:13:51 +1000 Date: Thu, 4 May 1995 18:13:51 +1000 From: ben@vislab.su.edu.au (Ben Simons) Message-Id: <199505040813.SAA10719@redgate.vislab.su.edu.au> To: info-performer@sgi.sgi.com Subject: NewpfuWidget: failed Status: O Has anyone got this one before?? Performer Warning: No VClock. Assuming 60Hz video rate Performer Fatal: NewpfuWidget: failed to allocate widget 36 of type 0x11 in gui data pool. Seems to have happened since I added another button, but I can't debug it as I think it's inside a library. ben. _______________________________________________________ Ben Simons Physics Building, A28, VisLab Systems Manager Sydney University. NSW. Phone +61-2-351-3005 AUSTRALIA. 2006. From guest Thu May 4 02:17:01 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA15990; Thu, 4 May 1995 02:13:55 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA15987; Thu, 4 May 1995 02:13:55 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27720; Thu, 4 May 95 02:14:18 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id CAA18565; Thu, 4 May 1995 02:13:53 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id CAA13096; Thu, 4 May 1995 02:13:51 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:ben@vislab.su.edu.au id AA27711; Thu, 4 May 95 02:14:15 -0700 Received: by rose.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id CAA09920; Thu, 4 May 1995 02:13:49 -0700 From: "Sharon Clay (Fischler)" Message-Id: <9505040213.ZM9918@rose.asd.sgi.com> Date: Thu, 4 May 1995 02:13:49 -0700 In-Reply-To: ben@vislab.su.edu.au (Ben Simons) "NewpfuWidget: failed" (May 4, 6:13pm) References: <199505040813.SAA10719@redgate.vislab.su.edu.au> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: ben@vislab.su.edu.au (Ben Simons), info-performer@sgi.sgi.com Subject: Re: NewpfuWidget: failed Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On May 4, 6:13pm, Ben Simons wrote: > Subject: NewpfuWidget: failed -> ->Has anyone got this one before?? -> ->Performer Warning: No VClock. Assuming 60Hz video rate ->Performer Fatal: NewpfuWidget: failed to allocate widget 36 of type 0x11 in gui data pool. Hmmm. For some reason pfDPoolAlloc of the GUI data pool failed. -> ->Seems to have happened since I added another button, ->but I can't debug it as I think it's inside a library. FYI: the source code to the GUI in libpfutil is at /usr/src/Performer/src/lib/libpfutil/gui.c src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Graphics Dev. src@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Thu May 4 02:05:16 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA15885; Thu, 4 May 1995 02:02:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA15882; Thu, 4 May 1995 02:02:26 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27433; Thu, 4 May 95 02:02:49 -0700 Received: from zaphod.axion.bt.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA17907; Thu, 4 May 1995 02:02:23 -0700 Received: from roundabout.bt-sys.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Thu, 4 May 1995 09:57:15 +0100 Received: from argon.bt-sys.bt.co.uk by roundabout.bt-sys.bt.co.uk (8.6.9/BT-SYS-8.6.9) id JAA04435; Thu, 4 May 1995 09:57:10 +0100 Received: from platinum.bt-sys.bt.co.uk by argon.bt-sys.bt.co.uk (4.1/SMI-4.1) id AA26679; Thu, 4 May 95 10:00:32 BST Received: by platinum.bt-sys.bt.co.uk (5.0/SMI-SVR4) id AA17249; Thu, 4 May 1995 10:00:29 +0000 Date: Thu, 4 May 1995 10:00:29 +0000 From: dburrast@bt-sys.bt.co.uk (Dave Burraston) Message-Id: <9505040900.AA17249@platinum.bt-sys.bt.co.uk> To: info-performer@sgi.sgi.com Subject: unsubscribe X-Sun-Charset: US-ASCII Content-Length: 12 Status: O unsubscribe From guest Thu May 4 04:34:05 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id EAA16589; Thu, 4 May 1995 04:31:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id EAA16586; Thu, 4 May 1995 04:31:33 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29781; Thu, 4 May 95 04:32:01 -0700 Received: from dw3f.ess.harris.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id EAA24878; Thu, 4 May 1995 04:31:30 -0700 From: jnemethy@dw3f.ess.harris.com Received: from dw3x.ess.harris.com (dw3x [130.41.10.25]) by dw3f.ess.harris.com (8.6.9/mdb(941103)) with SMTP id HAA05070; Thu, 4 May 1995 07:32:28 -0400 Received: by dw3x.ess.harris.com (5.57/Ultrix3.0-C) id AA10563; Thu, 4 May 95 07:33:18 -0400 Message-Id: <9505041133.AA10563@dw3x.ess.harris.com> To: info-performer@sgi.sgi.com Cc: jnemethy@harris.com Subject: Picking objects on terrain Date: Thu, 04 May 95 07:33:17 -0400 X-Mts: smtp Status: O Hello, I'm trying to pick objects which I have placed on a terrain. I am using pfNodePickSetup with FPTRAV_IS_PRIM and PFPK_IS_NEAREST, pfuCalcNormalizedChanXY, pfChanPick and pfQueryHit, similar to the pickfly application. However, the pick is only successful when I am looking down on the object as in a God's eye view. Any help or suggestions would be greatly appreciated. Thanks, Joe Nemethy Harris Corporation, ISD (407)984 From guest Thu May 4 06:50:11 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA16716; Thu, 4 May 1995 06:48:13 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA16713; Thu, 4 May 1995 06:48:12 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02113; Thu, 4 May 95 06:48:44 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id GAA04435; Thu, 4 May 1995 06:48:09 -0700 Received: from tobias.neu.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) id GAA27475; Thu, 4 May 1995 06:47:58 -0700 Received: by tobias.neu.sgi.com (940816.SGI.8.6.9/930416.SGI) id EAA03360; Thu, 4 May 1995 04:37:06 -0700 From: "Richard Mercille" Message-Id: <9505040437.ZM3358@tobias.neu.sgi.com> Date: Thu, 4 May 1995 04:37:06 -0700 In-Reply-To: Milana Huang "Triple Keyboard Option" (Apr 17, 6:10am) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Milana Huang , info-performer@sgi.sgi.com Subject: Re: Triple Keyboard Option Cc: David Pape , lindahl@evl.eecs.uic.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I think in your call to pfInitPipe() you are using something like : pfInitPipe(NULL, OpenPipeline); try p = pfGetPipe(0); pfInitPipe(p, OpenPipeline); On Apr 17, 6:10am, Milana Huang wrote: > Subject: Triple Keyboard Option > Hello Performer People, > > My setup: > Performer 1.2 with Irix 5.3 on an Onyx with 8 processors, > 3 Reality Engines and Triple Keyboard Option installed > (supports 3 monitor/keyboard pairs for the 1 Onyx). > > My problem: > I would like my Performer program to open 3 windows, 1 on each > display/monitor. With Triple Keyboard Option I can no longer use > scrnselect() to do that. Each pipe is now a separate display - > :0, :1, :2 (each with only ONE screen). > > My attempted fix: > Use putenv(). > My routine I send to pfInitPipe() looks essentially like this: > void OpenPipeline(pfPipe * p) > { putenv(StaticEnvVariable); > /*StaticEnvVariable set to DISPLAY=:num where num is 0,1, or 2 */ > sleep(5); > prefposition(0, XMAX_96HZ, 0,YMAX_96HZ); > noborder(); > foreground(); > winopen(""); > stereobuffer(); > doublebuffer(); > gconfig(); > pfInitGfx(p); > } > But doesn't do the trick. All the windows pile up on the same monitor. > > Please let me know a work around or if this is not possible with > Triple Keyboard Option installed. > > Thank you very much, > Milana > ___________________________________________________________________________ > Milana Huang Electronic Visualization Lab > mhuang@eecs.uic.edu University of Illinois at Chicago (M/C 154) > (312) 996-3002 851 S. Morgan, room 1120 SEO > (312) 413-7585 FAX Chicago, IL 60607-7053 > > >-- End of excerpt from Milana Huang -- Richard Mercille Core Technology Group European Graphics Lab Silicon Graphics Email rim@neu.sgi.com Chemin des Rochettes 2 VMail 5-8408 2016 Cortaillod/Switzerland Phone +41.38.43.35.29 Fax +41.38.43.39.05 From guest Fri May 5 07:26:46 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA19497; Fri, 5 May 1995 07:14:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA19494; Fri, 5 May 1995 07:14:03 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22342; Fri, 5 May 95 07:14:02 -0700 Received: from pigeon.cf.ac.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA11694; Fri, 5 May 1995 07:11:34 -0700 Received: from thor.cf.ac.uk by pigeon.cf.ac.uk with SMTP (PP) id <09503-0@pigeon.cf.ac.uk>; Fri, 5 May 1995 15:08:05 +0100 Pp-Warning: Illegal Received field on preceding line Pp-Warning: Illegal Via field on preceding line Date: Fri, 5 May 1995 14:55:03 +0100 (BST) From: ROY RUDDLE Reply-To: Ruddle@cardiff.ac.uk To: info-performer@sgi.sgi.com Subject: pfMakePerspFrust error? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Ref. p153 in the 1.2 Performer Reference manual. I've tried doing this with just one frustrum, but the FOV I get is 45 (horiz) by 43.xxx (vert). Any suggestions anyone? Code is (C++): pfChannel *left = pfNewChan(pfGetPipe(0)); float v_fov = 22.5f; float t = pfTan( v_fov ); pfMakePerspFrust(left, -1.0f, 0.0f, -t, t); pfFrustNearFar(left, 1.0f, 1000.0f); float ffh, ffv; pfGetFrustFOV( left, &ffh, &ffv ); cout << "frust FOV " << ffh << " " << ffv << endl; ------------------------------------------------------------------------ Roy Ruddle, Principal Researcher | School of Psychology Tel: 01222 874523 (direct) | University of Wales College of Cardiff 01222 874007 (messages) | PO Box 901 Fax: 01222 874858 | Cardiff CF1 3YG Email: Ruddle@CARDIFF.AC.UK | UK From guest Thu May 4 20:11:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA18867; Thu, 4 May 1995 19:59:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA18864; Thu, 4 May 1995 19:59:02 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10370; Thu, 4 May 95 19:59:02 -0700 Received: from hntp2.hinet.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA00908; Thu, 4 May 1995 19:58:59 -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 KAA23151 for <@hntp2.hinet.net:info-performer@sgi.com>; Fri, 5 May 1995 10:58:16 +0800 Received: by systech.hinet.net (931110.SGI/930416.SGI) for @hntp2.hinet.net:info-performer@sgi.com id AA07621; Fri, 5 May 95 10:58:16 -0700 Date: Fri, 5 May 95 10:58:16 -0700 From: terence@systech.hinet.net (Terence Ker) Message-Id: <9505051758.AA07621@systech.hinet.net> To: info-performer@sgi.sgi.com Subject: Texture for a ball Status: O Hi, everyone: Is there anybody out there willin to send me a performer program which renders a ball with texture? I learned GL thru Performer study so I really don't know how to properly set up texture coordinates. Are there some guidelines for applying textures on geometry? I have been trying a simple case of applying texture on a flat polygon, it ended up a severely blurred image on polygon or "blocks" of repeated images with clear-cut boundary. I know this is not really a Performer topics, but I am working on Performer, can someone help? thanks -= Terence Ke =- Systems & Technology Taipei, Taiwan e-mail: terence@systech.hinet.net From guest Fri May 5 13:05:27 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA20116; Fri, 5 May 1995 12:51:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA20113; Fri, 5 May 1995 12:51:32 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06351; Fri, 5 May 95 12:51:24 -0700 Received: from taurus.cs.nps.navy.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA04931; Fri, 5 May 1995 12:51:21 -0700 Received: from cool.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA24222; Fri, 5 May 95 12:51:13 PDT Received: by cool.cs.nps.navy.mil (950215.SGI.8.6.10/940406.SGI) id MAA00807; Fri, 5 May 1995 12:51:11 -0700 From: mcmillan@cool.cs.nps.navy.mil (Scott McMillan) Message-Id: <199505051951.MAA00807@cool.cs.nps.navy.mil> Subject: Re: Performer intersection problem (maybe?) To: jimh@surreal (Jim Helman) Date: Fri, 5 May 1995 12:51:10 -0700 (PDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <199505030248.TAA18726@surreal.asd.sgi.com> from "Jim Helman" at May 2, 95 07:48:16 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 955 Status: O Well...it took a while to track down my problem. I was, indeed, stuffing NAN's into a pfSegSet segment.segs[].pos[] vector. Two things I would like explained for my own info: 1) I was running with pfNotifyLevel(PFNFY_FATAL) but performer never complained. Is this because it will only output messages if Performer generates NANs, but will do nothing if it starts with bad info in the first place. 2) When it happened, it seemed to "infect" all intersection tests -- even ones not related to the above problem -- so that they also started to return bogus (i.e., NANs) results when fed proper numbers. Is this behaviour to be expected? Thanks to all who helped, scott -- Scott McMillan, Ph.D. (408) 656-3316 mcmillan@cs.nps.navy.mil URL: http://cs.nps.navy.mil/people/faculty/mcmillan/ Dept. of Computer Science/Naval Postgraduate School/Monterey, CA 93943 "Manuals! Manuals!! We don't need no stinkin' manuals!" From guest Fri May 5 13:44:41 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA20290; Fri, 5 May 1995 13:33:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA20287; Fri, 5 May 1995 13:33:33 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08773; Fri, 5 May 95 13:33:32 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id NAA16144; Fri, 5 May 1995 13:33:30 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id NAA05624; Fri, 5 May 1995 13:33:26 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:turnerm@post.aes.com id AA08755; Fri, 5 May 95 13:33:19 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA13103; Fri, 5 May 1995 13:33:18 -0700 Message-Id: <199505052033.NAA13103@surreal.asd.sgi.com> To: turnerm@post.aes.com (Mark Turner) Cc: info-performer@sgi.sgi.com Subject: Re: Shared Arena problem In-Reply-To: Your message of "Fri, 05 May 95 12:37:16 -0800." <9505051935.AA23341@ag.aes.com> Date: Fri, 05 May 95 13:33:18 -0700 From: Jim Helman Status: O > Performer Fatal (12): pfInitArenas() Could not create shared arena of 512000KB The default arenasize in Performer 1.2 is 256MB, so I assume the program is calling pfSharedArenaSize() to request the larger arena. Assuming you're on 5.X, you won't need to worry about virtual swap, so it should work as is, subject to the availability of contiguous space in the process address space and subject to any limitations in your shell's rlimit. The former shouldn't be a problem unless you are doing mmaps or something before pfInit(). The latter can be fixed with a few suitable calls to setrlimit or in the shell: Example: [check existing limits] b52# limit -h cputime unlimited filesize unlimited datasize 524288 kbytes stacksize 524288 kbytes coredumpsize unlimited memoryuse 524288 kbytes descriptors 2500 vmemoryuse 524288 kbytes b52# limit cputime unlimited filesize unlimited datasize 524288 kbytes stacksize 65536 kbytes coredumpsize unlimited memoryuse 508996 kbytes descriptors 200 vmemoryuse 524288 kbytes b52# ./shmemhog 1500 requesting: 1572864000 bytes (1500MB) Performer Fatal (12):pfInitArenas() Could not create shared arena of 768000 KB [increase limits to approx 3GB, do NOT increase to 4GB or above since a kernel bug some versions of 5.X will interpret the number as NEGATIVE and prevent any process from running. You will get a "Killed" message even trying to run "ls"] b52# limit -h vmemoryuse 3000000 b52# limit -h memoryuse 3000000 b52# limit -h cputime unlimited filesize unlimited datasize 524288 kbytes stacksize 524288 kbytes coredumpsize unlimited memoryuse 3000000 kbytes descriptors 2500 vmemoryuse 3000000 kbytes [check new limits] b52# limit vmemoryuse 3000000 b52# limit memoryuse 3000000 b52# limit cputime unlimited filesize unlimited datasize 524288 kbytes stacksize 65536 kbytes coredumpsize unlimited memoryuse 3000000 kbytes descriptors 200 vmemoryuse 3000000 kbytes [run performer app with big arenasize] b52# ./shmemhog 1500 requesting: 1572864000 bytes (1500MB) Performer Debug (9):pfInitArenas() Allocated 1536000KB rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri May 5 12:50:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA20072; Fri, 5 May 1995 12:37:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA20069; Fri, 5 May 1995 12:37:14 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05677; Fri, 5 May 95 12:37:09 -0700 Received: from ag.aes.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA00988; Fri, 5 May 1995 12:37:05 -0700 Received: from [159.4.130.88] by ag.aes.com (4.1/CERFnet-1.0) id AA23341; Fri, 5 May 95 12:35:24 PDT Message-Id: <9505051935.AA23341@ag.aes.com> X-Sender: turnerm@ag.aes.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 May 1995 12:37:16 -0800 To: info-performer@sgi.sgi.com From: turnerm@post.aes.com (Mark Turner) Subject: Shared Arena problem Status: O Hi, I'm new to performer and I'm working on a application where I will be displaying DTED terrain data. I grabed the DTED file reader mentioned here previously and I hacked "smallfly" to use the DTED reader. When I run I get the following error: Performer Fatal (12): pfInitArenas() Could not create shared arena of 512000KB I read the manuals, but I don't completely understand the concept of "arenas" yet. I played with the swap space and the PFTMPDIR environment variable, but I still wasn't able to get the program to work. Any suggestions? Mark Turner Aerojet From guest Fri May 5 14:25:49 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA20486; Fri, 5 May 1995 14:12:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA20483; Fri, 5 May 1995 14:12:47 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10915; Fri, 5 May 95 14:12:47 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA26176; Fri, 5 May 1995 14:12:42 -0700 Received: from temple.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA13525; Fri, 5 May 95 16:56:28 EDT Received: by temple.vsl.ist.ucf.edu (940816.SGI.8.6.9) id QAA03161; Fri, 5 May 1995 16:55:01 -0400 Date: Fri, 5 May 1995 16:55:00 -0400 (EDT) From: "Lance R. Marrou" To: Scott McMillan Cc: info-performer@sgi.sgi.com Subject: Re: Performer intersection problem (maybe?) In-Reply-To: <199505051951.MAA00807@cool.cs.nps.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Fri, 5 May 1995, Scott McMillan wrote: > 1) I was running with pfNotifyLevel(PFNFY_FATAL) but performer never > complained. Is this because it will only output messages if Performer > generates NANs, but will do nothing if it starts with bad info in the > first place. PFNFY_FATAL is the highest level. Performer will only print out messages that relate to "...the dying gasp of a doomed process". You want to use: pfNotifyLevel(PFNFY_FP_DEBUG); and then hopefully you will see the errors as they occur. ______________________________________________________________________________ /\ ______ /\____ ______ ______ E-mail: marrou@vsl.ist.ucf.edu Visual / / / _ / / __ // ____// ____/ VSL: (407)658-5073 Systems / /__ / /_/ / / / / // /___ / __/_ R. Marrou Fax: (407)658-5059 Lab /____//____/\\/_/ /_//_____//_____/ http://www.vsl.ist.ucf.edu/~marrou "Reap the whirlwind." "We don't need no thought control." From guest Fri May 5 14:48:12 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA20537; Fri, 5 May 1995 14:35:04 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA20534; Fri, 5 May 1995 14:34:59 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12290; Fri, 5 May 95 14:34:45 -0700 Received: from palladium.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id OAA01888; Fri, 5 May 1995 14:34:40 -0700 Received: from giraffe.asd.sgi.com by palladium.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id OAA19307; Fri, 5 May 1995 14:18:56 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:mcmillan@cool.cs.nps.navy.mil id AA11359; Fri, 5 May 95 14:18:52 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA13190; Fri, 5 May 1995 14:18:51 -0700 Message-Id: <199505052118.OAA13190@surreal.asd.sgi.com> To: mcmillan@cool.cs.nps.navy.mil (Scott McMillan) Cc: info-performer@sgi.sgi.com Subject: Re: Performer intersection problem (maybe?) In-Reply-To: Your message of "Fri, 05 May 95 12:51:10 PDT." <199505051951.MAA00807@cool.cs.nps.navy.mil> Date: Fri, 05 May 95 14:18:50 -0700 From: Jim Helman Status: O > 1) I was running with pfNotifyLevel(PFNFY_FATAL) but performer never > complained. Is this because it will only output messages if Performer > generates NANs, but will do nothing if it starts with bad info in the > first place. PFNFY_FATAL tells Performer to only complain if it is about to die. NaN's are not usually fatal. If you want debugging info and FP exception details, you should set PFNFY_FP_DEBUG. > 2) When it happened, it seemed to "infect" all intersection tests -- > even ones not related to the above problem -- so that they also > started to return bogus (i.e., NANs) results when fed proper > numbers. Is this behaviour to be expected? I'm not sure how this could happen since nothing inside the toolkit should be reusing any data from a previous traversal. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri May 5 14:53:24 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA20576; Fri, 5 May 1995 14:43:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA20573; Fri, 5 May 1995 14:43:25 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12756; Fri, 5 May 95 14:43:21 -0700 Received: from taurus.cs.nps.navy.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) id OAA04157; Fri, 5 May 1995 14:43:18 -0700 Received: from cool.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA27649; Fri, 5 May 95 14:38:03 PDT Received: by cool.cs.nps.navy.mil (950215.SGI.8.6.10/940406.SGI) id OAA00892; Fri, 5 May 1995 14:38:00 -0700 From: mcmillan@cool.cs.nps.navy.mil (Scott McMillan) Message-Id: <199505052138.OAA00892@cool.cs.nps.navy.mil> Subject: Re: Performer intersection problem (maybe?) To: info-performer@sgi.sgi.com Date: Fri, 5 May 1995 14:38:00 -0700 (PDT) Cc: marrou@vsl.ist.ucf.edu, jimh@sgi.sgi.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 807 Status: O > 1) I was running with pfNotifyLevel(PFNFY_FATAL) but performer never > complained. Ack! Typo...I meant to say that I was running with pfNotifyLevel(PFNFY_DEBUG). Thanks to Lance for pointing out that there is yet another level (PFNFY_FP_DEBUG) that reports FP exceptions. Did you know that while this additional level is included in the Performer Reference Pages it is not included in my copy of the IRIS Performer Programming Guide (which I happened to be using as a reference that day)... another lesson learned. scott -- Scott McMillan, Ph.D. (408) 656-3316 mcmillan@cs.nps.navy.mil URL: http://cs.nps.navy.mil/people/faculty/mcmillan/ Dept. of Computer Science/Naval Postgraduate School/Monterey, CA 93943 "Manuals! Manuals!! We don't need no stinkin' manuals!" From guest Fri May 5 16:30:53 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA21051; Fri, 5 May 1995 16:17:19 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA21048; Fri, 5 May 1995 16:17:18 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18049; Fri, 5 May 95 16:17:13 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id QAA24517; Fri, 5 May 1995 16:17:09 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id QAA05475; Fri, 5 May 1995 16:17:07 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:mcmillan@cool.cs.nps.navy.mil id AA18038; Fri, 5 May 95 16:17:06 -0700 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA04546; Fri, 5 May 1995 16:17:04 -0700 From: "Michael Jones" Message-Id: <9505051617.ZM4544@babar.asd.sgi.com> Date: Fri, 5 May 1995 16:17:04 -0700 In-Reply-To: mcmillan@cool.cs.nps.navy.mil (Scott McMillan) "Re: Performer intersection problem (maybe?)" (May 5, 2:38pm) References: <199505052138.OAA00892@cool.cs.nps.navy.mil> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: mcmillan@cool.cs.nps.navy.mil (Scott McMillan), info-performer@sgi.sgi.com Subject: Re: Performer intersection problem (maybe?) Cc: marrou@vsl.ist.ucf.edu, jimh@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 5, 2:38pm, Scott McMillan wrote: > Subject: Re: Performer intersection problem (maybe?) :Did you know that while this additional level is included in the :Performer Reference Pages it is not included in my copy of the IRIS :Performer Programming Guide (which I happened to be using as a :reference that day)... another lesson learned. While I can't excuse our documentation oversight, I'll point out that should there be "extra" levels of detailed pfNotifies, you'd be sure to get them by using any really big number when setting the level. For example, "perfly -n99" will cause the 99 to be clamped to the largest effective level. Michael Jones -- 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 From guest Mon May 8 05:13:29 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA24272; Mon, 8 May 1995 05:09:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA24269; Mon, 8 May 1995 05:09:07 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13790; Mon, 8 May 95 05:06:23 -0700 Received: from dw3f.ess.harris.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA27524; Mon, 8 May 1995 05:08:56 -0700 From: jnemethy@dw3f.ess.harris.com Received: from dw3x.ess.harris.com (dw3x [130.41.10.25]) by dw3f.ess.harris.com (8.6.9/mdb(941103)) with SMTP id IAA03629; Mon, 8 May 1995 08:10:04 -0400 Received: by dw3x.ess.harris.com (5.57/Ultrix3.0-C) id AA12561; Mon, 8 May 95 08:10:44 -0400 Message-Id: <9505081210.AA12561@dw3x.ess.harris.com> To: turnerm@post.aes.com (Mark Turner) Cc: info-performer@sgi.sgi.com, jnemethy@dw3f.ess.harris.com Subject: Re: Shared Arena problem In-Reply-To: Your message of "Fri, 05 May 95 12:37:16 -0800." <9505051935.AA23341@ag.aes.com> Date: Mon, 08 May 95 08:10:43 -0400 X-Mts: smtp Status: O Mark, I don't know if you realized it, but there's a bug in the DTED reader during the reading of the header, specifically in DMA_read_DTED_terrain. The first 80 bytes must be accounted for otherwise, everything will be misaligned. Try adding the following line in DMA_read_DTED_terrain module. fseek(dted_file, 80, SEEK_SET); <---- Add this line. fread(dted, BYTE, 648, dted_file); ----------------------------------------------------------- Joe Nemethy | Phone 407-984-5856 (Office) Harris Corporation, ISD | 407-984-6813 (Lab) P.O. Box 98000 | Fax 407-984-6323 W3-3209 | email: jnemethy@harris.com Melbourne, FL 32902 | ----------------------------------------------------------- From guest Mon May 8 12:39:13 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA24728; Mon, 8 May 1995 12:13:22 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA24725; Mon, 8 May 1995 12:13:13 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03105; Mon, 8 May 95 12:13:09 -0700 Received: from od.sri.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA02722; Mon, 8 May 1995 12:13:06 -0700 Received: by od.sri.com (931110.SGI/930416.SGI) for info-performer@sgi.com id AA29413; Mon, 8 May 95 12:04:38 -0700 From: "Nathaniel Bletter" Message-Id: <9505081204.ZM29411@od.sri.com> Date: Mon, 8 May 1995 12:04:37 -0700 In-Reply-To: ROY RUDDLE "pfMakePerspFrust error?" (May 5, 2:55pm) References: X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Ruddle@cardiff.ac.uk, info-performer@sgi.sgi.com Subject: Re: pfMakePerspFrust error? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I've had this same exact problem with pfMakePerspFrust. I think the performer people should look into this. The FOV of the frustrum never gets changed unless you actually do a PfFrustFOV() set call. The actual frustrum doesn't change unless you do this also. Seems like a bug. -- Nat Bletter SRI International nat@od.sri.com http://os.sri.com/people/nat/ (415) 859-4358 From guest Mon May 8 14:45:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA25099; Mon, 8 May 1995 14:24:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA25096; Mon, 8 May 1995 14:24:02 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11581; Mon, 8 May 95 14:24:01 -0700 Received: from adadv1 by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA28494; Mon, 8 May 1995 14:23:54 -0700 From: lechnerr@adadv1.mdc.com Date: Mon, 8 May 1995 16:23:53 -0500 Message-Id: <95050816235370@adadv1.mdc.com> To: info-performer@sgi.sgi.com Subject: Non-orthogonal Perspective Matrices X-Vms-To: SMTP%"info-performer@sgi.com" Status: O I am developing an application that requires the screen projection plane to be non-normal to the eye line of sight vector. The screen plane can move in both azimuth and elevation. This, of course induces keystone in the image without compensation. I would like to correct for this in the perspective transformation in Performer. Does anybody have the proper matrix transformation to multiply the perspective matrix by to induce keystone distortion correction on the projection plane. . | . | Screen . | Plane . .| . . . . eye < . I also want to make sure I am attaching the perspective matrix correctly. The following is a snipet from my code. It is within a Draw Callback function. (done before DrawCallback) frust1 = pfNewFrustum(NULL); frust2 = pfNewFrustum(NULL); Draw Callback: { /** Set up Key Comensation Matrix **/ pfMakeIdentMat(key_comp_mat); pfSetVec3(key_comp_vec,key_x,key_y,key_z); pfSetMatColVec3(key_comp_mat,2,key_comp_vec); /** Get Perspective Frustum and Apply Comp **/ pfGetBaseFrust(chan,frust1); pfOrthoXformFrust(frust2,frust1,key_comp_mat); pfApplyFrust(frust2); pfDraw(); } This seems to effect the perspective correctly. I'm just missing the correct compensation factors. PS- I tried putting the frustum data back into pfChan in pfOrthoXformFrust as the man pages state, but it complained. My only guess is that pfChan does not carry along the actual projection matrix, on the perspective parameters to build the matrix? RJL McDonnell Douglas Corp. From guest Mon May 8 17:16:11 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA25818; Mon, 8 May 1995 16:49:46 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA25815; Mon, 8 May 1995 16:49:45 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21075; Mon, 8 May 95 16:49:32 -0700 Received: from relay3.UU.NET by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA29744; Mon, 8 May 1995 16:49:16 -0700 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyoxb13576; Mon, 8 May 1995 19:49:14 -0400 Received: from multigen.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 8 May 1995 19:49:14 -0400 Received: from MAIL_CENTER (QM 3.0) by multigen.uucp (UMCP\QM 2.0.1) id AA01030; Mon, 8 May 1995 14:41:17 PST Message-Id: <00581.2882788877.1030@multigen.uucp> Organization: MultiGen, Inc. X-Charset: MACINTOSH X-Umcp-Priority: 1 X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Mon, 8 May 1995 14:26:26 PST Subject: Re: >pfMakePerspFrust error? Status: O Reply to: RE>>pfMakePerspFrust error? >Subject: Re: pfMakePerspFrust error? > >I've had this same exact problem with pfMakePerspFrust. I think the >performer people should look into this. The FOV of the frustrum never >gets changed unless you actually do a PfFrustFOV() set call. The actual >frustrum doesn't change unless you do this also. Seems like a bug. > >Nat Bletter >SRI International >nat@od.sri.com >http://os.sri.com/people/nat/ >(415) 859-4358 I think you are right on this. A while ago I create a stereo version of perfly that used the Fakespace Boom. I had found that FOV wasn't really "shared" across channels as documented. It might seem so only for the default 45 degree FOV but other values show that there is a problem. All "shared" FOV's not explicitely set will be 45 degrees regardless of the "master" channel FOV. This was in Performer 1.2 btw. Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: 1-408-261-4118 FX: 1-408-247-4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Tue May 9 01:50:20 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA27902; Tue, 9 May 1995 01:22:13 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA27899; Tue, 9 May 1995 01:22:07 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07865; Tue, 9 May 95 01:22:06 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA24984; Tue, 9 May 1995 01:21:51 -0700 Received: (from uucp@localhost) by warrane.connect.com.au with UUCP id SAA25828 (8.6.11/IDA-1.6 for info-performer@sgi.com); Tue, 9 May 1995 18:21:22 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA29881 (5.65c/IDA-1.5 for ); Tue, 9 May 1995 17:47:59 +1000 Received: from homer (homer [8.0.0.44]) by aggro with SMTP id RAA24301 (8.6.12/IDA-1.6 for ); Tue, 9 May 1995 17:49:50 +1000 Received: by homer (5.65) id AA09098; Tue, 9 May 1995 17:49:50 +1000 Date: Tue, 9 May 1995 17:49:49 +1000 (EST) From: Kathy Loynes Sender: Kathy Loynes Reply-To: Kathy Loynes Subject: Blurring / Sharpening images in Real Time To: Performer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: O Hi, In the application that I am working on I have a requirement to focus & defocus the generated image. This is effectively emulating the behaviour of focusing a camera. I had come up with two possible approaches to doing this : (1) Perform some sort of image processing to blur or sharpen the image in the framebuffer in my post-draw callback. I was looking at some of the image enhancement sample code in the /src/haeberli/ directory on the Developers Toolkit CD and believe that some nice effects could be achieved. However, not surprisingly, this doesn't look like it's possible at a 30 Hz framerate. Simply calling lrectread() & lrectwrite() (without attempting any fiddling with pixel values) results in the frame rate in my application dropping from 36Hz down to approx 24Hz. Does anyone think it is worth pursuing this approach ? Is it possible to significantly speed up lrectread() & lrectwrite() ? I only need to work with a monochrome image at a resolution of 640x480. I was surprised that, at that resolution and running on an 2RM RE2, the effect was as noticeable as it was. Is there something obvious I'm missing ? I did try using rectcopy() with the same source and destination pixels (as I believe there are various image processing effects that can be done by the GEs during a rectcopy call). This was quick, no noticeable frame rate hit, but I'm not too clear on what could be achieved via this method. I had a look at the convolve() manpage but that didn't seem to clarify much...... Should I be investigating the ImageVision library ? I've never used it before and so am a little hazy on what sort of effects could be achieved. (2) Another approach was to use the accumulation buffer to blur the image as required. I believe this is possible in realtime (I haven't actually tried this out yet) and is good for motion blur but may not be exactly the focusing effect I'm looking for. Many thanks in advance for any suggestions. ---------------------------------------------------------------------- Kathy Loynes | Wormald Technology kathyl@wormald.com.au | Advanced Systems Engineering Ph: +61 2 981 0611 | Sydney, Australia From guest Tue May 9 01:40:08 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA27880; Tue, 9 May 1995 01:12:04 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA27877; Tue, 9 May 1995 01:12:03 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07735; Tue, 9 May 95 01:12:03 -0700 Received: from radian.Nagoya.tcp-net.ad.jp by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA24471; Tue, 9 May 1995 01:11:56 -0700 Received: from tytcprm.tytlabs.co.jp (tytcprm.tytlabs.co.jp [133.240.100.2]) by radian.Nagoya.tcp-net.ad.jp (8.6.9+2.4W/3.3W7-TCP(radian)03/03/95) with ESMTP id RAA20024 for ; Tue, 9 May 1995 17:11:43 +0900 Received: from popeye.vdlab.tytlabs.co.jp (popeye [133.240.210.45]) by tytcprm.tytlabs.co.jp (8.6.10+2.4W/3.3W8-05/01/95) with ESMTP id RAA18247 for ; Tue, 9 May 1995 17:11:29 +0900 Received: by popeye.vdlab.tytlabs.co.jp (1.37.109.14/6.4J.6) id AA104127088; Tue, 9 May 1995 17:11:28 +0900 Date: Tue, 9 May 1995 17:11:28 +0900 From: mizuno@popeye.vdlab.tytlabs.co.jp (MIZUNO Masahiko) Message-Id: <199505090811.AA104127088@popeye.vdlab.tytlabs.co.jp> To: info-performer@sgi.sgi.com Subject: How to control moving object Reply-To: =?ISO-2022-JP?B?GyRCP2VMbjJtSScbKEI=?= Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Status: O Hi, I am trying to make realtime simulation program using Performer 1.2 on IRIX 5.2. Please tell me the way of control moving object. The track can move in the demonstration program. How can we control track? ---------------------------------------------------------- MIZUNO Masahiko, Man-Machine System Lab. TOYOTA Central R&D Labs., Inc. Nagakute , Aichi , 480-11 JAPAN Tel:+81-561-62-6111(3736) Fax:+81-561-63-5743 E-mail address: mizuno@vdlab.tytlabs.co.jp From guest Tue May 9 00:29:16 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA27610; Tue, 9 May 1995 00:09:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA27607; Tue, 9 May 1995 00:09:35 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05549; Tue, 9 May 95 00:09:31 -0700 Received: from bvr.co.il by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id AAA19966; Tue, 9 May 1995 00:09:19 -0700 Received: from amcor.bvr.co.il by bvr.co.il via SMTP (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA01669; Tue, 9 May 95 10:15:06 +0300 Received: by amcor.bvr.co.il (940816.SGI.8.6.9/911001.SGI) id KAA08371; Tue, 9 May 1995 10:06:31 +0300 From: "Ran Yakir" Message-Id: <9505091006.ZM8369@amcor.bvr.co.il> Date: Tue, 9 May 1995 10:06:22 +0000 In-Reply-To: "Holger Krumm" "! Texture out of framebuffer ? !" (May 9, 7:17am) References: <9505090717.ZM27315@neutra> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Holger Krumm" Subject: Re: ! Texture out of framebuffer ? ! Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > > is it possible to get the contents of the framebuffer to generate a texture > out of it, like a 'screenshot'? I read the programmer's guide and the manual > pages, but can't find anything about it? Do I have to use OpenGL for it? > Yes. The GL function to do that is fbsubtexload(). It loads a rectangular region of the framebuffer into a predefined texture. The texture has to be defined with the TX_FAST_DEFINE property, so it can not have mip-mapping. You also must define the texture dimensions to be a power of two. The rectangular region you are loading must have dimensions that divides by 32. I've never used fbsubtexload() along with Performer, but I think it is rather straightforward. The following Performer code fragments will do the job (I hope) : /* * At initialization */ screen_tex = pfNewTex (arena); pfTexFilter (screen_tex, PFTEX_MINFILTER, PFTEX_BILINEAR); /* no mipmap !!! */ pfTexFilter (screen_tex, PFTEX_MAGFILTER, PFTEX_BILINEAR); pfTexFormat (screen_tex, PFTEX_FAST_DEFINE, PF_ON); pfTexImage (screen_tex, NULL, 3, xsize, ysize, 1); ... /* * At the post-draw callback */ pfApplyTEnv (env); pfApplyTex (screen_tex); fbsubtexload (screen_x, screen_y, TX_TEXTURE_0, pfGetGLHandle (screen_tex), 0.0, 1.0, 0.0, 1.0, 0); ... This is the simple case in which you fill the whole texture with your screen image. In other cases, you specify that part of the texture which has to be filled using the 5th to 8th arguments of the function. If you need a complete example source, I can compose one for you. Regards, Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | From guest Tue May 9 03:41:53 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA28145; Tue, 9 May 1995 03:29:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA28142; Tue, 9 May 1995 03:29:40 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10087; Tue, 9 May 95 03:29:40 -0700 Received: from pigeon.cf.ac.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA02088; Tue, 9 May 1995 03:29:33 -0700 Received: from thor.cf.ac.uk by pigeon.cf.ac.uk with SMTP (PP) id <04399-0@pigeon.cf.ac.uk>; Tue, 9 May 1995 11:28:37 +0100 Date: Tue, 9 May 1995 11:29:19 +0100 (BST) From: ROY RUDDLE Reply-To: Ruddle@cardiff.ac.uk To: info-performer@sgi.sgi.com Subject: Re: pfMakePerspFrust error? In-Reply-To: <9505081204.ZM29411@od.sri.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O OK. I've investigated further. There doesn't seem to be a (documented?) PfFrustFOV() or similar call, but if I use pfChanFOV then the frustrum FOV gets set correctly. BUT, everything goes totally whacky when I start introducing clipping - there seems to be a conflict somewhere in Performer's guts. Anyway, UK Support are now aware of the problem. roy ------------------------------------------------------------------------ Roy Ruddle, Principal Researcher | School of Psychology Tel: 01222 874523 (direct) | University of Wales College of Cardiff 01222 874007 (messages) | PO Box 901 Fax: 01222 874858 | Cardiff CF1 3YG Email: Ruddle@CARDIFF.AC.UK | UK From guest Tue May 9 03:39:07 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA28140; Tue, 9 May 1995 03:27:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA28137; Tue, 9 May 1995 03:27:15 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10058; Tue, 9 May 95 03:27:11 -0700 Received: from nordwest.pop.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA02011; Tue, 9 May 1995 03:27:01 -0700 Received: from pink.atlas.de by nordwest.pop.de with smtp (Smail3.1.28.1 #6) id m0s8mNT-0000CCC; Tue, 9 May 95 12:18 MES Received: from tyrann mygate by pink.atlas.de (4.1/GEN-1.0.7) via CASEnet for mail.nordwest.pop.de id AA15352; Tue, 9 May 95 12:15:23 +0200 Date: Tue, 9 May 1995 12:16:29 +0000 (GMT-1:00) From: E-Hendon To: info-performer@sgi.sgi.com Subject: Builder and Breakup Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi I am looking for a way to break up the large geosets created by the pfuBuilder. It seems that pfuBuilder builds one large geoset, indifferent to the fact that the pfuTris referenced may be spatially very distant. (The builder generally seems to generate QUADs even though this is not always desirable, since breakup works on TRI_STRIPS. I have attempted to set pfBreakup on these geosets (child of geode) but without success. Any help is greatly appreciated! --------------------------------------------------------------------------- E. Hendon STN-Atlas Elektronik GmbH Simulation Division Sebaldsbruecker Heerstr. 235, D-28305 Bremen email: elke@tyrann.atlas.de Telefon: 0421/457 3122 --------------------------------------------------------------------------- From guest Mon May 8 22:42:56 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA27280; Mon, 8 May 1995 22:17:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA27274; Mon, 8 May 1995 22:17:58 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03253; Mon, 8 May 95 22:17:49 -0700 Received: from hni.uni-paderborn.de by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA11133; Mon, 8 May 1995 22:17:40 -0700 Received: from neutra.uni-paderborn.de (neutra [131.234.244.2]) by hni.uni-paderborn.de (8.6.10/hni-mailhub) with ESMTP id HAA29377; Tue, 9 May 1995 07:17:34 +0200 Received: (hok@localhost) by neutra.uni-paderborn.de (8.6.10/client-irix-hni) id FAA27317; Tue, 9 May 1995 05:17:34 GMT From: "Holger Krumm" Message-Id: <9505090717.ZM27315@neutra> Date: Tue, 9 May 1995 07:17:33 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: ! Texture out of framebuffer ? ! Cc: hok@hni.uni-paderborn.de Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hello everybody, is it possible to get the contents of the framebuffer to generate a texture out of it, like a 'screenshot'? I read the programmer's guide and the manual pages, but can't find anything about it? Do I have to use OpenGL for it? Thanks in advance, Holger PS: If this description should be a little short of information, reply to me my personal mail and I will give more background about the problem. ------------------------------------------------------------------------- Holger Krumm Heinz Nixdorf Institut Heinrich-Luecking Str. 22 33098 Paderborn +49 05251 740164 => Visualisation of a virtual enterprise EMail: hok@hni.uni-paderborn.de http://wwwhni.uni-paderborn.de/personen/hok/index.html ------------------------------------------------------------------------- From guest Tue May 9 07:50:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA28419; Tue, 9 May 1995 07:48:01 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA28416; Tue, 9 May 1995 07:48:00 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14633; Tue, 9 May 95 07:48:00 -0700 Received: from alexandra.mtl.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA21670; Tue, 9 May 1995 07:47:56 -0700 Received: from Maddie (maddie [192.148.246.55]) by alexandra.mtl.com (8.6.10/8.6.6) with ESMTP id KAA05537 for ; Tue, 9 May 1995 10:48:31 -0400 Received: by Maddie (940816.SGI.8.6.9/Spike-2.0) id KAA09987; Tue, 9 May 1995 10:43:58 -0400 From: "John A. Collier" Message-Id: <9505091043.ZM9985@Maddie.mtl.com> Date: Tue, 9 May 1995 10:43:57 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Specular Reflection Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi All, The current maximum shininess is 128.0 and gives a bit too large a diameter of a reflection. Is there any way to shrink the reflection smaller. The application we are using this for is specular reflection in the IR. We can calculate what exitance (color) and want hardware to calculate which facets to illuminate. The problem is that the reflection angle is too big even at the maximum shininess (128.0) setting. Any suggestions? Thanks, John -- John A. Collier e-mail: jcollier@mtl.com MTL Systems, Inc. voice: (513) 426-3111 3481 Dayton-Xenia Rd. fax: (513) 426-8301 Dayton, OH 45432-2796 From guest Tue May 9 08:07:11 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA28443; Tue, 9 May 1995 08:05:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA28440; Tue, 9 May 1995 08:05:09 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15120; Tue, 9 May 95 08:05:09 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id IAA24191; Tue, 9 May 1995 08:05:06 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id IAA18946; Tue, 9 May 1995 08:05:05 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:Ruddle@cardiff.ac.uk id AA15111; Tue, 9 May 95 08:05:03 -0700 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id IAA02291; Tue, 9 May 1995 08:05:01 -0700 From: "Michael Jones" Message-Id: <9505090805.ZM2289@babar.asd.sgi.com> Date: Tue, 9 May 1995 08:05:00 -0700 In-Reply-To: ROY RUDDLE "pfMakePerspFrust error?" (May 5, 2:55pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Ruddle@cardiff.ac.uk, info-performer@sgi.sgi.com Subject: Re: pfMakePerspFrust error? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 5, 2:55pm, ROY RUDDLE wrote: > Subject: pfMakePerspFrust error? :Ref. p153 in the 1.2 Performer Reference manual. I've tried doing this :with just one frustrum, but the FOV I get is 45 (horiz) by 43.xxx (vert). : :Any suggestions anyone? Code is (C++): : :pfChannel *left = pfNewChan(pfGetPipe(0)); :float v_fov = 22.5f; :float t = pfTan( v_fov ); :pfMakePerspFrust(left, -1.0f, 0.0f, -t, t); :pfFrustNearFar(left, 1.0f, 1000.0f); :float ffh, ffv; :pfGetFrustFOV( left, &ffh, &ffv ); :cout << "frust FOV " << ffh << " " << ffv << endl; This is indeed a bug. First report I've seen, although it seems to have inspired several similar bug reports. I looked at the code and there is indeed a problem. I fixed it, though, and the new results are as expected: babar!mtj% cat frust.c #include #include #include #include "Performer/pr.h" main () { float t = 0.0f; float h = 0.0f; float v = 0.0f; pfFrustum *frust; t = pfTan(12.5f); frust = pfNewFrust(NULL); pfMakePerspFrust(frust, -1.0f, 0.0f, -t, t); pfFrustNearFar(frust, 1.0f, 1000.0f); pfGetFrustFOV(frust, &h, &v); printf("h = %f\n", h); printf("v = %f\n", v); } babar!mtj% make frust.dsocmd babar!mtj% ./frust.dsocmd h = 53.130104 v = 45.000004 The bug was that the center of projection was always mistakenly computed to be at the "center" of the near plane, as is the case for symmetric perspective frusta. It's fixed now. -- 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 From guest Tue May 9 08:48:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA28617; Tue, 9 May 1995 08:45:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA28614; Tue, 9 May 1995 08:45:59 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16484; Tue, 9 May 95 08:45:58 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id IAA00534; Tue, 9 May 1995 08:45:55 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) id IAA24023; Tue, 9 May 1995 08:45:51 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id QAA01482; Tue, 9 May 1995 16:29:46 +0100 From: "Rob Jenkins" Message-Id: <9505091629.ZM1480@barney.reading.sgi.com> Date: Tue, 9 May 1995 16:29:45 +0100 In-Reply-To: Kathy Loynes "Blurring / Sharpening images in Real Time" (May 9, 5:49pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Kathy Loynes , Performer Subject: Re: Blurring / Sharpening images in Real Time Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19505091629.ZM1480.reading.sgi.com" Status: O -- --PART-BOUNDARY=.19505091629.ZM1480.reading.sgi.com Content-Type: text/plain; charset=us-ascii Sorry - I didn't attach the attachment :-) note - you may find that the number of images you need to accumulate makes this method less than realtime also - let me know what you think. -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, --PART-BOUNDARY=.19505091629.ZM1480.reading.sgi.com X-Zm-Content-Name: dof.c Content-Description: Text Content-Type: text/plain ; name="dof.c" ; charset=us-ascii ; x-irix-type=CProgram /* dof.c This program draws a torus and beam using the accumulation buffer to simulate depth of field. */ #include #include #include #include #include "shapes.h" #include "dof.h" #include "jitter.h" float shiny_material[] = { DIFFUSE, 0.4, 0.4, 0.4, SPECULAR, 1.0, 1.0, 1.0, SHININESS, 128.0, LMNULL }; void def_simple_light_calc(void) { lmdef(DEFMATERIAL, 1, 11, shiny_material); lmdef(DEFLIGHT, 1, 0, NULL); lmdef(DEFLMODEL, 1, 0, NULL); } void use_simple_light_calc(void) { lmbind(LIGHT0, 1); lmbind(LMODEL, 1); } void main(void) { short attached; short value; int dev; attached = 1; if (!getgdesc(GD_BITS_ACBUF)) { fprintf(stderr, "This machine does not support the accumulation buffer.\n"); exit(0); } initialize(); while (TRUE) { while (qtest() || !attached) { dev = qread (&value); if ((dev == ESCKEY) && (value == 0)) exit(0); else if (dev == REDRAW) { reshapeviewport(); drawscene(); } else if (dev == INPUTCHANGE) attached = value; } /* end while qtest or not attached */ drawscene(); } /* end while (TRUE) */ } /* end main() */ /* The initialize subroutine positions the window and specifies * its future constraints. The program is in double buffer * and RGB mode. The simplest lighting model is used. */ void initialize(void) { long gid1; long xmax, ymax; xmax = getgdesc(GD_XPMAX); ymax = getgdesc(GD_YPMAX); prefposition( xmax/4, xmax*3/4, ymax/4, ymax*3/4 ); gid1 = winopen ("Depth of Field"); minsize (xmax/10, ymax/10); keepaspect (xmax, ymax); winconstraints(); doublebuffer(); RGBmode(); acsize(16); gconfig(); zbuffer(TRUE); subpixel(TRUE); qdevice (ESCKEY); qenter (REDRAW, gid1); mmode(MVIEWING); def_simple_light_calc(); use_simple_light_calc(); } /* Draw a beam and torus with depth of field. */ void drawscene(void) { int jitter; static Angle angle = 0; acbuf(AC_CLEAR, 0.0); for(jitter = 0; jitter < 8; jitter++) { czclear(0,getgdesc(GD_ZMAX)); pushmatrix(); accperspective(450, 1.0, 3.0, 6.0, 0.0, 0.0, j8[jitter].x, j8[jitter].y, 5.0); lookat(0.0, 0.0, 5.0, 0.0, 0.0, 0.0, 0); rotate(angle, 'x'); lmbind(MATERIAL,1); ftorus(); scale(1.0,3.0,0.5); fcube(); popmatrix(); acbuf(AC_ACCUMULATE, 1.0); } angle += 50; acbuf(AC_RETURN, 1.0/8.0); swapbuffers(); } /* accwindow() The first six arguments are identical to standard gl window() call pixdx and pixdy are anti-alias jitter in pixels. Set both equal to 0.0 for no anti-alias jitter. eyedx and eyedy are depth-of field jitter in pixels. Set both equal to 0.0 for no depth of field effects. focus is distance from eye to plane in focus. focus must be greater than, but not equal to 0.0 Note that accwindow() calls translate(). You will probably want to insure that your ModelView matrix has been initialized to identity before calling accwindow() */ void accwindow( float left, float right, float bottom, float top, float near, float far, float pixdx, float pixdy, float eyedx, float eyedy, float focus) { float xwsize, ywsize; float dx, dy; long xpixels, ypixels; getsize(&xpixels, &ypixels); xwsize = right - left; ywsize = top - bottom; dx = -(pixdx*xwsize/xpixels + eyedx*near/focus); dy = -(pixdy*ywsize/ypixels + eyedy*near/focus); window(left + dx, right + dx, bottom + dy, top + dy, near, far); translate(-eyedx, -eyedy, 0.0); } /* accperspective() The first four arguments are identical to standard gl perspective() call pixdx and pixdy are anti-alias jitter in pixels. Set both equal to 0.0 for no anti-alias jitter. eyedx and eyedy are depth-of field jitter in pixels. Set both equal to 0.0 for no depth of field effects. focus is distance from eye to plane in focus. focus must be greater than, but not equal to 0.0 Note that accperspective() calls accwindow() */ void accperspective( Angle fovy, float aspect, float near, float far, float pixdx, float pixdy, float eyedx, float eyedy, float focus) { float fov2,left,right,bottom,top; fov2 = ((fovy*M_PI) / 1800.0) / 2.0; top = near / (fcos(fov2) / fsin(fov2)); bottom = -top; right = top * aspect; left = -right; accwindow(left,right,bottom,top,near,far,pixdx,pixdy,eyedx,eyedy,focus); } --PART-BOUNDARY=.19505091629.ZM1480.reading.sgi.com X-Zm-Content-Name: dof.h Content-Description: Text Content-Type: text/plain ; name="dof.h" ; charset=us-ascii ; x-irix-type=HeaderFile /* include file for dof.c */ void def_simple_light_calc(void); void use_simple_light_calc(void); void initialize(void); void drawscene(void); void accwindow( float left, float right, float bottom, float top, float near, float far, float pixdx, float pixdy, float eyedx, float eyedy, float focus); void accperspective( Angle fovy, float aspect, float near, float far, float pixdx, float pixdy, float eyedx, float eyedy, float focus); --PART-BOUNDARY=.19505091629.ZM1480.reading.sgi.com-- From guest Tue May 9 09:25:27 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA28686; Tue, 9 May 1995 09:23:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA28683; Tue, 9 May 1995 09:23:05 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18014; Tue, 9 May 95 09:23:05 -0700 Received: from shallow.division.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA05667; Tue, 9 May 1995 09:22:58 -0700 Received: from caliban.division.co.uk by shallow.division.co.uk with SMTP id AA04801 (5.65c/IDA-1.4.4 for info-performer@sgi.com); Tue, 9 May 1995 16:21:06 GMT Received: by caliban.division.co.uk (931110.SGI/921111.SGI) for @shallow.division.co.uk:info-performer@sgi.com id AA06777; Tue, 9 May 95 17:25:10 +0100 From: "Angus Dorbie" Message-Id: <9505091725.ZM6775@caliban.division.co.uk> Date: Tue, 9 May 1995 17:25:10 +0100 In-Reply-To: "John A. Collier" "Specular Reflection" (May 9, 10:43am) References: <9505091043.ZM9985@Maddie.mtl.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "John A. Collier" Subject: Re: Specular Reflection Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > The current maximum shininess is 128.0 and gives a bit too large a diameter of > a reflection. Is there any way to shrink the reflection smaller. > > The application we are using this for is specular reflection in the IR. We can > calculate what exitance (color) and want hardware to calculate which facets to > illuminate. The problem is that the reflection angle is too big even at the > maximum shininess (128.0) setting. > > Any suggestions? If you have distant light sources then you could try using an environment map texgen(TG_SPHEREMAP) with the specular highlight painted on the environment texture, but moving the light relative to the eye is _expensive_. The other thing to watch is that you have localviewer product vector calculation enabled in the lighting model, without this highlights on some surfaces could appear artificially large (and in the wrong place), even infinitely large with distant lights and flat surfaces. I'd even be tempted to try values greater than 128.0 but I've never tried this and I'm sure someone will say it's a _really_ bad idea :) Just some suggestions, Angus. -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.co.uk UK From guest Tue May 9 15:11:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA29730; Tue, 9 May 1995 14:52:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA29727; Tue, 9 May 1995 14:52:30 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07172; Tue, 9 May 95 14:52:21 -0700 Received: from lgc.lgc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA22825; Tue, 9 May 1995 14:52:19 -0700 From: mlg@lgc.com Received: from junior.lgc.com by lgc.lgc.com (5.65b/lgc.1.23) id AA00213; Tue, 9 May 95 16:52:19 -0500 Received: from hrn.lgc.com by junior.lgc.com (8.6.9/lgc.1.25) id QAA17137; Tue, 9 May 1995 16:56:09 -0500 Received: by hrn.lgc.com (4.1/lgc.1.9) id AA07900; Tue, 9 May 95 16:56:49 CDT Date: Tue, 9 May 95 16:56:49 CDT Message-Id: <9505092156.AA07900@hrn.lgc.com> To: info-performer@sgi.sgi.com Subject: unsubscribe Status: O From guest Tue May 9 23:39:49 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA01154; Tue, 9 May 1995 23:28:46 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id XAA01151; Tue, 9 May 1995 23:28:45 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24733; Tue, 9 May 95 23:28:44 -0700 Received: from bvr.co.il by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id XAA07649; Tue, 9 May 1995 23:28:33 -0700 Received: from amcor.bvr.co.il by bvr.co.il via SMTP (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA03073; Wed, 10 May 95 09:34:15 +0300 Received: by amcor.bvr.co.il (940816.SGI.8.6.9/911001.SGI) id JAA02130; Wed, 10 May 1995 09:25:40 +0300 From: "Ran Yakir" Message-Id: <9505100925.ZM2128@amcor.bvr.co.il> Date: Wed, 10 May 1995 09:25:38 +0000 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: kathyl@wormald.COM.AU Subject: Re: Blurring / Sharpening images in Real Time Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Kathy, I'm afraid that doing image processing with the host CPU, will get you nowhere. As you said, only the lrectread() and lrectwrite() is bad enough. That is, ofcourse, for a resolution of 640 X 480. If you are willing to render the image at a lower resolution when the defocus is on, you might be able to do this. Using the convolve() function of the RE will have better results. I've tried bluring an OTW image with convolve() and those are the results : kernel size resolution time (milisec) ----------- ---------- ---- 3X3 seperable 640X480 10 5X5 seperable 640X480 12 7X7 seperable 640X480 15 If your application is drawing the scene in less than 15 milisec, you might have 30 Hz with 7X7 convlution. Note that I've used the CV_SEPERABLE convolution which is less accurate, but faster. I can measure the CV_GENERAL convolution if you like. A substantial performance gain is achieved by using 8 bit pixel operations instead of 24 bit. This is possible in your case since you use monochrome image. The following code does the job : ... static float kernel3[] = { 1/6, 1/6, 1/6, 1/6, 1/6, 1/6 }; static float kernel5[] = { 1/10, 1/10, 1/10, 1/10, 1/10, 1/10, 1/10, 1/10, 1/10, 1/10 }; static float kernel7[] = { 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14, 1/14 }; float *kernel; /* * select the appropriate kernel */ switch (shared->blur_kernel_size) { case 3 : kernel = kernel3; break; case 5 : kernel = kernel3; break; case 7 : kernel = kernel3; break; default : return; } /* * set up the convolution params */ convolve (CV_SEPARABLE, CV_REDUCE, shared->blur_kernel_size, shared->blur_kernel_size, kernel, 0.0f); /* * set up pixel op. mode to monochrome (input - I, output - RGB) */ pixmode (PM_SIZE, 8); pixmode (PM_INPUT_TYPE, PM_UNSIGNED_BYTE); pixmode (PM_INPUT_FORMAT, PM_LUMINANCE); pixmode (PM_OUTPUT_FORMAT, PM_BGR); /* * copy the original image to another part of the screen */ rectcopy (mx0, my0, mx1, my1, to_x, to_y); /* * restore everithing to normal */ pixmode (PM_SIZE, 32); pixmode (PM_INPUT_FORMAT, PM_ABGR); pixmode (PM_OUTPUT_FORMAT, PM_ABGR); convolve (CV_OFF, CV_REDUCE, 3, 3, kernel, 0.0f); } As for the accumulation buffer, anything you do with it requires multiple rendering. You can have realtime performance only if you scene is drawn _very_ fast. Regards, Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | From guest Wed May 10 01:22:46 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA01457; Wed, 10 May 1995 01:16:49 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA01454; Wed, 10 May 1995 01:16:49 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26468; Wed, 10 May 95 01:16:48 -0700 Received: from nordwest.pop.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id BAA14704; Wed, 10 May 1995 01:16:41 -0700 Received: from pink.atlas.de by nordwest.pop.de with smtp (Smail3.1.28.1 #6) id m0s96s7-0000g8C; Wed, 10 May 95 10:11 MES Received: from tyrann mygate by pink.atlas.de (4.1/GEN-1.0.7) via CASEnet for mail.nordwest.pop.de id AA08304; Wed, 10 May 95 10:08:17 +0200 Date: Wed, 10 May 1995 10:09:27 +0000 (GMT-1:00) From: E-Hendon To: info-performer@sgi.sgi.com Subject: dynamic terrain Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Has anyone implemented dynamic terrain with Performer? I would like to assess Performer's applicablility in this case. grateful for all inputs/comments etc. --------------------------------------------------------------------------- E. Hendon STN-Atlas Elektronik GmbH Simulation Division Sebaldsbruecker Heerstr. 235, D-28305 Bremen email: elke@tyrann.atlas.de Telefon: 0421/457 3122 --------------------------------------------------------------------------- From guest Wed May 10 01:53:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA01494; Wed, 10 May 1995 01:42:29 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA01491; Wed, 10 May 1995 01:42:28 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26818; Wed, 10 May 95 01:42:27 -0700 Received: from nordwest.pop.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id BAA16338; Wed, 10 May 1995 01:42:22 -0700 Received: from pink.atlas.de by nordwest.pop.de with smtp (Smail3.1.28.1 #6) id m0s97Ix-0000ltC; Wed, 10 May 95 10:39 MES Received: from tyrann mygate by pink.atlas.de (4.1/GEN-1.0.7) via CASEnet for mail.nordwest.pop.de id AA08729; Wed, 10 May 95 10:36:02 +0200 Date: Wed, 10 May 1995 10:37:12 +0000 (GMT-1:00) From: E-Hendon To: info-performer@sgi.sgi.com Subject: dynamic terrain Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Has anyone looked into the applicablility of Performer for dynamic terrain? Very intereseted in hearing comments, suggestions etc. Thanks --------------------------------------------------------------------------- E. Hendon STN-Atlas Elektronik GmbH Simulation Division Sebaldsbruecker Heerstr. 235, D-28305 Bremen email: elke@tyrann.atlas.de Telefon: 0421/457 3122 --------------------------------------------------------------------------- From guest Wed May 10 03:58:19 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA01768; Wed, 10 May 1995 03:48:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA01765; Wed, 10 May 1995 03:47:59 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28475; Wed, 10 May 95 03:47:59 -0700 Received: from shallow.division.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA22503; Wed, 10 May 1995 03:47:53 -0700 Received: from caliban.division.co.uk by shallow.division.co.uk with SMTP id AA05894 (5.65c/IDA-1.4.4 for info-performer@sgi.com); Wed, 10 May 1995 10:45:43 GMT Received: by caliban.division.co.uk (931110.SGI/921111.SGI) for @shallow.division.co.uk:info-performer@sgi.com id AA09853; Wed, 10 May 95 11:50:25 +0100 From: "Angus Dorbie" Message-Id: <9505101150.ZM9851@caliban.division.co.uk> Date: Wed, 10 May 1995 11:50:24 +0100 In-Reply-To: E-Hendon "dynamic terrain" (May 10, 10:37am) References: X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: E-Hendon Subject: Re: dynamic terrain Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > Has anyone looked into the applicablility of Performer for dynamic terrain? > Very intereseted in hearing comments, suggestions etc. Although I've not applied the techniques specifically to terrain, I have found it really simple to implement dynamic geometry in geosets. Basically, the coordinate & other information is held in memory and you are free to write new values for your vertex information to memory. One important choice is what type of geoset you decide to use. If you use indexed geosets then typically each vertex is represented once in a neat list with connectivity information held in an index list. This reduces the bandwidth required to update vertices and makes for a neater implementation. Non indexed geosets can be slightly faster to draw but typically hold multiple copies of each vertex making it trickier to update an individual vertex. Changing connectivity is a different kettle of fish and I've never needed to try this, clearly indexed geosets have further advantages for this type of dynamic update. There's a cute SigGraph 93 paper "Modeling Soil: Realtime Dynamic Models for Soil Slippage and Manipulation" . I noticed that Lance Marrou got an acknowledgement at the end (he mails the group). Maybe he has aquired some 'soil specific' experience with performer. -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.co.uk UK From guest Wed May 10 03:11:20 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA01629; Wed, 10 May 1995 03:00:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA01626; Wed, 10 May 1995 03:00:30 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27873; Wed, 10 May 95 03:00:26 -0700 Received: from bvr.co.il by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA20128; Wed, 10 May 1995 03:00:08 -0700 Received: from amcor.bvr.co.il by bvr.co.il via SMTP (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA03357; Wed, 10 May 95 13:05:54 +0300 Received: by amcor.bvr.co.il (940816.SGI.8.6.9/911001.SGI) id MAA05165; Wed, 10 May 1995 12:57:17 +0300 From: "Ran Yakir" Message-Id: <9505101257.ZM5163@amcor.bvr.co.il> Date: Wed, 10 May 1995 12:57:14 +0000 In-Reply-To: Kathy Loynes "Blurring / Sharpening images in Real Time" (May 9, 5:49pm) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Kathy Loynes Subject: Re: Blurring / Sharpening images in Real Time Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Kathy, A small mistake occured in the source lines I've sent you yesterday. The kernel values for 3X3 should be 1/3 for all 6 entries. The kernel values for 5X5 should be 1/5 for all 10 entries. The kernel values for 7X7 should be 1/7 for all 14 entries. You can get an even nicer defocus effect by not including the center pixel of the convolution in the convolution. This is done by zeroing its coefficients in the kernel. Thus the 3X3 kernel will have the form : float kernel[3] = { 1/2, 0.0, 1/2, 1/2, 0.0, 1/2 }; If you want to add a defocus level to the effect, you can create the kernel on-the-fly, by applying the values 0..1 to the center coefficients, and 1/size..0 to the other coefficients, depending on the blur level. Regards, Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | From guest Wed May 10 06:06:01 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA01884; Wed, 10 May 1995 06:03:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA01881; Wed, 10 May 1995 06:03:38 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00802; Wed, 10 May 95 06:03:37 -0700 Received: from vr1.engin.umich.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA02434; Wed, 10 May 1995 06:03:36 -0700 Received: by vr1.engin.umich.edu (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id JAA25677; Wed, 10 May 1995 09:04:27 -0400 From: falko@vr1.engin.umich.edu (Falko Kuester) Message-Id: <199505101304.JAA25677@vr1.engin.umich.edu> Subject: unsubscribe To: info-performer@sgi.sgi.com Date: Wed, 10 May 1995 09:04:21 -0500 (EDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1485 Status: O Please unsubscribe Thanks falko -- ========================================================================== Falko Kuester _/_/_/_/ _/ _/ _/ _/ _/ Virtual Reality Laboratory _/ _/ _/ University of Michigan _/_/_/ _/_/ NA&ME Building _/ _/ _/ __o 2600 Draper Road _/ _/ _/ _`\<; Ann Arbor MI 48109-2145 _/ _/ _/ _/ _(*)/(*) E-mail: falko@vr1.engin.umich.edu Phone: (313) 763-7798 (voice) Phone: (313) 936-8820 (fax) 764-6689 http://www-name.engin.umich.edu:8001/vr/people/falko/falko.html ========================================================================== ( ) ( ) ( ) ( ) _______ ( ) ( ) | . ~ ~ ~ ~~ . . ~ ~ ~ ~~ . | \_______________________________/`\______________________________/ \_/ o I'd rather be soaring From guest Wed May 10 12:31:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA02995; Wed, 10 May 1995 12:10:37 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA02992; Wed, 10 May 1995 12:10:37 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19403; Wed, 10 May 95 12:10:25 -0700 Received: from relay.iunet.it by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA06038; Wed, 10 May 1995 12:10:15 -0700 Received: from hpdtmt2.UUCP by relay.iunet.it with UUCP id AA11068 (5.65c8/IDA-1.4.4 for info-performer%sgi.com@iunet.it); Wed, 10 May 1995 21:14:39 +0200 Message-Id: <199505101914.AA11068@relay.iunet.it> Received: by hpdtmt2 (16.6/16.2) id AA06842; Wed, 10 May 95 15:44:28 +0200 From: Marco Crocetta Subject: About Transparency To: info-performer@sgi.sgi.com Date: Wed, 10 May 95 15:44:27 METDST Mailer: Elm [revision: 66.25] Status: O Hi, I read in the man pages and also on several mail message in this list that to have a correct rendering of transparent object they must be sorted from back to front (from the farthest to the nearest). My question is: there is someone who could gently explain me this problem and how can I "sort" objects (exactly what it means in practice). And what about sorting if I have both multigen a GL objects in my scene?? Thanks very much in advance -------------------------- Marco Crocetta DATAMAT SpA, Rome e-mail: onyx@datamat.it -------------------------- From guest Wed May 10 09:51:50 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA02134; Wed, 10 May 1995 09:45:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA02131; Wed, 10 May 1995 09:45:58 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09081; Wed, 10 May 95 09:45:56 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA03588; Wed, 10 May 1995 09:45:53 -0700 Received: from crusader.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA04809; Wed, 10 May 95 12:44:20 EDT Received: by crusader.vsl.ist.ucf.edu (940816.SGI.8.6.9) id MAA10741; Wed, 10 May 1995 12:42:21 -0400 Date: Wed, 10 May 1995 12:42:20 -0400 (EDT) From: "Lance R. Marrou" To: Angus Dorbie Cc: E-Hendon , info-performer@sgi.sgi.com, Mark Kilby Subject: Re: dynamic terrain In-Reply-To: <9505101150.ZM9851@caliban.division.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Wed, 10 May 1995, Angus Dorbie wrote: > > Has anyone looked into the applicablility of Performer for dynamic terrain? > > Very intereseted in hearing comments, suggestions etc. One of our major projects is Dynamic Terrain (DT). If you went to the I/ITSEC conference in 1993 and 1994 you might remember the IST Visual Systems Lab booth. We displayed early and current research on dynamic terrain and dynamic fluids. Robert Buckley originally worked on visualizing DT with continuous terrain level of detail in Performer for his Master's Degree thesis and project in Computer Science here at the University of Central Florida. His work, BwanaVision was showed in our booth in 1993 and in the NTSC booth in the same year. Bob reads this group, so maybe he wants to respond. Feel free to check out our web site: http://www.vsl.ist.ucf.edu/~deg for the Digital Environments Group (DT) http://www.vsl.ist.ucf.edu for the VSL DT was funded by the US Army Simulation, Training and Instrumentation Command (STRICOM). > > Although I've not applied the techniques specifically to terrain, I > have found it really simple to implement dynamic geometry in geosets. > > Basically, the coordinate & other information is held in memory and you > are free to write new values for your vertex information to memory. > > One important choice is what type of geoset you decide to use. If you use > indexed geosets then typically each vertex is represented once in a neat > list with connectivity information held in an index list. This reduces > the bandwidth required to update vertices and makes for a neater > implementation. Non indexed geosets can be slightly faster to draw > but typically hold multiple copies of each vertex making it trickier to > update an individual vertex. > > Changing connectivity is a different kettle of fish and I've never needed > to try this, clearly indexed geosets have further advantages for this type > of dynamic update. Indexed geosets is the method Bob used and we are still using it. It is undoubtedly the only real solution for quick updates. Changing connectivity is quite interesting and Bob's solution is great. However, it is based upon our extremely flexible terrain surface model and querying structure. For more information, check out some of the papers on the web site. > > There's a cute SigGraph 93 paper "Modeling Soil: Realtime Dynamic Models > for Soil Slippage and Manipulation" . I noticed that Lance Marrou got an > acknowledgement at the end (he mails the group). Maybe he has aquired some > 'soil specific' experience with performer. > This paper was written by Dr. Li Xin and Dr. Mike Moshell. The paper is based upon Dr. Li's PhD dissertation and research on Dynamic Terrain here at UCF. It is the foundation for our soil modeling. Please check out the web site. There you will find a reference to this paper and others. Postscript versions of some of these papers are readily available through the web (including Li's full dissertation and Jim Chen's on fluid modeling). P.S. If there is any problem obtaining these documents from the web, please contact the web administrator noted on the page. I have tried and it worked great for me, but then I am on the same site :) ______________________________________________________________________________ /\ ______ /\____ ______ ______ E-mail: marrou@vsl.ist.ucf.edu Visual / / / _ / / __ // ____// ____/ VSL: (407)658-5073 Systems / /__ / /_/ / / / / // /___ / __/_ R. Marrou Fax: (407)658-5059 Lab /____//____/\\/_/ /_//_____//_____/ http://www.vsl.ist.ucf.edu/~marrou "Reap the whirlwind." "We don't need no thought control." From guest Wed May 10 10:11:49 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA02157; Wed, 10 May 1995 10:01:24 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA02154; Wed, 10 May 1995 10:01:24 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10103; Wed, 10 May 95 10:01:23 -0700 Received: from mane.cgrg.ohio-state.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA06390; Wed, 10 May 1995 10:01:20 -0700 Received: from stegosaur.cgrg.ohio-state.edu (tmoeller@cgrg.ohio-state.edu) by mane.cgrg.ohio-state.edu (8.6.12/941010.52) with ESMTP id NAA26479 for ; Wed, 10 May 1995 13:01:13 -0400 Received: (from tmoeller) by stegosaur.cgrg.ohio-state.edu (8.6.10/941010) id NAA10450 for info-performer@sgi.com; Wed, 10 May 1995 13:01:13 -0400 From: Torsten Moeller Message-Id: <199505101701.NAA10450@stegosaur.cgrg.ohio-state.edu> Subject: Power ONYX with IRIX 6.0.1 To: info-performer@sgi.sgi.com Date: Wed, 10 May 1995 13:01:12 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 590 Status: O I took perfly and only added one line to perfly.c: WinSizeX = WinSizeY = 800; in initSceneGraph (line 163). Still, if I compile and run this modified perfly on a Power ONYX with 4 R8000 processors under IRIX 6.0.1 it ignores the modified screensize. Running the same code on another machine (Crimson, Indy) everything is fine (i.e. I get a smaller window size). Does anybody know, what is causing this behaviour? Is Performer supposed to work on this kind of platforms at all? Thanks, Torsten. -- Research Assistant ACCAD tmoeller@cgrg.ohio-state.edu Ohio State University From guest Wed May 10 12:37:52 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA03013; Wed, 10 May 1995 12:14:55 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA03010; Wed, 10 May 1995 12:14:47 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19589; Wed, 10 May 95 12:14:42 -0700 Received: from ridgefield.sdr.slb.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA06818; Wed, 10 May 1995 12:14:39 -0700 Received: from hermes.ridgefield.sdr.slb.com by ridgefield.sdr.slb.com (PMDF V4.2-14 #5218) id <01HQCC9ATFLS90XN4U@ridgefield.sdr.slb.com>; Wed, 10 May 1995 15:13:19 EST Received: from luan.slb.com by hermes.ridgefield.sdr.slb.com (4.1/SMI-4.1) id AA12689; Wed, 10 May 95 15:12:22 EDT Date: Wed, 10 May 1995 15:12:22 -0400 (EDT) From: reischer@ridgefield.sdr.slb.com (Andy Reischer) To: info-performer@sgi.sgi.com Message-Id: <9505101912.AA12689@hermes.ridgefield.sdr.slb.com> Content-Transfer-Encoding: 7BIT Status: O Hello... I've made my first performer application. The LOD's work well, exept for the popping(I'm working on an Indy). My problem is that I don't know how to make a movie from it. I have the gallieo board but the dm tools only seem to input from live video not my application window. How do I do this??? Andy Reischer P.S. I need to record to memory/file so i can speed it up to show how the application would work on a faster machine. From guest Wed May 10 18:35:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA05119; Wed, 10 May 1995 18:09:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA05116; Wed, 10 May 1995 18:09:46 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13994; Wed, 10 May 95 18:09:40 -0700 Received: from shallow.division.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA09321; Wed, 10 May 1995 15:38:13 -0700 Received: from caliban.division.co.uk by shallow.division.co.uk with SMTP id AA20969 (5.65c/IDA-1.4.4 for info-performer@sgi.com); Wed, 10 May 1995 22:35:52 GMT Received: by caliban.division.co.uk (931110.SGI/921111.SGI) for @shallow.division.co.uk:info-performer@sgi.com id AA03881; Wed, 10 May 95 23:40:50 +0100 From: "Angus Dorbie" Message-Id: <9505102340.ZM3879@caliban.division.co.uk> Date: Wed, 10 May 1995 23:40:49 +0100 In-Reply-To: Marco Crocetta "About Transparency" (May 10, 3:44pm) References: <199505101914.AA11068@relay.iunet.it> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Marco Crocetta Subject: Re: About Transparency Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > I read in the man pages and also on several mail message > in this list that to have a correct rendering of transparent object > they must be sorted from back to front (from the farthest to the nearest). To determine surface visibility the Z value in the framebuffer the 'destination' pixels is compared with the Z of any incoming pixels being written to because of a polygon surface 'source' pixels. Typically the pixel value whose Z distance is nearest the eye (either 'source' or 'destination') determines what ends up being displayed in the framebuffer. The snag occurs when you write transparent pixels to the framebuffer. If you can imagine a scene where you look through smoked glass, you effectively have a single framebuffer colour, obtained by blending the pixel in the scene beyond the glass with the colour of the glass, you also have a single Z value. Unfortunately these values are derived from two colours and two depth values, both of which are still visible in the scene. First we should consider the problem of rendering this simple scene. If we render the glass first then because of it's nearer Z value it will occlude pixels from polygons beyond it in the scene. We can avoid this by disabling the zbuffer write by the glass, in otherwords it has no Z value and cannot subsequently occlude any polygon pixels. The problem with this solution is that the glass cannot be blended with pixels from subsequently rendered polygons (actually it can but this involves other blendfunctions with their own particular foibles, we'll keep it simple here). The solution which works is to draw the glass last and then everything works without any problems. Performer supports this type of transparency sorting. e.g. pfChanTravMode(Pchan, PFTRAV_CULL , PFCULL_VIEW | PFCULL_SORT); Next we can consider the situation where we've sorted the transparent stuff and we've rendered the scene and the smoked glass correctly, but there is another transparent object in the scene which has been sorted with the smoked glass. If this object is nearer than the smoked glass it will be drawn correctly, but if it is farther away we are back to our original problem; either it is occluded by the glass (glass has Z) or it cannot be partially occluded with the glass (glass has no Z). Previously we solved this problem by drawing transparent objects after opaque objects in the scene, we could occlude the transparent with the opaque and there wasn't a problem. However, here we have to sort transparent objects by Z distance and draw them back to front to produce an accurate scene. Performer doesn't automatically support this kind of transparency sorting. You have to provide it yourself. A quick way to sort your transparent objects is to build them in the scene sorted and attach pre and post draw callbacks to a common parent node to stop them being reshuffled, but this isn't a complete solution (the eye could move!!). Specific situations like alpha keying such as that used when billboarding trees can be greatly improved by culling transparent and/or semi-transparent pixels using ALPHAFUNC and ALPHAREF states. Under many circumstances if the transparent objects are drawn last without sorting they will look reasonable if you ensure the transparent objects don't write to the Z buffer, especially if the alpha values are low, that is what PFTR_NO_OCCLUDE is for. So far we've assumed blendfunction parameters of (BF_SA, BF_MSA) but for layered alpha using the 'destination' alpha value can be of some use in various circumstances when used in conjunction with the equivalent of PFTR_NO_OCCLUDE, but it's slow and isn't a generic solution. Finally there is multisampled transparency, this uses the Reality Engines ability to store more than one colour and one Z value for each pixel to avoid some of the pitfalls of blended transparency. The main problem is that more transparent objects are not visible through more opaque (if you stick with the same mask) and a limited number of transparency values are possible due to the small number of samples per pixel, causing quantisation. -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.co.uk UK From guest Thu May 11 12:22:12 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA06979; Thu, 11 May 1995 11:41:40 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA06976; Thu, 11 May 1995 11:41:39 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21488; Thu, 11 May 95 11:41:31 -0700 Received: from relay3.UU.NET by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA18723; Thu, 11 May 1995 11:41:27 -0700 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQyphi23177; Thu, 11 May 1995 14:41:36 -0400 Received: from multigen.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 11 May 1995 14:41:25 -0400 Received: from MAIL_CENTER (QM 3.0) by multigen.uucp (UMCP\QM 2.0.1) id AA01067; Thu, 11 May 1995 11:39:50 PST Message-Id: <00581.2883037190.1067@multigen.uucp> Organization: MultiGen, Inc. X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 10 May 1995 15:55:01 PST Subject: Re: Power ONYX with IRIX 6.0 Status: O Reply to: RE>Power ONYX with IRIX 6.0.1 Hi Torsten, Channel configuration in perfly is very misleading with several sequences of redundant code and data initialization. I remember that it was the gui initialization code that actually has final say on most things. Have a look in gui.c ... On this one though ... also look at InitSharedMem() and InitPipe() in generic.c. Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: 1-408-261-4118 FX: 1-408-247-4329 EMAIL: multigen!marcus@uunet.UU.NET -------------------------------------- Date: 5/10/95 11:21 AM To: Marcus From: Torsten Moeller >From guest@holodeck.asd.sgi.com Wed May 10 13:48:52 1995 Received: from sgi.sgi.com by relay3.UU.NET with SMTP id QQypdn16634; Wed, 10 May 1995 13:48:52 -0400 Received: from holodeck.asd.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id KAA11854; Wed, 10 May 1995 10:26:16 -0700 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA02157; Wed, 10 May 1995 10:01:24 -0700 Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA02154; Wed, 10 May 1995 10:01:24 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10103; Wed, 10 May 95 10:01:23 -0700 Received: from mane.cgrg.ohio-state.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA06390; Wed, 10 May 1995 10:01:20 -0700 Received: from stegosaur.cgrg.ohio-state.edu (tmoeller@cgrg.ohio-state.edu) by mane.cgrg.ohio-state.edu (8.6.12/941010.52) with ESMTP id NAA26479 for ; Wed, 10 May 1995 13:01:13 -0400 Received: (from tmoeller) by stegosaur.cgrg.ohio-state.edu (8.6.10/941010) id NAA10450 for info-performer@sgi.com; Wed, 10 May 1995 13:01:13 -0400 From: Torsten Moeller Message-Id: <199505101701.NAA10450@stegosaur.cgrg.ohio-state.edu> Subject: Power ONYX with IRIX 6.0.1 To: info-performer@sgi.com Date: Wed, 10 May 1995 13:01:12 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 590 I took perfly and only added one line to perfly.c: WinSizeX = WinSizeY = 800; in initSceneGraph (line 163). Still, if I compile and run this modified perfly on a Power ONYX with 4 R8000 processors under IRIX 6.0.1 it ignores the modified screensize. Running the same code on another machine (Crimson, Indy) everything is fine (i.e. I get a smaller window size). Does anybody know, what is causing this behaviour? Is Performer supposed to work on this kind of platforms at all? Thanks, Torsten. -- Research Assistant ACCAD tmoeller@cgrg.ohio-state.edu Ohio State University From guest Wed May 10 18:16:40 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA05022; Wed, 10 May 1995 17:51:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA05019; Wed, 10 May 1995 17:51:27 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12414; Wed, 10 May 95 17:51:26 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA15169; Wed, 10 May 1995 17:51:15 -0700 Received: (from uucp@localhost) by warrane.connect.com.au with UUCP id KAA00909 (8.6.11/IDA-1.6 for info-performer@sgi.com); Thu, 11 May 1995 10:51:08 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA10281 (5.65c/IDA-1.5 for ); Thu, 11 May 1995 10:34:17 +1000 Received: from homer (homer [8.0.0.44]) by aggro with SMTP id KAA27565 (8.6.12/IDA-1.6 for ); Thu, 11 May 1995 10:36:10 +1000 Received: by homer (5.65) id AA12714; Thu, 11 May 1995 10:36:09 +1000 Date: Thu, 11 May 1995 10:36:09 +1000 (EST) From: Kathy Loynes Subject: bogus pfuSaveImage (??) To: Performer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O >From the Performer FAQ : ------------------------------ Subject: + -50- 1.2 libpfutil pfuSaveImage broken Date: 8 Apr 94 00:00:01 EST The image file generated by pfuSaveImage is bogus. ------------------------------ Could someone explain how it is bogus ? I used pfuSaveImage (on an Onyx RE2) & the resulting image seemed to be fine. By "fine" I mean it looked OK & I could convert it to other formats without a problem.... Is the issue fog ? (I had it disabled). I think there was some discussion about this a while ago. ---------------------------------------------------------------------- Kathy Loynes | Wormald Technology kathyl@wormald.com.au | Advanced Systems Engineering Ph: +61 2 981 0611 | Sydney, Australia From guest Wed May 10 20:41:48 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id UAA05334; Wed, 10 May 1995 20:21:28 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA05331; Wed, 10 May 1995 20:21:27 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19802; Wed, 10 May 95 20:21:23 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id UAA10310; Wed, 10 May 1995 20:21:18 -0700 Received: (from uucp@localhost) by warrane.connect.com.au with UUCP id NAA11868 (8.6.11/IDA-1.6 for info-performer@sgi.com); Thu, 11 May 1995 13:21:10 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA10714 (5.65c/IDA-1.5 for ); Thu, 11 May 1995 12:46:42 +1000 Received: from krusty (krusty [8.0.0.31]) by aggro with SMTP id MAA28032 (8.6.12/IDA-1.6); Thu, 11 May 1995 12:48:34 +1000 Received: by krusty (5.65) id AA30381; Thu, 11 May 1995 12:48:33 +1000 Date: Thu, 11 May 1995 12:48:32 +1000 (EST) From: Robert Webb Subject: pfNodeTravMask calls pfGetGSetBBox??? To: Performer mailing list Cc: Robert Webb Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi all, Every now and then my code core dumps, with a trace something like this (and no I'm not just asking you to find the bug for me!): 0 pfGetGSetBBox(gset = 0x186e9020, box = (nil)) ... 1 pfGSetIsectMask(gset = 0x186e9020, mask = 0, setMode = 48, bitOp = 1) ... 2 pfGeode::setTravMask(long,unsigned long,long,long)(this = 0x186e8dc0, which = 0, mask = 0, setMode = 48, bitOp = 1) ... 3 pfGroup::setTravMask(long,unsigned long,long,long)(this = 0x186e9870, which = 0, mask = 0, setMode = 48, bitOp = 1) ... 4 pfNodeTravMask(_node = 0x186e9870, which = 0, mask = 0, setMode = 48, bitOp = 1) ... > 5 MyFunc(0x435d4c, 0x18c6f750, 0x7053e0, 0x2, 0x1000df74) ... 6 ... The call I have to pfNodeTravMask looks like this: pfNodeTravMask(node, PFTRAV_ISECT, 0x0, PFTRAV_SELF|PFTRAV_DESCEND, PF_SET ); That is, I am trying to turn off all intersection traversal for this node and below. However I can't see why this call should lead Performer to internally call pfGetGSetBBox()? And I especially can't see why Performer would pass it an argument of "box = (nil)", since this is what I believe to be causing the core dump. From the man page: void pfGetGSetBBox(pfGeoSet *gset, pfBox *box); ... pfGetGSetBBox copies the current bounding box into bbox. (I assume 'bbox' refers to the argument just called 'box' - a man-page bug) So from this it seems to make sense that it may core dump if not passed any memory to fill in. I am calling pfNodeTravMask() before any sensible data has been put in the the GeoSets below it, but I don't see why that should matter for this call. I will rearrange my code, but would still like to know why calling pfNodeTravMask() leads to a call to pfGetGSetBBox(.., NULL). Also, when I call pfNodeTravMask() with PFTRAV_SELF|PFTRAV_DESCEND, how is this different from just using PFTRAV_SELF? I believe that when the intersection traversal comes across a node with a mask of 0x0, the node and all it's children are skipped immediately, so why does it matter whether the children's masks are also 0x0 or not (ie why use PFTRAV_DESCEND)? Thanks, Rob. ------------------------------------------------------------------------------ Robert Webb. robertw@wormald.com.au ------------------------------------------------------------------------------ From guest Thu May 11 00:01:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA05525; Wed, 10 May 1995 23:34:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id XAA05522; Wed, 10 May 1995 23:34:56 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24573; Wed, 10 May 95 23:34:56 -0700 Received: from mail0.nk-exa.co.jp by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id XAA26486; Wed, 10 May 1995 23:34:44 -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 PAA27229; Thu, 11 May 1995 15:34:37 +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.3W-EXA03) with ESMTP id PAA18677 for ; Thu, 11 May 1995 15:34:36 +0900 Received: from dimwit.dst.nk-exa.co.jp by exagw.nk-exa.co.jp (8.6.9+2.4W/3.3W9/1.6) with SMTP id PAA10260; Thu, 11 May 1995 15:33:58 +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 AA03560; Thu, 11 May 95 15:35:55 +0900 To: info-performer@sgi.sgi.com Subject: perfly using glx Date: Thu, 11 May 1995 15:35:47 +0900 Message-Id: <3559.800174147@dimwit.dst.nk-exa.co.jp> From: Masahiko Yamanaka Status: O Excuse me, Does anyone have the perfly with GLX ? If there is a free source, I'd like to get it. Thanks, -- M.Y. From guest Thu May 11 00:53:29 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA05662; Thu, 11 May 1995 00:22:00 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA05653; Thu, 11 May 1995 00:21:56 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26480; Thu, 11 May 95 00:21:47 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id AAA29550; Thu, 11 May 1995 00:21:45 -0700 Received: from sgiger.munich.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id AAA07262; Thu, 11 May 1995 00:21:40 -0700 Received: from sgihan.hannover.sgi.com by sgiger.munich.sgi.com via SMTP (911016.SGI/911001.SGI) for info-performer@sgi.sgi.com id AA06401; Thu, 11 May 95 09:21:20 +0200 Received: from elwood.hannover.sgi.com by sgihan.hannover.sgi.com via ESMTP (940816.SGI.8.6.9/930416.SGI) id JAA03522; Thu, 11 May 1995 09:18:02 +0200 Received: by elwood.hannover.sgi.com (940816.SGI.8.6.9/930416.SGI) id JAA24063; Thu, 11 May 1995 09:18:00 +0200 From: "Axel Sammet" Message-Id: <9505110917.ZM24061@elwood.hannover.sgi.com> Date: Thu, 11 May 1995 09:17:59 +0000 In-Reply-To: reischer@ridgefield.sdr.slb.com (Andy Reischer) "" (May 10, 15:12) References: <9505101912.AA12689@hermes.ridgefield.sdr.slb.com> X-Face: %BF3$'?$)#p&@-.1*c72Cz/H4?x1i3iBWMbb1#mz6NKfMb}-Lv@@1dqU#3Yb@PTVm@ui#]@ 2]L/vOL[CZ{*FbsNs=gbZ8S-oJb7|0;.Os~S3nDH@CUZQ]J*XyqX ZSz.YX}_v_j>@YVxsy5Tbpg$+_@;T8jTK9xueFT}Q5x1*"+gz0 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: reischer@ridgefield.sdr.slb.com (Andy Reischer) Cc: info-performer@sgi.sgi.com Subject: RE: make a movie from a Performer APP Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On May 10, 15:12, Andy Reischer wrote: Hi Andy, This seems to be a Video- rather than a Performer- related problem. I believe you would like to record every frame to videotape to replay it at a higher frame rate. Using an Indy/Indigo2 you have at least four choices: a) Video Board & Cosmo Compress & Simple Video Recorder b) Video Board & Frame Acurate Video Recorder c) Harddisk Recorder d) Local movie Solution a) and c) would require storing the frames rendered by your application on disk and recording them in realtime(25/30 frames/sec) to the recorder afterwards. The length of the sequence, however, is limited by the available disk space. Solution b) would be able to store an infinit number of frame since nothing is placed on disk. Dependent on the size of your application window you would also have to take into concern a resizing of the frame to match the video resolution. Solution d) would load all the frames to memory and loop/swing through them at the rate you need. This would require quite a large amount of free physical memory dependent on the length and resolution of the sequence. Of course there are a bunch of other things to watch out for, so let me know the exact configuration you are using. Hope this helps. Axel > Subject: > Hello... > > I've made my first performer application. The LOD's work well, exept for the > popping(I'm working on an Indy). My problem is that I don't know how to make a > movie from it. I have the gallieo board but the dm tools only seem to input > from live video not my application window. How do I do this??? > > Andy Reischer > > P.S. I need to record to memory/file so i can speed it up to show how the > application would work on a faster machine. > >-- End of excerpt from Andy Reischer -- ______________________________________________________________________ _/_/_/_/_/ _/_/_/_/_/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/_/ _/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/_/ _/_/_/_/_/ _/ Axel Sammet, SE Visual Simulation, Digital Media, CAD/CAM Silicon Graphics GmbH | Tel: +49 511 9017229 Ahrensburger Strasse 3 | Fax: +49 511 6138115 30659 Hannover | VM #: 59191 M/S: IHA-314 Germany | E-Mail: axel@hannover.sgi.com ______________________________________________________________________ From guest Thu May 11 03:03:37 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA06059; Thu, 11 May 1995 02:34:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA06056; Thu, 11 May 1995 02:34:31 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29625; Thu, 11 May 95 02:34:30 -0700 Received: from relay1.oleane.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA06593; Thu, 11 May 1995 02:34:22 -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 LAA24716; Thu, 11 May 1995 11:33:35 +0200 Message-Id: <199505110933.LAA24716@relay1.oleane.net> X-Sender: csf2@pobox.oleane.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 May 1995 11:15:31 +0000 To: "John A. Collier" From: arnaud@pobox.oleane.com (Remi Arnaud) Subject: Re: Specular Reflection Cc: info-performer@sgi.sgi.com X-Mailer: Status: O >Hi All, > >The current maximum shininess is 128.0 and gives a bit too large a diameter of >a reflection. Is there any way to shrink the reflection smaller. > >The application we are using this for is specular reflection in the IR. We can >calculate what exitance (color) and want hardware to calculate which facets to >illuminate. The problem is that the reflection angle is too big even at the >maximum shininess (128.0) setting. > >Any suggestions? > >Thanks, >John > >-- >John A. Collier e-mail: jcollier@mtl.com >MTL Systems, Inc. voice: (513) 426-3111 >3481 Dayton-Xenia Rd. fax: (513) 426-8301 >Dayton, OH 45432-2796 > > > The problem is coming from the fact that maximum specular rendering (with a value of 128) is done by doing gouraud shading with the near vertices of the vertex which is the most illuminated. So if you have a rough tessellation of your shape, even with a shininess of 128, the reflection on your shape will be too large. Try to tessellate your shape more precisely if you can. Of course, this will have a cost on the number of faces to be rendered, but you get nothing for nothing. Philippe Poutignat Thomson Training & Simulation SA ZA Les Boutries 78703 Conflans Sainte Honorine FRANCE From guest Thu May 11 06:54:39 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA06257; Thu, 11 May 1995 06:47:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA06254; Thu, 11 May 1995 06:47:21 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04472; Thu, 11 May 95 06:47:20 -0700 Received: from relay1.fnet.fr by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA22433; Thu, 11 May 1995 06:47:16 -0700 Received: from matrasp.UUCP by relay1.fnet.fr (5.65c8d/92.02.29) via Fnet/EUnet-France id AA18833; Thu, 11 May 1995 15:47:11 +0200 (MET) Received: from BAROCO.matra-espace.fr by matrasp.matra-espace.fr, Thu, 11 May 95 15:30:42 +0200 Received: by BAROCO.matra-espace.fr, Thu, 11 May 95 15:25:34 +0200 Date: Thu, 11 May 95 15:25:34 +0200 From: maurel@BAROCO.matra-espace.fr (Herve Maurel) Message-Id: <9505111325.AA15236@BAROCO.matra-espace.fr> To: info-performer@sgi.sgi.com Subject: Performer & gnu compiler Status: O Has anyone compiled Performer application with a gnu c compiler. I develop a Performer based application which will be integrated with parts of software compiled with a gnu c. I 'd like to know if compiling my performer based processes with a gnu c we can encounter troubles at runtime. Many thanks in advance for any informations. --------------------------------------------------- Herve Maurel maurel@baroco.matra-espace.fr From guest Thu May 11 06:54:24 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA06262; Thu, 11 May 1995 06:47:24 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA06259; Thu, 11 May 1995 06:47:23 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04478; Thu, 11 May 95 06:47:23 -0700 Received: from relay1.fnet.fr by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA22440; Thu, 11 May 1995 06:47:17 -0700 Received: from matrasp.UUCP by relay1.fnet.fr (5.65c8d/92.02.29) via Fnet/EUnet-France id AA18837; Thu, 11 May 1995 15:47:14 +0200 (MET) Received: from BAROCO.matra-espace.fr by matrasp.matra-espace.fr, Thu, 11 May 95 15:31:07 +0200 Received: by BAROCO.matra-espace.fr, Thu, 11 May 95 15:25:59 +0200 Date: Thu, 11 May 95 15:25:59 +0200 From: maurel@BAROCO.matra-espace.fr (Herve Maurel) Message-Id: <9505111325.AA15240@BAROCO.matra-espace.fr> To: info-performer@sgi.sgi.com Subject: Performer & gnu compiler Status: O Has anyone compiled Performer application with a gnu c compiler. I develop a Performer based application which will be integrated with parts of software compiled with a gnu c. I 'd like to know if compiling my performer based processes with a gnu c we can encounter troubles at runtime. Many thanks in advance for any informations. --------------------------------------------------- Herve Maurel maurel@baroco.matra-espace.fr From guest Thu May 11 06:53:53 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA06267; Thu, 11 May 1995 06:47:26 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA06264; Thu, 11 May 1995 06:47:25 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04482; Thu, 11 May 95 06:47:25 -0700 Received: from relay1.fnet.fr by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA22444; Thu, 11 May 1995 06:47:20 -0700 Received: from matrasp.UUCP by relay1.fnet.fr (5.65c8d/92.02.29) via Fnet/EUnet-France id AA18841; Thu, 11 May 1995 15:47:16 +0200 (MET) Received: from BAROCO.matra-espace.fr by matrasp.matra-espace.fr, Thu, 11 May 95 15:31:24 +0200 Received: by BAROCO.matra-espace.fr, Thu, 11 May 95 15:26:16 +0200 Date: Thu, 11 May 95 15:26:16 +0200 From: maurel@BAROCO.matra-espace.fr (Herve Maurel) Message-Id: <9505111326.AA15244@BAROCO.matra-espace.fr> To: info-performer@sgi.sgi.com Subject: gnu compiler Status: O Has anyone compiled Performer application with a gnu c compiler. I develop a Performer based application which will be integrated with parts of software compiled with a gnu c. I 'd like to know if compiling my performer based processes with a gnu c we can encounter troubles at runtime. Many thanks in advance for any informations. --------------------------------------------------- Herve Maurel maurel@baroco.matra-espace.fr From guest Thu May 11 06:54:17 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA06272; Thu, 11 May 1995 06:47:30 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA06269; Thu, 11 May 1995 06:47:30 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04488; Thu, 11 May 95 06:47:29 -0700 Received: from relay1.fnet.fr by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA22452; Thu, 11 May 1995 06:47:25 -0700 Received: from matrasp.UUCP by relay1.fnet.fr (5.65c8d/92.02.29) via Fnet/EUnet-France id AA18845; Thu, 11 May 1995 15:47:19 +0200 (MET) Received: from BAROCO.matra-espace.fr by matrasp.matra-espace.fr, Thu, 11 May 95 15:31:54 +0200 Received: by BAROCO.matra-espace.fr, Thu, 11 May 95 15:26:46 +0200 Date: Thu, 11 May 95 15:26:46 +0200 From: maurel@BAROCO.matra-espace.fr (Herve Maurel) Message-Id: <9505111326.AA15248@BAROCO.matra-espace.fr> To: info-performer@sgi.sgi.com Subject: gnu compiler Status: O Has anyone compiled Performer application with a gnu c compiler. I develop a Performer based application which will be integrated with parts of software compiled with a gnu c. I 'd like to know if compiling my performer based processes with a gnu c we can encounter troubles at runtime. Many thanks in advance for any informations. --------------------------------------------------- Herve Maurel maurel@baroco.matra-espace.fr From guest Thu May 11 07:32:55 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA06372; Thu, 11 May 1995 07:30:39 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA06369; Thu, 11 May 1995 07:30:38 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05777; Thu, 11 May 95 07:30:37 -0700 Received: from relay.iunet.it by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA27301; Thu, 11 May 1995 07:30:19 -0700 Received: from hpdtmt2.UUCP by relay.iunet.it with UUCP id AA26979 (5.65c8/IDA-1.4.4 for info-performer%sgi.com@iunet.it); Thu, 11 May 1995 16:34:56 +0200 Message-Id: <199505111434.AA26979@relay.iunet.it> Received: by hpdtmt2 (16.6/16.2) id AA08831; Thu, 11 May 95 13:52:41 +0200 From: Marco Crocetta Subject: More about transparency To: angus@division.co.uk Date: Thu, 11 May 95 13:52:41 METDST Cc: info-performer@sgi.sgi.com Mailer: Elm [revision: 66.25] Status: O > On May 10, 11:40pm, Angus Dorbie wrote: > > Subject: Re: About Transparency > > > You have to provide it yourself. A quick way to > sort your transparent objects is to build them in the scene sorted and > attach pre and post draw callbacks to a common parent node to stop them > being reshuffled, >-- End of excerpt from Angus Dorbie First, thanks for your good explanation and I'sorry if I take a little more of your time: my question is how can I "...build them sorted in the scene" ? In other words can I build the scene graph attaching nodes in a depth sorted order? I was not able to find anything about this in the man pages, do I have to go through them deeply? Thanks very much ---------------------------- MARCO CROCETTA DATAMAT SpA, Rome e-mail: onyx@datamat.it ---------------------------- From guest Thu May 11 07:47:22 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA06454; Thu, 11 May 1995 07:44:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA06451; Thu, 11 May 1995 07:44:43 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06291; Thu, 11 May 95 07:44:42 -0700 Received: from shallow.division.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id HAA29456; Thu, 11 May 1995 07:44:01 -0700 Received: from caliban.division.co.uk by shallow.division.co.uk with SMTP id AA23162 (5.65c/IDA-1.4.4 for info-performer@sgi.com); Thu, 11 May 1995 14:41:18 GMT Received: by caliban.division.co.uk (931110.SGI/921111.SGI) for @shallow.division.co.uk:info-performer@sgi.com id AA04867; Thu, 11 May 95 15:46:33 +0100 From: "Angus Dorbie" Message-Id: <9505111546.ZM4865@caliban.division.co.uk> Date: Thu, 11 May 1995 15:46:33 +0100 In-Reply-To: Marco Crocetta "More about transparency" (May 11, 1:52pm) References: <199505111434.AA26973@relay.iunet.it> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Marco Crocetta Subject: Re: More about transparency Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > In other words can I build the scene graph attaching nodes in a depth sorted > order? Yes, that's it, add them to a common parent in distant to near order, and add draw callbacks to the parent. This is a quick and horrid fix, not a recommended solution. -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.co.uk UK From guest Thu May 11 10:13:14 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA06791; Thu, 11 May 1995 10:07:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA06788; Thu, 11 May 1995 10:07:58 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14715; Thu, 11 May 95 10:07:56 -0700 Received: from ctaeng.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA27417; Thu, 11 May 1995 10:07:53 -0700 Received: from support.ctaeng.com by ctaeng.com (4.1/SMI-4.1) id AA13341; Thu, 11 May 95 11:07:50 MDT Received: from getreal.mss.ctaeng.com by support.ctaeng.com (5.0/SMI-SVR4) id AA06244; Thu, 11 May 1995 11:07:45 -0600 Received: by getreal.mss.ctaeng.com (931110.SGI/920502.SGI.AUTO) for @support.ctaeng.com:elke@tyrann.atlas.de id AA14316; Thu, 11 May 95 11:08:42 -0600 From: "`Bwana' Bob Buckley" Message-Id: <9505111108.ZM14314@getreal.mss.ctaeng.com> Date: Thu, 11 May 1995 11:08:37 -0600 In-Reply-To: "Angus Dorbie" "Re: dynamic terrain" (May 10, 11:50am) References: <9505101150.ZM9851@caliban.division.co.uk> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: dynamic terrain Cc: angus@division.co.uk, elke@tyrann.atlas.de, bbuckley@ctaeng.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 3901 Status: O > > > Has anyone looked into the applicablility of Performer for dynamic terrain? > > Very intereseted in hearing comments, suggestions etc. > > Although I've not applied the techniques specifically to terrain, I > have found it really simple to implement dynamic geometry in geosets. > > Basically, the coordinate & other information is held in memory and you > are free to write new values for your vertex information to memory. > However, when multiprocessing you MUST multi-buffer your pfGeoSet data. When updating vertex, normal, and texture coordinates in the app process you don't want the draw process to render in the midst of an update. We just spawned a separate rebuilding process and let the visuals continue to run typically at 60Hz. > > One important choice is what type of geoset you decide to use. If you use > indexed geosets then typically each vertex is represented once in a neat > list with connectivity information held in an index list. This reduces > the bandwidth required to update vertices and makes for a neater > implementation. Non indexed geosets can be slightly faster to draw > but typically hold multiple copies of each vertex making it trickier to > update an individual vertex. > When performing Continuous Terrain Level of Detail it allowed for very efficent seamless updates. Actually very little updates and more of data movement in memory (pfGeoSets were dynamic in their location). When dealing with the Dynamic Terrain it made no difference due to the fact that we would build the effected areas from scratch on the fly. The updating being done was not on a per vertex basis but rather on a group of verticies at a time. So we kept the non-indexed method to ensure the whole terrain surface was t-meshed and updating was efficient and easy. > > Changing connectivity is a different kettle of fish and I've never needed > to try this, clearly indexed geosets have further advantages for this type > of dynamic update. In my Masters Thesis we ran up against this and the chronology of how we dealt with it is documented. Lance mentioned that it and a number of supporting/related documents are avaialble at IST's Web Site at http://www.vsl.ist.ucf.edu/~deg, the Digital Environments Group (DT). > > There's a cute SigGraph 93 paper "Modeling Soil: Realtime Dynamic Models > for Soil Slippage and Manipulation" . I noticed that Lance Marrou got an > acknowledgement at the end (he mails the group). Maybe he has aquired some > 'soil specific' experience with performer. > I'm not so sure I'd quantify a paper of this complexity (with real-time working model) as 'cute'. It's not the easiest thing to get a paper into SIGGRAPH nor get your Ph.D. We built this capability as an OOPs object and were very successful at using it in other applications by just inserting two calls. One thing that we did not address at the time was a blending effect when 'morphing' one terrain topology to the next. A higher resolution soil model could have been used to smooth the terrain transitions or a geometry morphing algorithm could have been used. I believe that a new pfMorph type construct in Performer V2.0 is really going to assist in Dynamic Terrain as well as a new and improved technique of dealing with LODs in general. The Performer group might be looking at creating more capabilities in the dynamic geometry area. Elke, just yell if you have any questions. =========================================================================== 'Bwana' Bob Buckley CTA, Inc. Sr. Software Engineer 5670 Greenwood Plaza Blvd Visual Systems Englewood, CO 80111 (303) 889-1207 (303) 889-1200 bbuckley@ctaeng.com (303) 889-1398 Fax =========================================================================== From guest Thu May 11 13:34:19 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA07393; Thu, 11 May 1995 13:15:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA07390; Thu, 11 May 1995 13:15:10 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26358; Thu, 11 May 95 13:15:05 -0700 Received: from taurus.cs.nps.navy.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA07654; Thu, 11 May 1995 13:15:03 -0700 Received: from cool.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA08021; Thu, 11 May 95 13:14:52 PDT Received: by cool.cs.nps.navy.mil (950215.SGI.8.6.10/940406.SGI) for info-performer@sgi.com id NAA06970; Thu, 11 May 1995 13:14:41 -0700 From: mcmillan@cool.cs.nps.navy.mil (Scott McMillan) Message-Id: <199505112014.NAA06970@cool.cs.nps.navy.mil> Subject: "blinking" objects on Indigo 2 To: info-performer@sgi.sgi.com Date: Thu, 11 May 1995 13:14:41 -0700 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1669 Status: O I am developing an application that needs to run on both RE's and EXtremes. I need to load in .flt models that have transparent portions -- like a tree texture mapped to the surface of square polygons so that any portion of the polygon outside the outline of the tree is invisible. Anyway to get the desired performance I want to turn texturing off on the EXtreme. When I do that all of these objects start to blink on and off erratically and sometimes they never show up. Below is what I have in the drawChannel() function before the call to pfDraw(): if (G_shared->reality_engine) { // flag set if machine is RE pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, 0); pfEnable(PFEN_TEXTURE); pfEnable(PFEN_LIGHTING); } else { pfDisable(PFEN_TEXTURE); pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, 1); // This is something I have to do for an Indigo2 Extreme to get // objects with alpha planes to stop blinking. pfOverride(PFSTATE_TRANSPARENCY, PF_OFF); pfTransparency(PFTR_ON); pfOverride(PFSTATE_TRANSPARENCY, PF_ON); } The last three lines are what I had to add to get it to behave properly. My questions are (1) can anyone explain what was happening to cause the blinking in the first place and (2) is this the correct (read most computationally efficient) way to overcome it? Thanks in advance, scott -- Scott McMillan, Ph.D. (408) 656-3316 mcmillan@cs.nps.navy.mil URL: http://cs.nps.navy.mil/people/faculty/mcmillan/ Dept. of Computer Science/Naval Postgraduate School/Monterey, CA 93943 "Manuals! Manuals!! We don't need no stinkin' manuals!" From guest Thu May 11 13:53:33 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA07534; Thu, 11 May 1995 13:36:08 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA07531; Thu, 11 May 1995 13:36:07 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27403; Thu, 11 May 95 13:36:06 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id NAA11669; Thu, 11 May 1995 13:36:04 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id NAA26930; Thu, 11 May 1995 13:35:59 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:angus@division.co.uk id AA27369; Thu, 11 May 95 13:35:36 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA17624; Thu, 11 May 1995 13:35:32 -0700 Message-Id: <199505112035.NAA17624@surreal.asd.sgi.com> To: "Angus Dorbie" Cc: Marco Crocetta , info-performer@sgi.sgi.com Subject: Re: About Transparency In-Reply-To: Your message of "Wed, 10 May 95 23:40:49 BST." <9505102340.ZM3879@caliban.division.co.uk> Date: Thu, 11 May 95 13:35:31 -0700 From: Jim Helman Status: O Most of our Onyx customers use multisample transparency, and so depth sorting is not required, and those that need higher quality blending get by with Performer's default mode of drawing transparent geometry last. But those apps that need to use blended transparency and have multiple layers of transparent objects are in a difficult position. So we hope to get depth sorting of transparent geometry into 2.0. If you're in a real pinch, 1.2 has an undocumented feature that allows billboards to be depth sorted. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu May 11 15:27:45 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA08190; Thu, 11 May 1995 15:06:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA08187; Thu, 11 May 1995 15:06:27 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02709; Thu, 11 May 95 15:06:26 -0700 Received: from netcom.netcom.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA04018; Thu, 11 May 1995 15:06:24 -0700 Received: by netcom.netcom.com (8.6.12/Netcom) id OAA15200; Thu, 11 May 1995 14:43:12 -0700 From: watsen@netcom.com (Kent Watsen) Message-Id: <199505112143.OAA15200@netcom.netcom.com> Subject: OpenGL in GLX Window with Performer 1.2? To: info-performer@sgi.sgi.com (performer) Date: Thu, 11 May 1995 14:43:07 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 435 Status: O Hello all, Is it possible to render OpenGL code into an GLX window from within a Performer 1.2 application. I have tried to hack xwin.c from ligpfutil by adding the appropriate (I think) calls for glXCreateContext and glXMakeCurrent but I keep getting the runtime error : GL: Error: can't connect to /dev/opengl I could wait for Performer 2.0, but I'd like to port as little code to OpenGL as possible. Thanks! Kent Watsen From guest Thu May 11 15:51:42 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA08359; Thu, 11 May 1995 15:27:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA08356; Thu, 11 May 1995 15:27:11 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04031; Thu, 11 May 95 15:26:58 -0700 Received: from Starbase.NeoSoft.COM by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA09962; Thu, 11 May 1995 15:26:56 -0700 Received: (from dweller@localhost) by Starbase.NeoSoft.COM (8.6.10/8.6.10) id RAA01484; Thu, 11 May 1995 17:26:48 -0500 From: David Weller Message-Id: <199505112226.RAA01484@Starbase.NeoSoft.COM> X-Provider: NeoSoft, Inc.: Internet Service Provider (713) 968-5800 Subject: Re: Performer & gnu compiler To: maurel@BAROCO.matra-espace.fr (Herve Maurel) Date: Thu, 11 May 1995 17:26:48 -0500 (CDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <9505111325.AA15236@BAROCO.matra-espace.fr> from "Herve Maurel" at May 11, 95 03:25:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 238 Status: O > Has anyone compiled Performer application with a gnu c > compiler. > This is an obtuse answer, but the GNU Ada95 compiler works with Performer. Now, the GNU Ada95 compiler uses the GNU gcc backend. Ergo.... The answer is, "Yes" :-) From guest Thu May 11 17:02:38 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA08822; Thu, 11 May 1995 16:46:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA08819; Thu, 11 May 1995 16:46:15 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08782; Thu, 11 May 95 16:46:14 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA24651; Thu, 11 May 1995 16:46:12 -0700 Received: from hawkeye.newport.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id QAA12730; Thu, 11 May 1995 16:46:08 -0700 Received: by hawkeye.newport.sgi.com (950215.SGI.8.6.10/911001.SGI) id QAA09782; Thu, 11 May 1995 16:46:01 -0700 From: millard@hawkeye.newport.sgi.com (Ed Millard) Message-Id: <199505112346.QAA09782@hawkeye.newport.sgi.com> Subject: Re: OpenGL in GLX Window with Performer 1.2? To: watsen@netcom.com (Kent Watsen) Date: Thu, 11 May 1995 16:46:01 -0800 (PDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <199505112143.OAA15200@netcom.netcom.com> from "Kent Watsen" at May 11, 95 02:43:07 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1161 Status: O > > > Hello all, > > Is it possible to render OpenGL code into an GLX window > from within a Performer 1.2 application. I have tried > to hack xwin.c from ligpfutil by adding the appropriate > (I think) calls for glXCreateContext and glXMakeCurrent > but I keep getting the runtime error : > > GL: Error: can't connect to /dev/opengl > > I could wait for Performer 2.0, but I'd like to port as > little code to OpenGL as possible. > You cant mix OpenGl and IrisGL in the same app or the same window. There are all kinds of collisions in symbols and contexts. So you would have to fork a different process and render to a different window to use OpenGL with Performer 1.2. Probably better to just wait for Performer 2.0. You can write IrisGL code now and run it through the 4Dgifts toogl translator which translates IrisGL source to OpenGL . This presumes your using C and that your willing to do a little cleanup work after the translation. If your not mixing IrisGL and OpenGL and you get this error message it usually means you have prbolems in your /dev directory or your trying to run OpenGL on a machine that doesn't support OpenGL. -- Ed From guest Thu May 11 21:44:35 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA09780; Thu, 11 May 1995 21:19:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA09777; Thu, 11 May 1995 21:19:34 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19929; Thu, 11 May 95 21:19:33 -0700 Received: from tcsernet.tcs.ernet.in by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id VAA03944; Thu, 11 May 1995 21:19:27 -0700 From: sundar@tcsernet.tcs.ernet.in Message-Id: <9505120953.AA18545@tcsernet.tcs.ernet.in> Subject: Unsubscribe To: info-performer@sgi.sgi.com Date: Fri, 12 May 95 9:52:56 EDT Content-Length: 89 Content-Type: text X-Mailer: ELM [version 2.3 PL2] Status: O Please Unsubscribe me from Performer Mailing list e-mail: sundar@tcsernet.tcs.ernet.in From guest Fri May 12 10:40:24 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA11722; Fri, 12 May 1995 10:12:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA11719; Fri, 12 May 1995 10:12:21 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06029; Fri, 12 May 95 10:12:21 -0700 Received: from gate.ti.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA18277; Fri, 12 May 1995 10:12:16 -0700 Received: from tilde.csc.ti.com ([128.247.160.56]) by gate.ti.com (8.6.10/) with ESMTP id MAA08196 for ; Fri, 12 May 1995 12:12:15 -0500 Received: from rts.dseg.ti.com (m2.dseg.ti.com [128.247.216.212]) by tilde.csc.ti.com (8.6.11/8.6.11) with SMTP id MAA03462 for ; Fri, 12 May 1995 12:11:44 -0500 Received: by rts.dseg.ti.com (4.1/SMI-4.1) id AA27182; Fri, 12 May 95 12:14:08 CDT Date: Fri, 12 May 95 12:14:08 CDT From: tpravata@rts.dseg.ti.com (Todd R Pravata) Message-Id: <9505121714.AA27182@rts.dseg.ti.com> To: info-performer@sgi.sgi.com Subject: pfLayer polygons and the clipping plane Reply-To: Status: O My loader uses pfLayer for the network (roads, rivers, etc.) polygons in the scene. The underlying terrain forms the base and the roads are decaled on top. Note the database is "tiled". The terrain and network polygons for each 1K tile are placed in a single pfLayer node for that tile. The network polygons are clipped to the tile boundary. I've noticed that the decaled polygons at the far clipping plane make the cull before the base layer. So when there is a hill in the distance coming into view with a road on it, first the roads stick up with no terrain underneath, then the terrain comes in. Is this a problem with bounding spheres? Do I need to force the bounding spheres of the base and decal layer geometry to be the same? Or is there something else going on here? -- Todd R. Pravata INTERNET: todd.pravata@dseg.ti.com Texas Instruments, Inc. VAX MAIL: MCOPN3::PRAVATA P.O.Box 869305, MS 8518 TI MSGID: TPRA Plano, Texas, 75086 VOICE: (214)575-6126 FAX: (214)575-6771 -- My views are my own and are not necessarily those of Texas Instruments. -- From guest Fri May 12 14:20:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA12305; Fri, 12 May 1995 13:51:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA12302; Fri, 12 May 1995 13:51:46 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18273; Fri, 12 May 95 13:51:37 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id NAA02576; Fri, 12 May 1995 13:51:35 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id NAA09031; Fri, 12 May 1995 13:51:31 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:robertw@wormald.com.au id AA18261; Fri, 12 May 95 13:51:09 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA24773; Fri, 12 May 1995 13:51:08 -0700 Message-Id: <199505122051.NAA24773@surreal.asd.sgi.com> To: Robert Webb Cc: Performer mailing list Subject: Re: pfNodeTravMask calls pfGetGSetBBox??? In-Reply-To: Your message of "Thu, 11 May 95 12:48:32 +1000." Date: Fri, 12 May 95 13:51:00 -0700 From: Jim Helman Status: O pfGetGSetBBox(..., NULL) is supposed to cause a recomputation of the pfGeoSet bounding box, instead it core dumps. This is is a bug, which I've just fixed. So no problem in 2.0. As for why it was invoked: pfGSetISectMask was doing a clean of the pfGeoSet's dirty attributes. In 1.2, when you change a pfGeoSet attribute, the bounding box is marked dirty, with the updating done at will thereafter. We can't recompute the bounding box whenever an attribute changes, because we don't know if the data are valid yet In the absence of a pfOKThisGSetIsDone() API, we implicitly make the assumption that the pfGeoSet is self-consistent (i.e. either empty or fully set up) when something other than an attribute set/get is done. We could defer the "clean" to the first cull or isect traversal, but this would require locks and would add non- determinism, since the first time the object is "touched" would be considerably more expensive. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri May 12 14:28:58 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA12329; Fri, 12 May 1995 13:58:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA12326; Fri, 12 May 1995 13:58:56 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18576; Fri, 12 May 95 13:58:50 -0700 Received: from vector.rickb.digex.net by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA04105; Fri, 12 May 1995 13:58:46 -0700 Received: from [10.1.0.2] (quadrant.rickb.digex.net [10.1.0.2]) by vector.rickb.digex.net (8.6.9/8.6.9) with SMTP id QAA00997 for ; Fri, 12 May 1995 16:56:54 -0400 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 May 1995 17:02:46 -0400 To: info-performer@sgi.sgi.com From: rickb@access.digex.net (Frederick E. Brown) Subject: Performer vs. OpenGVS Status: O Does anyone have experience with both Performer and OpenGVS. Since both seem to do roughly the same thing as a Vis-Sim API, I was wondering what the tradeoffs of each are. Obviously, OpenGVS is *much* more expensive ($12,000 commercial, and $4,000 educational). The neat thing about GVS is that it supports the new and totally cool sounding Real3D-Pro/1000 box which will supposedly blow a single-piped RE2 Onyx away. Plus GVS's cross-platform support for NT is a nice bonus. Comments? rickb@access.digex.net From guest Sun May 14 08:30:13 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA16868; Sun, 14 May 1995 08:20:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA16865; Sun, 14 May 1995 08:20:27 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03061; Sun, 14 May 95 08:20:22 -0700 Received: from mail02.mail.aol.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA27630; Sun, 14 May 1995 08:20:20 -0700 From: IBCONDOR@aol.com Received: by mail02.mail.aol.com (1.37.109.11/16.2) id AA152804819; Sun, 14 May 1995 11:20:19 -0400 Date: Sun, 14 May 1995 11:20:19 -0400 Message-Id: <950514112019_118207273@aol.com> To: info-performer@sgi.sgi.com Subject: Position -MD - Virtual Sys Eng Status: O SEMCOR Inc, an International Systems Engineering Corporation has exceptional opportunities for engineers and computer scientists to participate in defining the Navy's next generation of carrier based tactical aircraft. We seek professionals with the following disciplines: VIRTUAL SYSTEMS ENGINEERING - Experience with Unix, C, prototyping tools (Corypheaus, VPI), SGI, model building, real-time processing, and computer hardware interface and optimization. Candidates must possess a minimum BSEE/CS (an advanced degree is preferred) with 3 years related experience. An excellent compensation package is offered. Southern Maryland location. Respond to IBCONDOR@AOL.COM From guest Sun May 14 17:55:12 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA17459; Sun, 14 May 1995 17:52:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA17456; Sun, 14 May 1995 17:52:44 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13515; Sun, 14 May 95 17:52:43 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA22896; Sun, 14 May 1995 17:52:20 -0700 Received: (from uucp@localhost) by warrane.connect.com.au with UUCP id KAA04895 (8.6.11/IDA-1.6 for info-performer@sgi.com); Mon, 15 May 1995 10:50:52 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA03643 (5.65c/IDA-1.5 for ); Mon, 15 May 1995 10:36:54 +1000 Received: from krusty (krusty [8.0.0.31]) by aggro with SMTP id KAA04766 (8.6.12/IDA-1.6 for ); Mon, 15 May 1995 10:39:02 +1000 Received: by krusty (5.65) id AA09759; Mon, 15 May 1995 10:39:01 +1000 Date: Mon, 15 May 1995 10:39:00 +1000 (AEST) From: Troy Stephen Sender: Troy Stephen Reply-To: Troy Stephen Subject: Where is the sky polygon? To: Performer Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-992262046-800498340:#18062" Status: O This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-992262046-800498340:#18062 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi all, I've been attempting to add a sun and moon to our visual simulation. I have been using point rotating billboards and positioning them just inside the far clip plane. Everything works great when my Earth-Sky mode is set to PFES_FAST. However, when using PFES_SKY_GRND or PFES_SKY_CLEAR, the celestial objects become occulted by the sky polygon which it seems is being rendered well inside the viewing frustum. In fact, with a far clip plane set to 50,000 metres (and a near clip plane set to 100 metres), even if I position the billboard at 45,000 metres from the eyepoint, I still get some occulting occurring. This leads me to think that our terrain is also being clipped by the sky/horizon polygons and not the far clip plane as one would expect. I would have thought that when Performer draws the Earth-Sky model it would force all the pixels to the maximum zbuffer value. If this is not possible, could I somehow calculate the exact position of the polygons used by the Earth-sky model so that I can more accurately control the visual range in our simulation? If anyone is interested I have attached a copy of earthsky.c (which comes as a sample program with Performer) to demonstrate the problem. I have modified it so that it uses the PFES_FAST mode for 10 seconds and PFES_SKY_GRND for 10 seconds. The far clip plane is set to 100 metres and the object is displayed 100 metres from the viewpoint. When PFES_FAST is used, the object gets clipped exactly through its origin as expected. However, when PFES_SKY_GRND is used, the object is completely occulted by the sky polygon. Any ideas would be appreciated. Troy Stephen troys@wormald.com.au --0-992262046-800498340:#18062 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="earthsky.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: earthsky.c I2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5j bHVkZSA8c3RyaW5nLmg+DQojaW5jbHVkZSA8bWF0aC5oPg0KI2luY2x1ZGUg PGdsL2RldmljZS5oPg0KDQojaW5jbHVkZSA8UGVyZm9ybWVyL3BmLmg+DQoj aW5jbHVkZSAicGZzZ2kuaCINCg0KDQpzdGF0aWMgdm9pZCBPcGVuUGlwZWxp bmUgKHBmUGlwZSAqcCk7DQpzdGF0aWMgdm9pZCBEcmF3Q2hhbm5lbCAocGZD aGFubmVsICpjaGFuLCB2b2lkICpkYXRhKTsNCg0Kc3RhdGljIHZvaWQNClVz YWdlICh2b2lkKQ0Kew0KICAgIGZwcmludGYoc3RkZXJyLCAiVXNhZ2U6IGVh cnRoc2t5IGZpbGUuZXh0IC4uLlxuIik7DQogICAgZXhpdCgxKTsNCn0NCg0K DQppbnQNCm1haW4gKGludCBhcmdjLCBjaGFyICphcmd2W10pDQp7DQogICAg ZmxvYXQgICAgICAgdCA9IDAuMGY7DQogICAgcGZTY2VuZSAgICAgKnNjZW5l Ow0KICAgIHBmUGlwZSAgICAgICpwOw0KICAgIHBmQ2hhbm5lbCAgICpjaGFu Ow0KICAgIHBmTm9kZQkqcm9vdDsNCiAgICBwZlNwaGVyZQlic3BoZXJlOw0K ICAgIHBmRWFydGhTa3kJKmVza3k7DQoNCiAgICBpZiAoYXJnYyA8IDIpDQoJ VXNhZ2UoKTsNCg0KICAgIC8qIEluaXRpYWxpemUgUGVyZm9ybWVyICovDQog ICAgcGZJbml0KCk7CQ0KDQogICAgLyogVXNlIGRlZmF1bHQgbXVsdGlwcm9j ZXNzaW5nIG1vZGUgYmFzZWQgb24gbnVtYmVyIG9mDQogICAgICogcHJvY2Vz c29ycy4NCiAgICAgKi8NCiAgICBwZk11bHRpcHJvY2VzcyhQRk1QX0RFRkFV TFQpOwkJCQ0KDQogICAgLyogQ29uZmlndXJlIG11bHRpcHJvY2Vzc2luZyBt b2RlIGFuZCBzdGFydCBwYXJhbGxlbA0KICAgICAqIHByb2Nlc3Nlcy4NCiAg ICAgKi8NCiAgICBwZkNvbmZpZygpOwkJCQ0KDQogICAgLyogQXBwZW5kIHRv IFBGUEFUSCBhZGRpdGlvbmFsIHN0YW5kYXJkIGRpcmVjdG9yaWVzIHdoZXJl IA0KICAgICAqIGdlb21ldHJ5IGFuZCB0ZXh0dXJlcyBleGlzdCANCiAgICAg Ki8NCiAgICBwZkZpbGVQYXRoKCIuOi91c3Ivc3JjL1BlcmZvcm1lci9kYXRh Iik7DQoNCiAgICAvKiBSZWFkIGEgc2luZ2xlIGZpbGUsIG9mIGFueSBrbm93 biB0eXBlLiAqLw0KICAgIGlmICgocm9vdCA9IExvYWRGaWxlKGFyZ3ZbMV0s IE5VTEwpKSA9PSBOVUxMKSANCiAgICB7DQoJcGZFeGl0KCk7DQoJZXhpdCgt MSk7DQogICAgfQ0KDQogICAgLyogQXR0YWNoIGxvYWRlZCBmaWxlIHRvIGEg cGZTY2VuZS4gKi8NCiAgICBzY2VuZSA9IHBmTmV3U2NlbmUoKTsNCiAgICBw ZkFkZENoaWxkKHNjZW5lLCByb290KTsNCg0KICAgIC8qIENyZWF0ZSBhIHBm TGlnaHRTb3VyY2UgYW5kIGF0dGFjaCBpdCB0byBzY2VuZS4gKi8NCiAgICBw ZkFkZENoaWxkKHNjZW5lLCBwZk5ld0xTb3VyY2UoKSk7DQoNCiAgICAvKiBD b25maWd1cmUgYW5kIG9wZW4gR0wgd2luZG93ICovDQogICAgcCA9IHBmR2V0 UGlwZSgwKTsNCiAgICBwZkluaXRQaXBlKHAsIE9wZW5QaXBlbGluZSk7CQ0K DQogICAgLyogQ3JlYXRlIGFuZCBjb25maWd1cmUgYSBwZkNoYW5uZWwuICov DQogICAgY2hhbiA9IHBmTmV3Q2hhbihwKTsJDQogICAgcGZDaGFuU2NlbmUo Y2hhbiwgc2NlbmUpOw0KICAgIHBmQ2hhbk5lYXJGYXIoY2hhbiwgMS4wZiwg MTAwLjBmICk7DQogICAgcGZDaGFuRk9WKGNoYW4sIDQ1LjBmLCAwLjBmKTsN CiAgICBwZkNoYW5EcmF3RnVuYyhjaGFuLCBEcmF3Q2hhbm5lbCk7DQoNCiAg ICBlc2t5ID0gcGZOZXdFU2t5KCk7DQogICAgcGZFU2t5TW9kZShlc2t5LCBQ RkVTX0JVRkZFUl9DTEVBUiwgUEZFU19GQVNUKTsNCiAgICBwZkVTa3lBdHRy KGVza3ksIFBGRVNfR1JORF9IVCwgLTEwLjBmICk7DQogICAgcGZFU2t5Q29s b3IoZXNreSwgUEZFU19HUk5EX0ZBUiwgMC4zZiwgMC4xZiwgMC4wZiwgMS4w Zik7DQogICAgcGZFU2t5Q29sb3IoZXNreSwgUEZFU19HUk5EX05FQVIsIDAu NWYsIDAuM2YsIDAuMWYsIDEuMGYpOw0KICAgIHBmQ2hhbkVTa3koY2hhbiwg ZXNreSk7DQoNCiAgICBwZkluaXRDbG9jaygwLjBmKTsNCg0KICAgIHdoaWxl ICh0IDwgMTAuMGYpDQogICAgew0KCWZsb2F0ICAgICAgcywgYzsNCglwZkNv b3JkCSAgIHZpZXc7DQoNCgkvKiBHbyB0byBzbGVlcCB1bnRpbCBuZXh0IGZy YW1lIHRpbWUuICovDQoJcGZTeW5jKCk7CQkNCg0KCS8qIENvbXB1dGUgbmV3 IHZpZXcgcG9zaXRpb24uICovDQoJdCA9IHBmR2V0VGltZSgpOw0KCXBmU2lu Q29zKDQ1LjBmKnQsICZzLCAmYyk7DQoJcGZTZXRWZWMzKHZpZXcuaHByLCA0 NS4wZip0LCAtNS4wZiwgMCk7DQoJcGZTZXRWZWMzKHZpZXcueHl6LCAxMDAu MGYgKiBzLCAtMTAwLjBmICpjLCAxMC4wZik7DQoJcGZDaGFuVmlldyhjaGFu LCB2aWV3Lnh5eiwgdmlldy5ocHIpOw0KDQoJLyogSW5pdGlhdGUgY3VsbC9k cmF3IGZvciB0aGlzIGZyYW1lLiAqLw0KCXBmRnJhbWUoKTsJCQ0KICAgIH0N Cg0KICAgIHBmRVNreU1vZGUoZXNreSwgUEZFU19CVUZGRVJfQ0xFQVIsIFBG RVNfU0tZX0dSTkQpOw0KDQogICAgd2hpbGUgKHQgPCAyMC4wZikNCiAgICB7 DQoJZmxvYXQgICAgICBzLCBjOw0KCXBmQ29vcmQJICAgdmlldzsNCg0KCS8q IEdvIHRvIHNsZWVwIHVudGlsIG5leHQgZnJhbWUgdGltZS4gKi8NCglwZlN5 bmMoKTsJCQ0KDQoJLyogQ29tcHV0ZSBuZXcgdmlldyBwb3NpdGlvbi4gKi8N Cgl0ID0gcGZHZXRUaW1lKCk7DQoJcGZTaW5Db3MoNDUuMGYqdCwgJnMsICZj KTsNCglwZlNldFZlYzModmlldy5ocHIsIDQ1LjBmKnQsIC01LjBmLCAwKTsN CglwZlNldFZlYzModmlldy54eXosIDEwMC4wZiAqIHMsIC0xMDAuMGYgKmMs IDEwLjBmKTsNCglwZkNoYW5WaWV3KGNoYW4sIHZpZXcueHl6LCB2aWV3Lmhw cik7DQoNCgkvKiBJbml0aWF0ZSBjdWxsL2RyYXcgZm9yIHRoaXMgZnJhbWUu ICovDQoJcGZGcmFtZSgpOwkJDQogICAgfQ0KDQogICAgLyogVGVybWluYXRl IHBhcmFsbGVsIHByb2Nlc3NlcyBhbmQgZXhpdC4gKi8NCiAgICBwZkV4aXQo KTsNCg0KICAgIHJldHVybiAwOw0KfQ0KDQoNCnN0YXRpYyB2b2lkDQpPcGVu UGlwZWxpbmUgKHBmUGlwZSAqcCkNCnsNCiAgICAvKiBPcGVuIGdyYXBoaWNz IHdpbmRvdy4gKi8NCiAgICBmb3JlZ3JvdW5kKCk7DQogICAgcHJlZnBvc2l0 aW9uKDEwMCwgNTAwLCAxMDAsIDUwMCk7DQogICAgd2lub3BlbigiSVJJUyBQ ZXJmb3JtZXIiKTsNCg0KICAgIC8qIENvbmZpZ3VyZSB3aW5kb3cgd2l0aCBy ZWFzb25hYmxlIGRlZmF1bHRzLiAqLw0KICAgIHBmSW5pdEdmeChwKTsNCg0K ICAgIC8qIENyZWF0ZSBhbmQgYXBwbHkgYSBkZWZhdWx0IG1hdGVyaWFsIGZv ciB0aG9zZSBtb2RlbHMNCiAgICAgKiB3aXRob3V0IG9uZS4NCiAgICAgKi8N CiAgICBwZkFwcGx5TXRsKHBmTmV3TXRsKHBmR2V0U2hhcmVkQXJlbmEoKSkp Ow0KDQogICAgLyogQ3JlYXRlIGEgZGVmYXVsdCBsaWdodGluZyBtb2RlbC4g Ki8NCiAgICBwZkFwcGx5TE1vZGVsKHBmTmV3TE1vZGVsKHBmR2V0U2hhcmVk QXJlbmEoKSkpOw0KfQ0KDQovKiBEcmF3IHByb2Nlc3MgY2FsbGJhY2sgKi8N CnN0YXRpYyB2b2lkIERyYXdDaGFubmVsIChwZkNoYW5uZWwgKmNoYW4sIHZv aWQgKmRhdGEpDQp7DQogICAgcGZDbGVhckNoYW4gKGNoYW4pOw0KICAgIHBm RHJhdyAoKTsNCn0NCg== --0-992262046-800498340:#18062-- From guest Sun May 14 21:35:35 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA17619; Sun, 14 May 1995 21:06:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA17616; Sun, 14 May 1995 21:06:16 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16291; Sun, 14 May 95 21:06:08 -0700 Received: from vision.arc.nasa.gov by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id VAA01679; Sun, 14 May 1995 21:06:07 -0700 Received: from fusion.arc.nasa.gov (fusion.arc.nasa.gov [128.102.121.150]) by vision.arc.nasa.gov (8.6.12/8.6.5) with ESMTP id VAA29787 for ; Sun, 14 May 1995 21:05:31 -0700 Received: (dhess@localhost) by fusion.arc.nasa.gov (8.6.12/8.6.5) id EAA14027 for info-performer@sgi.com; Mon, 15 May 1995 04:05:30 GMT From: "Drew Hess" Message-Id: <9505142105.ZM14025@fusion.arc.nasa.gov> Date: Sun, 14 May 1995 21:05:30 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pixelmap()/pixeltransfer() Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O We're a little unclear on how pixelmap() and pixeltransfer() work. We would like to take an RGB image, rendered in a viewport by Performer, and convert it via the RE2s color lookup tables to a greyscale image. The mapping is arbitrary (non-linear). For instance, we might want the following mapping: Color Image (RGB) ---> Greyscale Image (RGB) ----------------- --------------------- (255, 255, 255) (0, 0, 0) (255, 255, 250) (127, 127, 127) ... ... (0, 0, 0) (40, 40, 40) Our Performer database has a limited number of colors, something on the order of 30-40 unique RGB values, so the size of the lookup tables is not an issue. Currently, we do this by lrectread()ing the Perfomer viewport, doing manual lookup, and then lrectwrite()ing the greyscale image back to the screen. Obviously the performance of the manual lookup leaves something to be desired. Is this possible with pixelmap() and pixeltransfer()? The man page for pixelmap() is pretty poor, yet this seems to be all the documentation that exists for it. If it is in fact possible, I'm not quite sure how to go about it. It seems to me that there is a many-to-one mapping of RGB triads to a 16-bit value, where the table size is either 256 or 4096 entries, and the interpretation of the 16-bit value is determined by the mode parameter passed to pixelmap(). In the above example, if I used a MAP_I_TO_I map via pixelmap(), wouldn't both (255, 255, 255) and (255, 255, 250) map to the same LUT entry? Or are there in fact 3 separate lookups going on here, one for each component of the original RGB pixel? Thanks in advance, -dwh- dhess@cs.stanford.edu dhess@vision.arc.nasa.gov From guest Sun May 14 23:26:15 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id XAA17823; Sun, 14 May 1995 23:23:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id XAA17820; Sun, 14 May 1995 23:23:18 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18612; Sun, 14 May 95 23:23:17 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id XAA08543; Sun, 14 May 1995 23:23:00 -0700 Received: (from uucp@localhost) by warrane.connect.com.au with UUCP id QAA27555 (8.6.11/IDA-1.6); Mon, 15 May 1995 16:21:22 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA04965 (5.65c/IDA-1.5); Mon, 15 May 1995 16:09:58 +1000 Received: from krusty (krusty [8.0.0.31]) by aggro with SMTP id QAA01367 (8.6.12/IDA-1.6); Mon, 15 May 1995 16:12:06 +1000 Received: by krusty (5.65) id AA07792; Mon, 15 May 1995 16:12:05 +1000 Date: Mon, 15 May 1995 16:12:03 +1000 (EST) From: Robert Webb Subject: Re: pfNodeTravMask calls pfGetGSetBBox??? To: Jim Helman Cc: Performer mailing list In-Reply-To: <199505122051.NAA24773@surreal.asd.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Fri, 12 May 1995, Jim Helman wrote: > pfGetGSetBBox(..., NULL) is supposed to cause a recomputation of the > pfGeoSet bounding box, instead it core dumps. This is is a bug, > which I've just fixed. So no problem in 2.0. OK, great. The man page in 1.2 only has this to say about pfGetGSetBBox: pfGetGSetBBox copies the current bounding box into bbox. It does not mention what should happen when bbox is NULL. Although it does for pfGSetBBox. So in 2.0, these two functions are identical when passed a NULL bbox? > As for why it was invoked: pfGSetISectMask was doing a clean of the > pfGeoSet's dirty attributes. In 1.2, when you change a pfGeoSet > attribute, the bounding box is marked dirty, with the updating done > at will thereafter. We can't recompute the bounding box whenever an > attribute changes, because we don't know if the data are valid yet > In the absence of a pfOKThisGSetIsDone() API, we implicitly make the > assumption that the pfGeoSet is self-consistent (i.e. either empty > or fully set up) when something other than an attribute set/get is > done. We could defer the "clean" to the first cull or isect > traversal, but this would require locks and would add non- > determinism, since the first time the object is "touched" would be > considerably more expensive. I'm still a bit confused: if I had not called pfNodeTravMask() at all, surely the dirty attributes would still have been cleaned? I am now using PFTRAV_SELF rather than PFTRAV_SELF|PFTRAV_DESCEND, since I can't see what difference it really makes. In either case the children of the given node will be pruned for intersection traversals (I believe), but if I just use PFTRAV_SELF then I avoid my original problem. Thanks, Rob. ------------------------------------------------------------------------------ Robert Webb. robertw@wormald.com.au ------------------------------------------------------------------------------ From guest Mon May 15 05:04:15 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA18339; Mon, 15 May 1995 05:01:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA18336; Mon, 15 May 1995 05:01:10 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27350; Mon, 15 May 95 05:01:09 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id FAA27515; Mon, 15 May 1995 05:01:07 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id FAA06194; Mon, 15 May 1995 05:01:05 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:robertw@wormald.com.au id AA27336; Mon, 15 May 95 05:01:03 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id FAA19247; Mon, 15 May 1995 05:01:02 -0700 Message-Id: <199505151201.FAA19247@surreal.asd.sgi.com> To: Robert Webb Cc: Performer mailing list Subject: Re: pfNodeTravMask calls pfGetGSetBBox??? In-Reply-To: Your message of "Mon, 15 May 95 16:12:03 +1000." Date: Mon, 15 May 95 05:00:56 -0700 From: Jim Helman Status: O I looked at the code again, and the only way it should core dump from that NULL is if more than one process is trying to clean the geoset's bbox at the same time. Otherwise maybe it's something else. Please send a complete stack trace with line numbers. Butrgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon May 15 08:29:54 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA18475; Mon, 15 May 1995 08:06:04 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA18472; Mon, 15 May 1995 08:06:02 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01362; Mon, 15 May 95 08:06:01 -0700 Received: from bvr.co.il by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA15257; Mon, 15 May 1995 08:05:41 -0700 Received: from amcor.bvr.co.il by bvr.co.il via SMTP (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA06144; Mon, 15 May 95 18:11:34 +0300 Received: by amcor.bvr.co.il (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.com id SAA07215; Mon, 15 May 1995 18:02:54 +0300 Date: Mon, 15 May 1995 18:02:54 +0300 From: aviva@amcor.bvr.co.il (Aviva Chavel Vaknin) Message-Id: <199505151502.SAA07215@amcor.bvr.co.il> To: info-performer@sgi.sgi.com Status: O We are developing a Performer application in we which traverse and update the database hierarchy loaded by the Performer openflight loader. In particular, we insert groups and geodes into the tree at various levels using the performer routines pfAddChild() and pfReplaceChild(). The resulting tree appears to be correct, however all nodes that we add manually ALWAYS pass culling with "trivially accepted", even when they are not visible. We have attempted recalculating the bounding volumes of the entire tree after all updates, but that has not affected the results. Is there further action necessary when inserting children into the hierarchy, or are there restrictions in adding children ? Aviva Chavel B.V.R. Technologies ISRAEL From guest Sun May 14 21:29:13 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id UAA17605; Sun, 14 May 1995 20:55:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA17602; Sun, 14 May 1995 20:55:38 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16111; Sun, 14 May 95 20:55:37 -0700 Received: from redgate.vislab.su.edu.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id UAA01273; Sun, 14 May 1995 20:55:34 -0700 Received: from moffatt.vislab.su.edu.au by redgate.vislab.su.edu.au via ESMTP (950215.SGI.8.6.10/940406.SGI) for id NAA12409; Mon, 15 May 1995 13:55:18 +1000 Received: by moffatt.vislab.su.edu.au (950215.SGI.8.6.10/940406.SGI) for info-performer@sgi.com id NAA12293; Mon, 15 May 1995 13:55:15 +1000 From: "Ben Simons" Message-Id: <9505151355.ZM12291@moffatt.vislab.su.edu.au> Date: Mon, 15 May 1995 13:55:13 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Anyone using cvd with performer? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Is there anyone using the CaseVision Workshop debugger "cvd" with performer? I am having trouble using the Structure Browser on structures that have been created via pfMalloc. In particular, I can't dereference the pointer returned; I get the error: ``variable is used before it is set'' and, yes, I am double clicking the address in the structure node of the structure browser after the pfMalloc() returns. Variable is set to NULL before the call to pfmalloc, so I know that the allocation does return an address. Any ideas?? ben. ------ To make the question explicit, Here's some example code... typedef struct pressureHeader { int howmany; int whichSet; int xsize; int ysize; PressChart *chartHead; PressChart *chartTail; } pressureHeader; pressureHeader * createPressHeader( void) { void *arena = pfGetSharedArena(); pressureHeader *pressHeader; int structSize; if( arena == NULL) { fprintf( stderr, "Error: createPressHeader(): "); fprintf( stderr, "can't get ptr to arena!\n"); return( NULL); } structSize = sizeof( pressureHeader); pressHeader = (pressureHeader *)pfMalloc( structSize, arena); if( pressHeader == NULL) { fprintf( stderr, "Error: createPressHeader(): "); fprintf( stderr, "can't malloc pressureHeader\n"); return( NULL); } return( pressHeader); } main() { pressureHeader *ph = NULL; fprintf(stderr, "starting.\n"); pfInit(); ph = createPressHeader(); ph->howmany = 9; ph->whichSet = 2; ph->chartTail = NULL; fprintf(stderr, "done.\n"); } When execution gets to the line with "ph->whichSet" in it, I expect that I should be able to use the Struct Browser to see ph. This is when I get the error: ph is used before it is set. The versions I am running are: IRIX 5.3, performer 1.2, and (cvd) Workshop 2.4 Nb. if I add a variable: pressureHeader ph2; to main(), then I can browse ph2. -- _______________________________________________________ Ben Simons Physics Building, A28, VisLab Systems Manager Sydney University. NSW. Phone +61-2-351-3005 AUSTRALIA. 2006. From guest Tue May 16 04:17:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA21329; Tue, 16 May 1995 03:54:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA21326; Tue, 16 May 1995 03:54:09 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07811; Tue, 16 May 95 03:54:08 -0700 Received: from david.zfe.siemens.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA28568; Tue, 16 May 1995 03:54:02 -0700 From: epp@d019f063.zfe.siemens.de Received: from ztivax.zfe.siemens.de by david.zfe.siemens.de with SMTP id AA03725 (5.67a/IDA-1.5 for ); Tue, 16 May 1995 12:53:50 +0200 Received: from D019F063.zfe.siemens.de (d019f063) by ztivax.zfe.siemens.de with SMTP id AA14038 (5.67a/IDA-1.5 for ); Tue, 16 May 1995 12:53:51 +0200 Received: from PGTF0006.z6 by D019F063.zfe.siemens.de (4.1/SMI-4.1) id AA17217; Tue, 16 May 95 12:52:08 +0200 Date: Tue, 16 May 95 12:52:07 +0200 Message-Id: <9505161052.AA17217@D019F063.zfe.siemens.de> To: info-performer@sgi.sgi.com Subject: benchmarking Status: O In the process of benchmarking my application and finding bottlenecks, I've studied the pfStats man pages and detected the "PFSTATSHW_GFXPIPE_BTLNCK" PFSTATS_ Token. Unfortunatly this token is not definded in the Performer/prstats.h> header file, so it will not compile. The following is a cut of the pfStats man pages about the Statistics Class Table. pfStats(3pf) IRIS Performer 1.2 libpr Reference Pages pfStats(3pf) ____________________________________________________________________________ | Statistics Class Table | |__________________________________________________________________________| | Class | PFSTATS_ Token | PFSTATS_EN token | |____________________|__________________________|__________________________| |Graphics Rendered | PFSTATS_GFX | PFSTATS_ENGFX | X Graphics Bottleneck | PFSTATSHW_GFXPIPE_BTLNCK | PFSTATS_ENGFXPIPE_BTLNCK | |Pixel Fill | PFSTATSHW_GFXPIPE_FILL | PFSTATSHW_ENGFXPIPE_FILL | |CPU | PFSTATSHW_CPU | PFSTATSHW_ENCPU | |Memory | PFSTATSHW_MEM | PFSTATSHW_ENMEM | |____________________|__________________________|__________________________| Could you please provide information regarding this token, when it will be available, what kind of statistics it will report, how to patch the header file to get it enabled and a sample setup of this token in the application. An additional mode added to the gui statistics radio button in gui.c would be very helpfull. Thanks, Erwin =================================================================== _____ _ _ _ Siemens-Nixdorf-Informationssysteme AG /____/ / | // // Otto-Hahn-Ring 6 //__ //|| // // 81739 Muenchen /__ / // || // // voice : +49 89 636-2944 ____// // ||// // Erwin Epple fax : +49 89 636-46779 /____/ // |_/ // BS2000 HE ZE 113 e-mail : epp@d019f063.zfe.siemens.de =================================================================== From guest Tue May 16 02:00:09 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA21229; Tue, 16 May 1995 01:35:11 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA21226; Tue, 16 May 1995 01:35:05 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05771; Tue, 16 May 95 01:34:56 -0700 Received: from bvr.co.il by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id BAA22006; Tue, 16 May 1995 01:34:42 -0700 Received: from amcor.bvr.co.il by bvr.co.il via SMTP (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA01409; Tue, 16 May 95 11:40:30 +0300 Received: by amcor.bvr.co.il (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.com id LAA01322; Tue, 16 May 1995 11:31:50 +0300 From: "Aviva Chavel Vaknin" Message-Id: <9505161131.ZM1320@amcor.bvr.co.il> Date: Tue, 16 May 1995 11:31:48 +0000 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Culling problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O We are developing a Performer application in we which traverse and update the database hierarchy loaded by the Performer openflight loader. In particular, we insert groups and geodes into the tree at various levels using the performer routines pfAddChild() and pfReplaceChild(). The resulting tree appears to be correct, however all nodes that we add manually ALWAYS pass culling with "trivially accepted", even when they are not visible. We have attempted recalculating the bounding volumes of the entire tree after all updates, but that has not affected the results. Is there further action necessary when inserting children into the hierarchy, or are there restrictions in adding children ? Aviva Chavel aviva@bvr.co.il B.V.R. Technologies, ISRAEL 972-3-571-5671 From guest Tue May 16 05:34:05 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA21410; Tue, 16 May 1995 05:10:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA21407; Tue, 16 May 1995 05:10:34 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08893; Tue, 16 May 95 05:10:30 -0700 Received: from charlie.ece.scarolina.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA02395; Tue, 16 May 1995 05:10:27 -0700 Received: by charlie.ece.scarolina.edu (5.57/Ultrix3.0-C) id AA24139; Tue, 16 May 95 08:10:22 -0400 Received: by enterprise.ece.scarolina.edu (950215.SGI.8.6.10/940406.SGI.AUTO) for info-performer@sgi.com id IAA29302; Tue, 16 May 1995 08:10:17 -0400 Date: Tue, 16 May 1995 08:10:17 -0400 From: king@enterprise.ece.scarolina.edu (Chris King) Message-Id: <199505161210.IAA29302@enterprise.ece.scarolina.edu> To: info-performer@sgi.sgi.com Status: O unsubscribe Chris King Electrical & Computer Engineering University of South Carolina (803) 777-7447 From guest Tue May 16 07:09:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA21522; Tue, 16 May 1995 06:45:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA21517; Tue, 16 May 1995 06:45:02 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10726; Tue, 16 May 95 06:44:47 -0700 Received: from martinique by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA09396; Tue, 16 May 1995 06:44:44 -0700 Received: from montserrat.ndhm.gtegsc.com by martinique via SMTP (931110.SGI/920502.SGI) for info-performer@sgi.com id AA25964; Tue, 16 May 95 09:44:01 -0400 Received: by montserrat (931110.SGI/930416.SGI) for @martinique.ndhm.gtegsc.com:info-performer@sgi.com id AA26740; Tue, 16 May 95 08:51:55 -0400 Date: Tue, 16 May 95 08:51:55 -0400 From: murtland@montserrat.ndhm.gtegsc.com (Jeff Murland) Message-Id: <9505161251.AA26740@montserrat> To: info-performer@sgi.sgi.com Subject: pfMalloc() error Reply-To: murtland@martinique.ndhm.gtegsc.com Status: O Hi, I'm trying to load a large .iv file into Perfly linked with the pfiv1.3 inverntor loader and get the following errors: Performer Fatal (12): pfMalloc() Unable to allocate 43024384 bytes from the heap. I looked at the swap space on the machine, and think I have enough space. (?) %swap -l command yields: lswap path dev pri swaplo blocks free maxswap vswap 2 /usr/swap/swap1 128,278 2 0 102400 102400 102400 0 1 /dev/swap 128,273 0 0 524288 516320 524288 0 I need a clue as to what to try next. I know the *.iv file is o.k., I load it into SceneViewer just fine. System info: 2 200 MHZ IP19 Processors CPU: MIPS R4400 Processor Chip Revision: 6.0 FPU: MIPS R4010 Floating Point Chip Revision: 0.0 Main memory size: 128 Mbytes, 2-way interleaved Thanks, Jeff -------------------------------------------------------------------- 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 From guest Tue May 16 13:02:07 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA22088; Tue, 16 May 1995 12:33:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA22085; Tue, 16 May 1995 12:33:17 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26596; Tue, 16 May 95 12:33:12 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id MAA12397; Tue, 16 May 1995 12:33:08 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id MAA07050; Tue, 16 May 1995 12:33:06 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:epp@d019f063.zfe.siemens.de id AA26586; Tue, 16 May 95 12:33:04 -0700 Received: by rose.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA02353; Tue, 16 May 1995 12:32:52 -0700 From: "Sharon Clay (Fischler)" Message-Id: <9505161232.ZM2351@rose.asd.sgi.com> Date: Tue, 16 May 1995 12:32:52 -0700 In-Reply-To: epp@d019f063.zfe.siemens.de "benchmarking" (May 16, 12:52pm) References: <9505161052.AA17217@D019F063.zfe.siemens.de> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: epp@d019f063.zfe.siemens.de, info-performer@sgi.sgi.com Subject: Re: benchmarking Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On May 16, 12:52pm, epp@d019f063.zfe.siemens.de wrote: > Subject: benchmarking -> ->In the process of benchmarking my application and finding bottlenecks, I've ->studied the pfStats man pages and detected the "PFSTATSHW_GFXPIPE_BTLNCK" ->PFSTATS_ Token. ->Unfortunatly this token is not definded in the Performer/prstats.h> header ->file, so it will not compile. The PFSTATSHW_GFXPIPE_BTLNCK token should not have been in the man page - This is a documentation bug in 1.2. This token will also not be supported in 2.0. Still looking to the future.... However, for an example of how to benchmark your application and some different uses of statistices, look at the stats.c and bench.c programs in /usr/src/Performer/src/sample/pguide/libpf/progs/ -> ->Could you please provide information regarding this token, when it will be ->available, what kind of statistics it will report, how to patch the header ->file to get it enabled and a sample setup of this token in the application. ->An additional mode added to the gui statistics radio button in gui.c would ->be very helpfull. The hope is to one day tell you at least what is the overwhelming bottleneck of your database, and at best tell you this information for different parts of your database. Imagine a mode like the fill statistics where your scene can be painted by bottleneck..... However, not yet. Glad for your interest! src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Graphics Dev. src@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue May 16 14:04:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA22215; Tue, 16 May 1995 13:34:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA22212; Tue, 16 May 1995 13:34:07 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29557; Tue, 16 May 95 13:34:03 -0700 Received: from dw3si.ess.harris.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA24569; Tue, 16 May 1995 13:34:01 -0700 From: bmcquear@dw3f.ess.harris.com Received: by dw3si.ess.harris.com (5.57/Ultrix3.0-C) id AA10516; Tue, 16 May 95 16:35:26 -0400 Message-Id: <9505162035.AA10516@dw3si.ess.harris.com> To: info-performer@sgi.sgi.com Subject: LoadFile problems Date: Tue, 16 May 95 16:35:24 -0400 X-Mts: smtp Status: O Hi, Any help on the following problem would be greatly appreciated. Can somebody explain why the following code inserted into pickfly causes it to dump after approximately 280 iterations? (This is a symptom of a current application I am working on but I reproduced in pickfly to simplify discussing it) /* Existing in pickfly...Load database.... */ for (i=0; i < NumFiles; i++) { /* Inserted for debug...Now want to read in a bunch of groups... */ for (j=0; j < 300; j++) root = (pfGroup *)LoadFile("klingon.flt", NULL); } Also, the number of iterations varies depending on the complexity of the model read in. This leads me to think that there may be either some MAX system limit for the size of the executable image that is running, or MAX limit for the total triangles in the performer geometry?? With pfNotify (PFNFY_DEBUG) I get no pf type errors. I am runing on an Indigo 2 Extreme, Performer 1.2, Iris 5.3, C++ 4.0 (Also I recently upgraded to Iris 5.3 from 5.2 but never noticed the bug in 5.2, probably because never loaded as many nodes) Here's the call stack after the dump: 0 pfUpdateList::checkFlush()(0xbf143702, 0x0, 0x1, 0x101e32c8, 0x18a9a60) [0x4f0a30] 1 pfBuffer::checkFlush()(0xbf143702, 0x0, 0x1, 0x101e32c8, 0x0) ["../../../lib/libpf/pfBuffer.C":137, 0x4b0e6c] 2 pfNewGeode(0xbf143702, 0x0, 0x1, 0x101e32c8, 0xc3238e4f) ["../../../lib/libpf/pfProcess.C":2881, 0x49b264] 3 makeGeode(0xbf143702, 0x0, 0x1, 0x101e32c8, 0x28000) ["../../../lib/libpfflt/geom.c":3007, 0x4708ac] 4 makeGeometry(0xbf143702, 0x0, 0x1, 0x101e32c8, 0x8) ["../../../lib/libpfflt/geom.c":2688, 0x46ffdc] 5 convObject(0x1897780, 0x0, 0x1, 0x101e32c8, 0x0) ["../../../lib/libpfflt/hier.c":1993, 0x466318] 6 convTree(0x1894b70, 0x0, 0x101d0bf0, 0x3, 0x0) ["../../../lib/libpfflt/hier.c":1038, 0x4638c4] 7 convTree(0x188e050, 0x0, 0x101d0bf0, 0x3, 0x0) ["../../../lib/libpfflt/hier.c":670, 0x462ab8] 8 convTree(0x188dff0, 0x0, 0x101d0bf0, 0x2, 0xfb54398) ["../../../lib/libpfflt/hier.c":670, 0x462ab8] 9 convTree(0x188dff0, 0x0, 0x101d0bf0, 0x1, 0x7618f0) ["../../../lib/libpfflt/hier.c":670, 0x462ab8] 10 LoadFlt(0x1000d1b8, 0x0, 0x7618f0, 0x6272a0, 0xfb5af20) ["../../../lib/libpfflt/hier.c":286, 0x461be0] 11 LoadFile(0x1000d1b8, 0x0, 0x187da70, 0x187da70, 0x1002b9d0) ["../../../lib/libpfsgi/loadfile.c":87, 0x43b3b4] 12 initSceneGraph(scene = 0x761870) ["/disk2/joe/Performer/pickfly/OPT/../pickfly.c":179, 0x436454] 13 InitScene() ["/disk2/joe/Performer/pickfly/OPT/../generic.c":266, 0x42f2ec] 14 main(argc = 2, argv = 0x7fffaf54) ["/disk2/joe/Performer/pickfly/OPT/../main.c":96, 0x43aef0] Thanks for any help, Bruce McQueary bmcquear@harris.com (407)984-6813 From guest Tue May 16 14:37:02 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA22267; Tue, 16 May 1995 14:06:39 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA22264; Tue, 16 May 1995 14:06:35 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02400; Tue, 16 May 95 14:06:27 -0700 Received: from zeus.sdl.USU.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA01302; Tue, 16 May 1995 14:06:24 -0700 Received: from raptor.pipe.sdl.usu.edu (raptor.idec.sdl.usu.edu) by zeus.sdl.USU.edu (5.x/SMI-SVR4) id AA26662; Tue, 16 May 1995 15:06:15 -0600 Received: by raptor.pipe.sdl.usu.edu (931110.SGI/920502.SGI.AUTO) for @sdl.usu.edu:info-performer@sgi.com id AA21333; Tue, 16 May 95 15:06:04 -0600 From: "Satish K. Annapureddy" Message-Id: <9505161506.ZM21331@raptor.pipe.sdl.usu.edu> Date: Tue, 16 May 1995 15:06:04 -0600 Envelope: cool X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: GLX mode and Cursor positioning Cc: satish@raptor.pipe.sdl.USU.edu, shaun@raptor.pipe.sdl.USU.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi there, I am using a modified version of perfly in GLX mode(PFUINPUT_X) I need to reposition the cursor . I tried to use setvaluator() in both PFUINPUT_X and PFUINPUT_GL mode. It works just once when the window is created /resized but subsequent calls are ignored, till the window is resized again(manually-not in code.) When I tried using XWarpPointer() with the window id from the OpenXpipeline() ( in generic.c), it core dumps. I checked for non-null display pointer and it is OK. Can you please let me know what I am doing wrong, since there has to be someway to reposition the cursor in performer applications. Thanks, Satish. From guest Wed May 17 13:54:49 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA24948; Wed, 17 May 1995 13:39:19 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA24945; Wed, 17 May 1995 13:39:15 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24045; Wed, 17 May 95 13:39:11 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id NAA29634; Wed, 17 May 1995 13:39:08 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id NAA15011; Wed, 17 May 1995 13:39:06 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:murtland@martinique.ndhm.gtegsc.com id AA24035; Wed, 17 May 95 13:38:58 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA20174; Wed, 17 May 1995 13:38:57 -0700 Message-Id: <199505172038.NAA20174@surreal.asd.sgi.com> To: murtland@martinique.ndhm.gtegsc.com, angus@reading.sgi.com Cc: info-performer@sgi.sgi.com Subject: Fix to Inventor Loader for Large Databases In-Reply-To: Your message of "Tue, 16 May 95 08:51:55 EDT." <9505161251.AA26740@montserrat> Date: Wed, 17 May 95 13:38:57 -0700 From: Jim Helman Status: O I chatted about this with Chris Tanner, Mr. Builder. The problem is that the allocation size in the builder increases by 2X each time it overflows the existing allocation. This is too aggressive for very large databases. The best thing to do is to change line 1716 in geobuilder.c chunkSize <<= 1; to: /* limit to 8K tris/chunk */ if (chunkSize < 8192) chunkSize <<= 1; This is the fix that's in 2.0. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed May 17 14:59:52 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA25052; Wed, 17 May 1995 14:43:17 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA25049; Wed, 17 May 1995 14:43:17 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28067; Wed, 17 May 95 14:43:12 -0700 Received: from MAPS.CS.CMU.EDU by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA13617; Wed, 17 May 1995 14:43:07 -0700 From: Stephen_Gifford@MAPS.CS.CMU.EDU Received: from MAPS.CS.CMU.EDU by MAPS.CS.CMU.EDU id aa07345; 17 May 95 17:42:52 EDT To: info-performer@sgi.sgi.com Subject: Job Posting Date: Wed, 17 May 95 17:42:51 -0400 Message-Id: <7343.800746971@MAPS.CS.CMU.EDU> Status: O I hope no one minds another job posting. The Performer related job is the third one down. Contact is listed at the bottom. "advanced SGI hardware" is code for a 4 processor Onyx. -Steve Gifford -------------------------------------------------------------------------- Research Staff Positions in Remote Sensing and Computer Science Digital Mapping Laboratory School of Computer Science Carnegie Mellon University Applications are invited for research staff positions in the general areas of digital cartography, remote sensing, advanced distributed simulation, and computer vision. Positions are available at several levels, including research programmer, senior research programmer, project scientist, and post doctoral research faculty. All positions are within the School of Computer Science at Carnegie Mellon University. Post doctoral positions are tenable for two years with possibilities for appointment to the regular Research or Systems Faculty track within the School. The successful applicant will be expected to play a major role in the current and future research efforts within the Digital Mapping Laboratory. Our research is broadly focused on the automated interpretation of remotely sensed data including high resolution aerial imagery and multispectral imagery such as SPOT, Landsat TM, and Daedalus scanner data. Current areas of investigation include knowledge-based scene analysis; cultural feature extraction (road network and building detection and delineation); automated scene registration and stereo matching; intensification and manipulation of large-scale spatial databases; and the use of these databases in the construction of large scale virtual worlds for advanced distributed simulation. Applicants at all levels are expected to be proficient in the implementation of large scale software systems within a UNIX/C/X11 environment. We seek applicants for the following research areas: --Digital cartographer. The candidate must have significant experience with the manipulation of digital cartographic data in various formats (DMA ITD and VPF, USGS DLG and LULC, and others) within the context of GIS applications. Prior work in the generalization, aggregation, and editing of digital feature data is relevant. Research issues include the generalization and combination of spatial data from diverse sources to be used in the automated generation of large scale virtual world simulation databases. Data sources will consist of standard DMA and USGS products as well as the results of automated computer vision systems. The successful applicant will be responsible for leadership in the design and implementation of prototype systems to automate the spatial data fusion process. --Remote sensing specialist. The candidate must have experience in performing analysis and classification using multispectral imagery, particularly using advanced airborne or hyperspectral systems with high spatial resolution. Research emphasis will be placed on the development of classification algorithms, the rigorous evaluation of the results, and the fusion of those results with information from other sources such as digital elevation models, a priori digital map data, and results from automated computer vision systems. --Visual simulation specialist. The candidate should have experience with terrain based simulation applications involving the efficient display and modification of runtime databases using advanced SGI hardware (including Performer and Inventor toolkit experience) and experience with X11 and Motif programming. In addition the applicant will be expected to participate in research in the area of applied computational geometry and the implementation of efficient algorithms for database construction. Experience with SIMNET, CCTT, or other related distributed visual simulation systems is a plus. --Computer graphics programmer. The candidate must have experience in the display and manipulation of digital imagery and spatial (cartographic) data. Knowledge of the X11 toolkits, Motif, and previously experience in the design and development of scientific user interfaces is required. A strong background in one or more of these areas or related areas is required. Excellent written and verbal communication skills are also expected. Applicants should send a curriculum vitae and names of at least three references to: David M. McKeown, Jr. Principal Research Computer Scientist Digital Mapping Laboratory School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 maps@cs.cmu.edu For more information regarding the Digital Mapping Laboratory and its projects: http://www.cs.cmu.edu/~MAPSLab Carnegie Mellon is an Equal Opportunity/Affirmative Action employer. Carnegie Mellon University does not discriminate and Carnegie Mellon University is required not to discriminate in admission, employment, or administration of its programs on the basis of race, color, national origin, sex or handicap in violation of Title VI of the Civil Rights Act of 1964, Title IX of the Educational Amendments of 1972, and Section 504 of the Rehabilitation Act of 1973 or other federal, state or local laws, or executive orders. From guest Wed May 17 15:33:49 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA25211; Wed, 17 May 1995 15:18:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA25208; Wed, 17 May 1995 15:18:03 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00323; Wed, 17 May 95 15:17:50 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA21014; Wed, 17 May 1995 15:17:46 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (940816.SGI.8.6.9/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id PAA23018; Wed, 17 May 1995 15:17:03 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id PAA07919; Wed, 17 May 1995 15:16:57 -0700 From: "AnitaKishore" Message-Id: <9505171516.ZM7917@lee.electrogig.com> Date: Wed, 17 May 1995 15:16:55 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: usage of engines in Inventor file format through Performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hello: Can someone explain to me how to make Inventor engines (user defined) whose description is given in Inventor file format, work inside a Performer program? If anyone can send me a small sample program, it would be great. Thanks ----------------------------------------------------------------------------- Anita Kishore kishore@electrogig.com ----------------------------------------------------------------------------- From guest Wed May 17 17:01:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA25333; Wed, 17 May 1995 16:46:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA25330; Wed, 17 May 1995 16:46:49 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04782; Wed, 17 May 95 16:46:48 -0700 Received: from orl.mmc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) id QAA10034; Wed, 17 May 1995 16:46:45 -0700 Received: by orl.mmc.com (4.1/1.34.a) id AA28340; Wed, 17 May 95 19:46:02 EDT Date: Wed, 17 May 95 19:46:02 EDT From: chucks@orl.mmc.com (Chuck Strickland) Message-Id: <9505172346.AA28340@orl.mmc.com> Subject: change of email address. Apparently-To: guest Apparently-To: info-performer@sgi.sgi.com Apparently-To: info-performer-request@sgi.sgi.com Status: O please change lauras@romulus.orl.mmc.com to lauras@escmail.orl.mmc.com any questions to chucks@orl.mmc.com(Postmaster) thanks. From guest Thu May 18 02:19:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA00945; Thu, 18 May 1995 01:49:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA00942; Thu, 18 May 1995 01:49:49 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20507; Thu, 18 May 95 01:49:45 -0700 Received: from redgate.vislab.su.edu.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id BAA02405; Thu, 18 May 1995 01:49:28 -0700 Received: by redgate.vislab.su.edu.au (950215.SGI.8.6.10/940406.SGI) for info-performer@sgi.com id SAA08380; Thu, 18 May 1995 18:49:21 +1000 Date: Thu, 18 May 1995 18:49:21 +1000 From: ben@vislab.su.edu.au (Ben Simons) Message-Id: <199505180849.SAA08380@redgate.vislab.su.edu.au> To: info-performer@sgi.sgi.com Subject: pfReplaceChild() Status: O When I call pfReplaceChild(), do I need to pfFree() the child that was replaced? When I try to do so I get: Performer Warning: pfFree() pointer 0x19ddd490 not from pfMalloc ben. _______________________________________________________ Ben Simons Physics Building, A28, VisLab Systems Manager Sydney University. NSW. Phone +61-2-351-3005 AUSTRALIA. 2006. From guest Thu May 18 05:02:12 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id EAA01138; Thu, 18 May 1995 04:32:58 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id EAA01135; Thu, 18 May 1995 04:32:50 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23212; Thu, 18 May 95 04:32:39 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id EAA00643; Thu, 18 May 1995 04:32:34 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) id EAA00927; Thu, 18 May 1995 04:32:31 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id MAA08077; Thu, 18 May 1995 12:28:01 +0100 From: "Rob Jenkins" Message-Id: <9505181228.ZM8075@barney.reading.sgi.com> Date: Thu, 18 May 1995 12:28:01 +0100 In-Reply-To: "Slimane Merzouk" "levels of details" (May 18, 11:30am) References: <9505181130.ZM8325@boudot.loria.fr> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Slimane Merzouk" , info-performer@sgi.sgi.com Subject: Re: levels of details Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19505181228.ZM8075.reading.sgi.com" Status: O -- --PART-BOUNDARY=.19505181228.ZM8075.reading.sgi.com Content-Type: text/plain; charset=us-ascii On May 18, 11:30am, Slimane Merzouk wrote: > Subject: levels of details > Hi, > > I have heard that Performer can do geometrical simplification by > using some sort of Levels of Details concepts. I wish to have > more information about this, i.e. which algorithm > is used, pointer to any reference and finally how actually performer > accomplish this. > > Thanks in advance. > > > -- > Slimane Merzouk (Chevalier de la table hyperbolique) >-- End of excerpt from Slimane Merzouk I have attached the man page for pfLOD - if you need more information let me know. You can see an example of this by running perfly esprit.flt ( this model has LOD built in ) and changing the LOD scale slider. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, --PART-BOUNDARY=.19505181228.ZM8075.reading.sgi.com X-Zm-Content-Name: manPfLod Content-Description: Text Content-Type: text/plain ; name="manPfLod" ; charset=us-ascii pfLOD(3pf) IRIS Performer 1.2 libpf Reference Pages pfLOD(3pf) NAME pfNewLOD, pfLODRange, pfGetLODRange, pfLODCenter, pfGetLODCenter - Create, modify, and query level of detail nodes. C SPECIFICATION #include pfLOD * pfNewLOD(void); void pfLODRange(pfLOD *lod, long index, float range); float pfGetLODRange(pfLOD *lod, long index); void pfLODCenter(pfLOD *lod, pfVec3 center); void pfGetLODCenter(pfLOD *lod, pfVec3 center); PARAMETERS lod identifies a pfLOD. DESCRIPTION A pfLOD is a level-of-detail (LOD) node. Level-of-detail is a technique for manipulating model complexity based on image quality and rendering speed. Typically, a model is drawn in finer detail when close to the viewer (occupies large screen area) than when it is far away (occupies little screen area). In this way, costly detail is drawn only when necessary. Additionally, IRIS Performer can adjust LODs based on rendering load. If a scene is taking too long to draw, IRIS Performer can globally modify LODs so that they are drawn coarser and render time is reduced (see pfChanStress). IRIS Performer uses range-based LOD and adjusts for field-of-view and viewport pixel size. Range is computed as the distance from the pfChannel eyepoint which is drawing the scene to a point designated as the center of a pfLOD. This range is then potentially modified by pfChannel attributes (see pfChanLODAttr, pfChanStress). This range indexes the pfLOD range list to select a single child to draw. pfLOD is derived from pfGroup so it can have children and use pfGroup API to manipulate its child list. In addition to a list of children, a pfLOD has a list of ranges which specify the transition points between levels- of-detail. pfNewLOD creates and returns a handle to a new pfLOD. pfLODCenter sets the object-space point which defines the center of lod. center is affected by any transforms in the hierarchy above lod (see pfSCS). pfGetLODCenter copies the LOD center point into center. pfLODRange sets the value of range list element index to range which is a floating point distance specified in world coordinates. A child is selected based on the computed range (LODRange) from the eyepoint to the Page 1 pfLOD(3pf) IRIS Performer 1.2 libpf Reference Pages pfLOD(3pf) pfLOD center and the range list (Ranges) according to the following decision test: if (LODRange < Ranges[0]) draw nothing; else if (LODRange >= Ranges[i] && LODRange < Ranges[i+1]) draw Child[i]; else if (LODRange >= Ranges[N-1] where N is length of Ranges) draw nothing; Ranges specified by pfLODRange must be positive and increasing with index or results are undefined. pfGetLODRange returns the range with index index. Normally, LOD transitions are abrupt switches that can cause distracting visual artifacts. On hardware which supports it, IRIS Performer can blend (fade) between levels-of-detail for a smooth transition. Fade level-of-detail (FLOD) is enabled by setting a non-zero fade range with pfChanLODAttr. FLOD is discussed in greater depth in the pfChanLODAttr man page. NOTES Intersection traversals currently always intersect with an LODRange of 0. To intersect with other ranges, a pfSwitch with the same parent and chil- dren as the pfLOD can be created with the pfLOD used for drawing and the pfSwitch used for intersecting (see pfChanTravMask). SEE ALSO pfChanLODAttr, pfChanStress, pfFindLOD, pfGroup, pfNode Page 2 --PART-BOUNDARY=.19505181228.ZM8075.reading.sgi.com-- From guest Thu May 18 09:45:29 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA01523; Thu, 18 May 1995 09:26:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA01520; Thu, 18 May 1995 09:26:02 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00577; Thu, 18 May 95 09:25:54 -0700 Received: from shallow.division.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA01470; Thu, 18 May 1995 09:25:48 -0700 Received: from caliban.division.co.uk by shallow.division.co.uk with SMTP id AA11816 (5.65c/IDA-1.4.4 for info-performer@sgi.com); Thu, 18 May 1995 16:25:45 GMT Received: by caliban.division.co.uk (931110.SGI/921111.SGI) for @shallow.division.co.uk:info-performer@sgi.com id AA11641; Thu, 18 May 95 17:25:36 +0100 From: "Angus Dorbie" Message-Id: <9505181725.ZM11639@caliban.division.co.uk> Date: Thu, 18 May 1995 17:25:35 +0100 In-Reply-To: Ben Simons "pfReplaceChild()" (May 18, 6:49pm) References: <199505180849.SAA08380@redgate.vislab.su.edu.au> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Ben Simons Subject: Re: pfReplaceChild() Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > When I call pfReplaceChild(), do I need to pfFree() the child > that was replaced? When I try to do so I get: > > Performer Warning: pfFree() pointer 0x19ddd490 not from pfMalloc I rely on pfDelete() to get rid of my redundant performer nodes. You must also set any user data at nodes to NULL prior to deleting the node if you still need the data. Be aware that pfDelete deletes everything below the deleted node if it isn't used elsewhere, to avoid this increment their reference counts. I've had similar errors to yours in the past but it's generally been due to my application scribbling memory or similar mistake. -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.co.uk UK From guest Thu May 18 03:03:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA01005; Thu, 18 May 1995 02:31:04 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA01002; Thu, 18 May 1995 02:31:03 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21584; Thu, 18 May 95 02:30:55 -0700 Received: from lorraine.loria.fr by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA04851; Thu, 18 May 1995 02:30:51 -0700 Received: from boudot.loria.fr (boudot.loria.fr [152.81.3.120]) by lorraine.loria.fr (8.6.12/8.6.12) with ESMTP id LAA03779 for ; Thu, 18 May 1995 11:30:46 +0200 Received: (merzouk@localhost) by boudot.loria.fr (8.6.12/8.6.12) id LAA08327 for info-performer@sgi.com; Thu, 18 May 1995 11:30:46 +0200 From: "Slimane Merzouk" Message-Id: <9505181130.ZM8325@boudot.loria.fr> Date: Thu, 18 May 1995 11:30:44 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: levels of details Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi, I have heard that Performer can do geometrical simplification by using some sort of Levels of Details concepts. I wish to have more information about this, i.e. which algorithm is used, pointer to any reference and finally how actually performer accomplish this. Thanks in advance. -- Slimane Merzouk (Chevalier de la table hyperbolique) From guest Thu May 18 11:18:13 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA01668; Thu, 18 May 1995 10:58:25 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA01665; Thu, 18 May 1995 10:58:24 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07066; Thu, 18 May 95 10:58:23 -0700 Received: from ligsg1.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA21338; Thu, 18 May 1995 10:58:20 -0700 Received: by ligsg1.epfl.ch (Smail3.1.29.1 #28) id m0sC9pv-0002kVC; Thu, 18 May 95 19:58 MET DST From: "Fernando D. Mato Mira" Message-Id: <9505181958.ZM21841@lig.di.epfl.ch> Date: Thu, 18 May 1995 19:58:15 +0200 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Motif/Performer problem on Onyx Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hello, I have an app that runs OK on the Indigos but doesn't work at all on the Onyx (PFMP_APPCULLDRAW). I've used cvd to setup a breakpoint in openGLXconnection (see below), but this does not seem to be called before setupWorkProc. So, pfInitPipe is not immediate in single-process mode? Thanks in advance. void SceneWindow::afterRealizeHook() { // This happens once after the widget // is first realized. Widget w = _draw_area; Display * display = XtDisplay(w); Window xWindow = XtWindow(w); // Place info in shared memory so draw // process can attach to GLXwidget. ViewState->glx_info.display_name = 0; if (!pipe_inited) { // Release exclusive hold on GLXwidget. GLXunlink(display, xWindow); } // Performer will now call // openGLXconnection in the draw // process. pfPipe *pipe = pfGetPipe(0); if (!pipe_inited) { pfInitPipe(pipe, openGLXconnection); pipe_inited = TRUE; } openGLXwindow(display, xWindow); setupWorkProc(); } void openGLXconnection(pfPipe* pipe) { ViewState->display = XOpenDisplay(ViewState->glx_info.display_name); } From guest Thu May 18 11:25:05 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA01680; Thu, 18 May 1995 11:05:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA01677; Thu, 18 May 1995 11:05:56 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07607; Thu, 18 May 95 11:05:56 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id LAA22842; Thu, 18 May 1995 11:05:52 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id LAA14370; Thu, 18 May 1995 11:05:50 -0700 Received: from tubes.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:ben@vislab.su.edu.au id AA07575; Thu, 18 May 95 11:05:48 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA22538; Thu, 18 May 1995 11:03:14 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199505181803.LAA22538@tubes.asd.sgi.com> Subject: Re: NewpfuWidget: failed To: guest (Sharon Clay) Date: Thu, 18 May 95 11:03:13 PDT Cc: ben@vislab.su.edu.au, info-performer@sgi.sgi.com In-Reply-To: <9505040213.ZM9918@rose.asd.sgi.com>; from "Sharon Clay" at May 4, 95 2:13 am X-Mailer: ELM [version 2.3 PL8] Status: O > > +>---- On May 4, 6:13pm, Ben Simons wrote: > > Subject: NewpfuWidget: failed > -> > ->Has anyone got this one before?? > -> > ->Performer Warning: No VClock. Assuming 60Hz video rate > ->Performer Fatal: NewpfuWidget: failed to allocate widget 36 of type 0x11 in gui data pool. > > Hmmm. For some reason pfDPoolAlloc of the GUI data pool failed. > > -> > ->Seems to have happened since I added another button, > ->but I can't debug it as I think it's inside a library. > > FYI: the source code to the GUI in libpfutil is at > /usr/src/Performer/src/lib/libpfutil/gui.c > There is a bug in initUtilDPool() in libpfutil/gui.c which does not allocate enough datapool memory for the gui. The line PFUGUI_MAXWIDGETS * sizeof(pfuWidget) is bogus since pfuSlider is larger than pfuWidget. To see if this is your problem, simply double PFUGUI_MAXWIDGETS as a quick check. From guest Thu May 18 14:22:21 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA02697; Thu, 18 May 1995 14:00:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA02690; Thu, 18 May 1995 13:59:56 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17075; Thu, 18 May 95 13:59:56 -0700 Received: by rose.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA24224; Thu, 18 May 1995 13:59:36 -0700 Date: Thu, 18 May 1995 13:59:36 -0700 From: src@rose (Sharon Clay (Fischler)) Message-Id: <199505182059.NAA24224@rose.asd.sgi.com> To: info-performer@rose Subject: Fix for mulitple GUI panels Cc: performer@rose Status: O Torres Mario noted that multple GUI panels in Performer1.2 do not work. For a fix, make a simple addition to /usr/src/Performer/src/lib/libpfutil/gui.c. add to the pfuEnablePanel() and pfuDisablePanel() functions: { .... if (p != NULL) { pfDPoolLock(GUI->flags); GUI->flags->dirty = GUI->flags->redrawAll = GUI->refresh; pfDPoolUnlock(GUI->flags); ..... } ... } Thanx Torres! src. -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Graphics Dev. src@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Thu May 18 14:23:02 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA02712; Thu, 18 May 1995 14:03:56 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA02709; Thu, 18 May 1995 14:03:47 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17510; Thu, 18 May 95 14:03:39 -0700 Received: from mercury.arl.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA25186; Thu, 18 May 1995 14:03:26 -0700 Received: by mercury.arl.mil (4.1/SMI-4.1) id AA17214; Thu, 18 May 95 15:05:25 MDT From: mtorres@arl.mil (Torres Mario 678-3280 AMSRL-BE-M) Message-Id: <9505182105.AA17214@mercury.arl.mil> Subject: Light & Material's interaction! To: info-performer@sgi.sgi.com Date: Thu, 18 May 95 15:05:25 MDT X-Mailer: ELM [version 2.4dev PL17] Status: O I am currently working on quantifying the interaction of Ambient and Diffuse light and material properties to try and relate them to some physically correct models that we have. In a perfly hack I've set up a 4 face pyramid with each face having a different color: red, green, blue and white. I've also setup sliders to change the Materials ambient and diffuse colors and a toggle to switch between various Material Color Modes. The CONFUSING behavior: When I set the pfMtlColorMode to DIFFUSE and then vary the Mtl DIFFUSE color I see no apparent effect on the colors of my pyramid. HOWEVER, if I change the material AMBIENT color (with the PFMTL_CMODE_DIFFUSE), the pyramid's color are affected and change with changing of ambient color. Is this behavior normal? correct? Does it make sense that if the MaterialColorMode is PFMTL_CMODE_DIFFUSE the AMBIENT material colors are active? The same behavior is shown when I use the PFMTL_CMODE_AMBIENT. That is the pyramids colors are changed by changing the diffuse material colors and not the ambient material colors (as I would expect it). Another, goody: When I change to this PFMTL_CMODE_DIFFUSE mode from another mode (like PFMTL_CMODE_AMBIENT) the WHITE face of the pyramid turns BLACK. (Is there a force of opposites at work here? ;) I have many more questions which I can't find answers to, but I will restrain... I have read all the Performer documentation and only a couple of many possible ColorModes are briefly mentioned there. GL documentation was not of much help either. I did read the OpenGL Ch 6 on Lighting, however, are all the definitions contained therein valid for Performer? It seems to me that OpenGL is capable of much more than Performer is, in terms of lighting, shadows, etc. Can I depend on the lighting and material mathematical definitions given in the OpenGL literature and considered them to be same for Performer? Sorry, for having so many questions, I am hoping for a clue to any them. Thanks in advance, Mario A. Torres From guest Thu May 18 14:53:15 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA02831; Thu, 18 May 1995 14:38:46 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA02828; Thu, 18 May 1995 14:38:45 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19900; Thu, 18 May 95 14:38:40 -0700 Received: from gold.tc.umn.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id OAA03443; Thu, 18 May 1995 14:38:38 -0700 Received: by gold.tc.umn.edu; Thu, 18 May 95 16:38:29 -0500 Date: Thu, 18 May 1995 16:38:28 -0500 (CDT) From: Renee Maheshwari Subject: LOD calculations To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I am wondering how channel size affects how Performer calculates LOD range for a predefined object with LOD ranges. I have the following information: >Inside Performer for LOD switching, > > true range = (defined range) * (Lod Scale) * (Global Lod Scale) > > defined range is assumed to be for 1280x1024 at 45 Degree FOV > > Lod Scale is a multiplier calculated from channel size & actual FOV /\ Lod Scale || is what I have my question on... > Global Lod Scale is a global value per channel that is applied to all > LOD's The part below is the part I'm wondering about, which determines the Lod Scale---what are horz and vert on the right hand side of this equation??? Are they field of view? I'm assuming that xs and ys are the x and y channel size, but I may be wrong on that too. Also, is this horz and vert defined recursively, or is that some typo? > /* this came from the Performer Team and is how a channel size */ > /* affects the Lod Calculation */ > horz = (xs * 0.5f) / pfTan(horz * 0.5f); > vert = (ys * 0.5f) / pfTan(vert * 0.5f); > > max = PF_MAX2(horz, vert); What is TAN_MPI8????? > lodAspect2 = (512.0f / TAN_MPI8) / max; > > Lod Scale = (FOV/45) * (lodAspect2) Thanks in advance for any help Renee Maheshwari mahe0010@gold.tc.umn.edu From guest Thu May 18 18:09:46 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA03630; Thu, 18 May 1995 17:53:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA03627; Thu, 18 May 1995 17:53:23 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01264; Thu, 18 May 95 17:53:22 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA11541; Thu, 18 May 1995 17:53:19 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) for id RAA27767; Thu, 18 May 1995 17:53:18 -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 AA01253; Thu, 18 May 95 17:53:15 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id RAA25979; Thu, 18 May 1995 17:50:45 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199505190050.RAA25979@tubes.asd.sgi.com> Subject: Re: pfLayer polygons and the clipping plane To: guest (Todd R Pravata) Date: Thu, 18 May 95 17:50:44 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9505121714.AA27182@rts.dseg.ti.com>; from "Todd R Pravata" at May 12, 95 12:14 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > My loader uses pfLayer for the network (roads, rivers, etc.) polygons > in the scene. The underlying terrain forms the base and the roads are > decaled on top. Note the database is "tiled". The terrain and > network polygons for each 1K tile are placed in a single pfLayer node > for that tile. The network polygons are clipped to the tile boundary. > > I've noticed that the decaled polygons at the far clipping plane make > the cull before the base layer. So when there is a hill in the > distance coming into view with a road on it, first the roads stick up > with no terrain underneath, then the terrain comes in. Is this a > problem with bounding spheres? Do I need to force the bounding > spheres of the base and decal layer geometry to be the same? Or is > there something else going on here? > This is an artifact of the PFDECAL_BASE_DISPLACE method for rendering layers. The displace mechanism brings the roads closer to you so you see them before the ground. The only solution now is to use the higher quality, but slower stencil mechanism: pfLayerMode(layer, PFDECAL_BASE_STENCIL) From guest Thu May 18 18:24:11 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA03709; Thu, 18 May 1995 18:05:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA03706; Thu, 18 May 1995 18:05:31 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01781; Thu, 18 May 95 18:05:26 -0700 Received: from mane.cgrg.ohio-state.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id SAA13590; Thu, 18 May 1995 18:05:23 -0700 Received: from shershe.cgrg.ohio-state.edu (tmoeller@cgrg.ohio-state.edu) by mane.cgrg.ohio-state.edu (8.6.12/941010.52) with ESMTP id VAA07328 for ; Thu, 18 May 1995 21:05:21 -0400 Received: (from tmoeller) by shershe.cgrg.ohio-state.edu (940816.SGI.8.6.9/941010) id VAA26914 for info-performer@sgi.com; Thu, 18 May 1995 21:05:21 -0400 From: Torsten Moeller Message-Id: <199505190105.VAA26914@shershe.cgrg.ohio-state.edu> Subject: Performer Memory Handling bug? To: info-performer@sgi.sgi.com Date: Thu, 18 May 1995 21:05:20 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3370 Status: O I modified perfly for some VR application and I've been having trouble with it all along. Again some weird pointer error popped up and I could track it down to the following subroutine ---------------------------------------------------------------------- pfGroup* objectRead(FILE *stream, pfMaterial **mtl) { char command[200]; /* Input buffer to hold each command */ char *obj_name; /* the name of the object */ pfGroup *root; /* hold the actual object */ short material = -1; /* store the material index */ pfGeoState* gstate; /* to store info on material */ /**************************************************************************/ /* Parse input stream and pull out data for this object */ fscanf(stream, " %s", command); while((strcmp(command, objectEND_TAG) != 0) && !feof(stream)) { if(strcmp(command, "file:") == 0) { fscanf(stream, " %s", command); obj_name = strdup(command); printf("Test 1 = %s\n", command); printf("1:Name = %s\n", obj_name); } else if(strcmp(command, "material:") == 0) { fscanf(stream, " %hd", &material); } else { /* Else what is it? */ pfNotify(PFNFY_NOTICE, PFNFY_PRINT, "WARNING: Don't recognize command: \"%s\"", command); } fscanf(stream, " %s", command); } printf("2:Name = %s\n", obj_name); /* Check whether material was defined */ if ((material == -1) || (mtl[material] == NULL)) { pfNotify(PFNFY_NOTICE, PFNFY_PRINT, "WARNING: no material specified or specified material not\ defined yet."); } else { /* Apply Material to this object*/ gstate = pfNewGState(NULL); pfGStateMode(gstate, PFSTATE_ENLIGHTING, PF_ON); pfGStateMode(gstate, PFSTATE_TRANSPARENCY, PFTR_ON); pfGStateAttr(gstate, PFSTATE_FRONTMTL, mtl[material]); } printf("3:Name = %s\n", obj_name); /* Load the database. create a hierarchy under node "root" */ root = (pfGroup *)LoadObj(obj_name, gstate); printf("4:Name = %s\n", obj_name); free(obj_name); obj_name = NULL; pfDelete(gstate); gstate = NULL; return root; } ---------------------------------------------------------------------- The output is the following: Test 1 = /nfs/stegosaur/research/NIDRR/tmoeller/Wheelchair/Neue_Version/Data/Wavefront/Store-Textured3//retailclg.obj 1:Name = /nfs/stegosaur/research/NIDRR/tmoeller/Wheelchair/Neue_Version/Data/Wavefront/Store-Textured3//retailclg.obj 2:Name = /nfs/stegosaur/research/NIDRR/tmoeller/Wheelchair/Neue_Version/Data/Wavefront/Store-Textured3//retailclg.obj 3:Name = /nfs/stegosaur/research/NIDRR/tm Performer Warning (2): openFile: Could not find file "/nfs/stegosaur/research/NIDRR/tm" 4:Name = /nfs/stegosaur/research/NIDRR/tm meaning that in the middle of the program (when I apply some routines to gstate) some memory gets overridden. That's why I am assuming, that there is something wrong within the Performer libraries?! I am kindly asking, whether anybody could give me some suggestions, whether there might be something in my program, I have overlooked, or whether there are other people who had similar problems. In the end my program returns with a Segmentation fault while calling 'pfFrame'. Torsten Moeller. -- Research Assistant ACCAD tmoeller@cgrg.ohio-state.edu Ohio State University From guest Thu May 18 22:38:52 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA04291; Thu, 18 May 1995 22:21:19 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA04288; Thu, 18 May 1995 22:21:15 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10595; Thu, 18 May 95 22:21:07 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA10476; Thu, 18 May 1995 22:20:59 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id PAA03645 (8.6.11/IDA-1.6); Fri, 19 May 1995 15:19:14 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA28672 (5.65c/IDA-1.5); Fri, 19 May 1995 14:33:59 +1000 Received: from zippy (zippy [1.0.0.79]) by aggro with ESMTP id OAA09059 (8.6.12/IDA-1.6); Fri, 19 May 1995 14:36:16 +1000 Received: by zippy (8.6.11) id OAA13650; Fri, 19 May 1995 14:36:16 +1000 Date: Fri, 19 May 1995 14:36:14 +1000 (BEST) From: Simon Bennett X-Sender: simonb@zippy To: "`Bwana' Bob Buckley" Cc: info-performer@sgi.sgi.com Subject: Re: dynamic terrain In-Reply-To: <9505111108.ZM14314@getreal.mss.ctaeng.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Thu, 11 May 1995, `Bwana' Bob Buckley wrote: > > are free to write new values for your vertex information to memory. > > However, when multiprocessing you MUST multi-buffer your pfGeoSet data. When > updating vertex, normal, and texture coordinates in the app process you don't > want the draw process to render in the midst of an update. We just spawned a > separate rebuilding process and let the visuals continue to run typically at > 60Hz. Slightly off the topic question I'm afraid... But, I've always been led to believe that Performer 1.2 did not let processes forked off the application process modify the scenegraph... So either this is not true or "a separate rebuilding process [that] let the visuals continue to run typically at 60Hz. " did not directly modify the scenegraph and achieved this some other way. Maybe I've missed something here. Thanx. +--------------------------------------------------------------------------------+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 981 0611 (x512) Computer Terms: hardware - the part of a computer system that one can kick From guest Fri May 19 02:36:27 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA04503; Fri, 19 May 1995 02:13:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA04500; Fri, 19 May 1995 02:13:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00633; Fri, 19 May 95 02:12:36 -0700 Received: from david.zfe.siemens.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA25274; Fri, 19 May 1995 02:12:52 -0700 From: epp@d019f063.zfe.siemens.de Received: from ztivax.zfe.siemens.de by david.zfe.siemens.de with SMTP id AA09248 (5.67a/IDA-1.5 for ); Fri, 19 May 1995 11:12:36 +0200 Received: from D019F063.zfe.siemens.de (d019f063) by ztivax.zfe.siemens.de with SMTP id AA05015 (5.67a/IDA-1.5 for ); Fri, 19 May 1995 11:12:35 +0200 Received: from PGTF0006.z6 by D019F063.zfe.siemens.de (4.1/SMI-4.1) id AA18737; Fri, 19 May 95 11:10:38 +0200 Date: Fri, 19 May 95 11:10:38 +0200 Message-Id: <9505190910.AA18737@D019F063.zfe.siemens.de> To: info-performer@sgi.sgi.com Subject: unsubscribe Status: O Please unsubscribe me from your mailing list. Thanks for all, -Erwin From guest Fri May 19 04:02:06 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA04762; Fri, 19 May 1995 03:38:11 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA04759; Fri, 19 May 1995 03:38:10 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01588; Fri, 19 May 95 03:36:27 -0700 Received: from amalia.rz.uni-frankfurt.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA29441; Fri, 19 May 1995 03:38:04 -0700 Message-Id: <199505191038.DAA29441@sgi.sgi.com> Received: from rz.uni-frankfurt.de by brion.rz.uni-frankfurt.de id <37347-0@brion.rz.uni-frankfurt.de>; Fri, 19 May 1995 12:33:41 +0000 Subject: unsubscribe To: info-performer@sgi.sgi.com Date: Fri, 19 May 1995 12:33:34 +0200 (CST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 56 From: Michael Saup Sender: Saup@em.uni-frankfurt.de Status: O please unsubscribe me off your mailing list. thank you. From guest Fri May 19 05:03:37 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id EAA05206; Fri, 19 May 1995 04:38:52 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id EAA05203; Fri, 19 May 1995 04:38:52 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02262; Fri, 19 May 95 04:36:17 -0700 Received: from bvr.co.il by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id EAA02139; Fri, 19 May 1995 04:38:36 -0700 Received: from amcor.bvr.co.il by bvr.co.il via SMTP (920330.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA06587; Fri, 19 May 95 14:44:34 +0300 Received: by amcor.bvr.co.il (940816.SGI.8.6.9/911001.SGI) for info-performer@sgi.com id OAA04249; Fri, 19 May 1995 14:35:48 +0300 From: "Ran Yakir" Message-Id: <9505191435.ZM4247@amcor.bvr.co.il> Date: Fri, 19 May 1995 14:35:46 +0000 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfLayer Culling Problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi, I've noticed a strange behaviour of pfLayers. In my application I create pfLayers after loading Flight format file. i.e. I traverse through the scene graph and create new layers in certain places. Those layers replace other nodes which are removed from the scene graph. The strange thing is that after I update the graph, the sub-graphs, which are under the layer nodes are not cull-tested properly. When I look on the polygon count in the chan stats, I see that they are tested against the far clipping plane, but not against the other faces of the viewing frustum. i.e. I can direct my eyepoint to the sky, or to the end of the world, and those nodes are still drawn, and, ofcourse affect my precious hertzes ... I've tried to modify all bounding volumes for everything after I add the layers, to no avail. However, when I create my own 'layers', meaning that I implement decaling with draw callbacks in the appropriate nodes, everything becomes normal again. the addinional nodes (now pfGroups instead of pfLayers) are culled properly and my hertzes are almost intact. Is there something I'm missing here ? If its indeed a bug, will it be fixed in Performer 2.0 ? Thanks Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-9-989974 | Fax : 972-3-5715668 | From guest Fri May 19 08:22:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA05613; Fri, 19 May 1995 08:01:25 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA05610; Fri, 19 May 1995 08:01:24 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04900; Fri, 19 May 95 07:55:37 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id IAA20511; Fri, 19 May 1995 08:01:19 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id IAA19126; Fri, 19 May 1995 08:01:17 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:murtland@martinique.ndhm.gtegsc.com id AA04885; Fri, 19 May 95 07:55:25 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id IAA14406; Fri, 19 May 1995 08:00:59 -0700 Message-Id: <199505191500.IAA14406@surreal.asd.sgi.com> Cc: murtland@martinique.ndhm.gtegsc.com, angus@reading.sgi.com, info-performer@sgi.sgi.com Subject: Re: Fix to Inventor Loader for Large Databases In-Reply-To: Your message of "Wed, 17 May 95 13:38:57 PDT." <199505172038.NAA20174@surreal.asd.sgi.com> Date: Fri, 19 May 95 08:00:59 -0700 From: Jim Helman Status: O Whoops. The freeTris() routine needed to be changed as well, since it makes assumptions about the chunksize. Here's the complete fix. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 #define TRICHUNK 128 /* initial allocation size */ #define MAXTRICHUNK 8192 /* maximum allocation size */ static void freeTris(pfdGeoBuilder *bldr) { pfdPrim *tri; int chunkSize = TRICHUNK; static int FreedTris = 0; /* Free linked list of triangle chunks */ tri = bldr->triList; do { pfdPrim *next; next = tri[chunkSize-1].next; pfFree(tri); FreedTris++; tri = next; chunkSize <<= 1; if (chunkSize > MAXTRICHUNK) chunkSize >>= 1; } while (tri != bldr->triList); } static pfdPrim * getPrim(pfdGeoBuilder *bldr) { pfdPrim *t = NULL; int chunkSize = TRICHUNK; int newChunkSize = 0; /* * Create and link in a new chunk of triangles whose size is twice * the size of the previous chunk. Use last triangle in chunk as link. */ if (bldr->availTri->flags == LINK_TRI) { if (bldr->availTri->next == bldr->triList) { /* determine old chunk size */ t = bldr->triList; while (&t[chunkSize-1] != bldr->availTri) { t = t[chunkSize-1].next; chunkSize <<= 1; if (chunkSize > MAXTRICHUNK) chunkSize >>= 1; } /* determine new chunk size */ newChunkSize = chunkSize << 1; if (newChunkSize > MAXTRICHUNK) newChunkSize >>= 1; bldr->availTri = t[chunkSize-1].next = pfCalloc(newChunkSize, sizeof(pfdPrim), NULL); pfAdd(bldr->mallocList,bldr->availTri); /* Point last tri in chunk to head of linked list */ t = &bldr->availTri[newChunkSize-1]; t->next = bldr->triList; t->flags = LINK_TRI; } else bldr->availTri = bldr->availTri->next; } t = bldr->availTri; bldr->availTri++; return t; } From guest Fri May 19 08:37:43 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA05629; Fri, 19 May 1995 08:12:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA05626; Fri, 19 May 1995 08:12:49 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05091; Fri, 19 May 95 08:06:46 -0700 Received: from FALCON.AL.WPAFB.AF.MIL by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA22031; Fri, 19 May 1995 08:12:35 -0700 From: JHUANG@FALCON.AL.WPAFB.AF.MIL Received: from AL-Message_Server by FALCON.AL.WPAFB.AF.MIL with WordPerfect_Office; Fri, 19 May 1995 11:12:15 -0400 Message-Id: X-Mailer: WordPerfect Office 4.0 Date: Fri, 19 May 1995 11:11:16 -0400 To: info-performer@sgi.sgi.com Subject: unsubscribe Status: O unsubscribe From guest Fri May 19 10:31:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA05871; Fri, 19 May 1995 10:15:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA05868; Fri, 19 May 1995 10:15:30 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA09515; Fri, 19 May 95 10:15:20 -0700 Received: from meg.saic.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA14417; Fri, 19 May 1995 10:15:20 -0700 Received: by meg.saic.com (4.1/SMI-4.1) id AA08677; Fri, 19 May 95 10:22:37 PDT Date: Fri, 19 May 95 10:22:37 PDT From: mccoll@meg.saic.com (David McColl) Message-Id: <9505191722.AA08677@meg.saic.com> To: info-performer@sgi.sgi.com Subject: unsubscribe Status: O unsubscribe performer@meg.saic.com I am the last person using this mail forwarder. I am going so it can stop getting mail. Thanks, it was fun. +-----------------------------------------------------------------------+ | David McColl email:(unix) mccoll@meg.saic.com | | SAIC Virtual Reality Systems Div (mac)David_McColl@cpqm.saic.com | | 10260 Campus Point Drive PHONE: (619) 546-6286 | | San Diego, CA 92121 FAX: (619) 535-7907 | +-----------------------------------------------------------------------+ From guest Fri May 19 12:26:01 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA06073; Fri, 19 May 1995 12:05:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA06070; Fri, 19 May 1995 12:05:24 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16594; Fri, 19 May 95 12:05:18 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA08949; Fri, 19 May 1995 12:05:16 -0700 Received: from eclipse.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA04444; Fri, 19 May 95 15:06:58 EDT Received: by eclipse.vsl.ist.ucf.edu (4.1) id AA23744; Fri, 19 May 95 15:04:32 EDT Date: Fri, 19 May 1995 15:04:31 -0400 (EDT) From: "Lance R. Marrou" To: Simon Bennett Cc: "`Bwana' Bob Buckley" , info-performer@sgi.sgi.com Subject: Re: dynamic terrain In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Fri, 19 May 1995, Simon Bennett wrote: > On Thu, 11 May 1995, `Bwana' Bob Buckley wrote: > > > > are free to write new values for your vertex information to memory. > > > > However, when multiprocessing you MUST multi-buffer your pfGeoSet data. When > > updating vertex,normal, and texture coordinates in the app process you don't > > want the draw process to render in the midst of an update. We just spawned a > > separate rebuilding process and let the visuals continue to run typically at > > 60Hz. > > Slightly off the topic question I'm afraid... > > But, I've always been led to believe that Performer 1.2 did not let processes > forked off the application process modify the scenegraph... So either this > is not true or "a separate rebuilding process [that] let the visuals continue > to run typically at 60Hz. " did not directly modify the scenegraph and > achieved this some other way. Maybe I've missed something here. The spawned process modifies the geoset data: "vertex, normal, and texture coordinates". The terrain geosets, geodes, and other structures are allocated before the rebuilding process is forked. You should immediately notice a possible conflict in modifying visual data at this low level. However, some synchronization locks are built in and only the original app process issues the changes to pfSwitch nodes. The draw process is never held up, though a possible 2 frame delay may occur in the data update. Things change a little bit with the pfCycleBuffer structure in 2.0, but that's a topic that can wait until 2.0's release. :) ______________________________________________________________________________ /\ ______ /\____ ______ ______ E-mail: marrou@vsl.ist.ucf.edu Visual / / / _ / / __ // ____// ____/ VSL: (407)658-5073 Systems / /__ / /_/ / / / / // /___ / __/_ R. Marrou Fax: (407)658-5059 Lab /____//____/\\/_/ /_//_____//_____/ http://www.vsl.ist.ucf.edu/~marrou "Reap the whirlwind." "We don't need no thought control." From guest Fri May 19 12:30:39 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA06084; Fri, 19 May 1995 12:09:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA06081; Fri, 19 May 1995 12:09:17 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16909; Fri, 19 May 95 12:09:15 -0700 Received: from ctaeng.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA09950; Fri, 19 May 1995 12:09:12 -0700 Received: from support.ctaeng.com by ctaeng.com (4.1/SMI-4.1) id AA28704; Fri, 19 May 95 13:08:40 MDT Received: from getreal.mss.ctaeng.com by support.ctaeng.com (5.0/SMI-SVR4) id AA09013; Fri, 19 May 1995 13:08:40 -0600 Received: by getreal.mss.ctaeng.com (931110.SGI/920502.SGI.AUTO) for @support.ctaeng.com:info-performer@sgi.com id AA03521; Fri, 19 May 95 13:09:35 -0600 From: "`Bwana' Bob Buckley" Message-Id: <9505191309.ZM3519@getreal.mss.ctaeng.com> Date: Fri, 19 May 1995 13:09:30 -0600 In-Reply-To: Simon Bennett "Re: dynamic terrain" (May 19, 2:36pm) References: X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Simon Bennett Subject: Re: dynamic terrain Cc: marrou@vsl.ist.ucf.edu, info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 2390 Status: O Hi Simon! On May 19, 2:36pm, Simon Bennett wrote: > Subject: Re: dynamic terrain > > But, I've always been led to believe that Performer 1.2 did not let processes > forked off the application process modify the scenegraph... So either this > is not true or "a separate rebuilding process [that] let the visuals continue > to run typically at 60Hz. " did not directly modify the scenegraph and > achieved this some other way. Maybe I've missed something here. > libpr objects can be created and modified safely in processes forked off of the application process. libpf objects, which use a global structure, cannot be safely created from such a process. The only safe way to modify libpf objects created prior to the fork would be to enforce mutual exclusion via locks or semaphores. However, there are certain routines that should only be run from the application process (pfDelete). Check out the programmers guide under Successful Multiprocessing with Iris Performer. To implement our Dynamic Terrain the whole scene graph is created (multi- buffered) prior to the fork and throughout the simulation run the complete structure never changes. Only the pfGeoSet (libpf) data changes including texture, normal, and vertex coordinates. Also, the parent pfGeode's bounding sphere is forced to recompute. Which makes me realize two things: 1) I don't have any mutual exclusion access to the parent pfGeode (Bad, Bad, Bad Programmer!!) and 2) a forced recomputation of a bounding sphere of one of my pfGeodes, although set as dynamic, might not force an upward propogation of the bounding sphere recomputation. According to the man page for pfNodeBSphere only additions, deletions, and matrix changes force the upward propogation through pfGroups. But, it works! So, the man page may not address the complete set of circumstances for an upward propogation of recomputing bounding spheres. =========================================================================== 'Bwana' Bob Buckley CTA, Inc. Sr. Software Engineer 5670 Greenwood Plaza Blvd Visual Systems Englewood, CO 80111 (303) 889-1207 (303) 889-1200 bbuckley@ctaeng.com (303) 889-1398 Fax =========================================================================== From guest Fri May 19 14:15:43 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA06504; Fri, 19 May 1995 13:52:13 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA06501; Fri, 19 May 1995 13:52:12 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22309; Fri, 19 May 95 13:52:04 -0700 Received: from elaine.crcg.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id NAA20533; Fri, 19 May 1995 13:52:01 -0700 Received: by elaine.crcg.edu (4.1/SMI-4.1) id AA28579; Fri, 19 May 95 16:52:48 EST Date: Fri, 19 May 95 16:52:48 EST From: shaas@crcg.edu (Stefan Haas) Message-Id: <9505192152.AA28579@elaine.crcg.edu> To: info-performer@sgi.sgi.com Status: O unsubscribe shaas@crcg.edu From guest Sun May 21 22:07:53 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA09850; Sun, 21 May 1995 21:39:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA09847; Sun, 21 May 1995 21:39:58 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04608; Sun, 21 May 95 21:39:57 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id VAA07779; Sun, 21 May 1995 21:39:55 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id VAA11362; Sun, 21 May 1995 21:39:53 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:tmoeller@cgrg.ohio-state.edu id AA04600; Sun, 21 May 95 21:39:39 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id VAA20801; Sun, 21 May 1995 21:39:39 -0700 Message-Id: <199505220439.VAA20801@surreal.asd.sgi.com> To: Torsten Moeller Cc: info-performer@sgi.sgi.com Subject: Re: Performer Memory Handling bug? In-Reply-To: Your message of "Thu, 18 May 95 21:05:20 EDT." <199505190105.VAA26914@shershe.cgrg.ohio-state.edu> Date: Sun, 21 May 95 21:39:34 -0700 From: Jim Helman Status: O The problem isn't clear. Performer doesn't diddle its caller's stack. It would be interesting to know which of the geostate attribute setting calls is causing the problem. The only cause I can think of is that the material pointer (mtl[material]) is incorrectly pointing to something on the stack instead of to something returned by pfNewMtl(). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sun May 21 22:26:53 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA09858; Sun, 21 May 1995 21:55:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA09855; Sun, 21 May 1995 21:55:41 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04789; Sun, 21 May 95 21:55:36 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id VAA08366; Sun, 21 May 1995 21:55:19 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id VAA11837; Sun, 21 May 1995 21:55:15 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:rany@amcor.bvr.co.il id AA04764; Sun, 21 May 95 21:54:57 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id VAA20863; Sun, 21 May 1995 21:54:44 -0700 Message-Id: <199505220454.VAA20863@surreal.asd.sgi.com> To: "Ran Yakir" Cc: info-performer@sgi.sgi.com Subject: Re: pfLayer Culling Problems In-Reply-To: Your message of "Fri, 19 May 95 14:35:46 -0000." <9505191435.ZM4247@amcor.bvr.co.il> Date: Sun, 21 May 95 21:54:40 -0700 From: Jim Helman Status: O pfLayer::cull is virutally identical to pfGroup::cull and all of the methods related to bounding volumes are inherited directly. So I have no explanation for the behavior you see. If it weren't for your saying that it works with a pfGroup, I would suspect that that "far-plane-only" culling that you see with pfLayer's is in fact the result of excessively large bounding volumes caused by a 1.2's sqrt(3) bounding volume bloat problem. I don't know of any culling bugs in 1.2. I'd suggest using pfPrint to check the bounding sphere of the pfLayer and its children against the eye point/frustum. Are they the same size as with the pfGroup? If you verify that the pfLayer is not culled even when its bounding sphere is completely outside the frustum, reduce it to a simple test case, so we can check it out. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sun May 21 22:33:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA09868; Sun, 21 May 1995 22:06:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA09865; Sun, 21 May 1995 22:06:16 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04979; Sun, 21 May 95 22:06:11 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id WAA08919; Sun, 21 May 1995 22:06:09 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id WAA12426; Sun, 21 May 1995 22:06:07 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:Slimane.Merzouk@loria.fr id AA04970; Sun, 21 May 95 22:05:57 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA20881; Sun, 21 May 1995 22:05:52 -0700 Message-Id: <199505220505.WAA20881@surreal.asd.sgi.com> To: "Slimane Merzouk" Cc: info-performer@sgi.sgi.com Subject: Re: levels of details In-Reply-To: Your message of "Thu, 18 May 95 11:30:44 MDT." <9505181130.ZM8325@boudot.loria.fr> Date: Sun, 21 May 95 22:05:48 -0700 From: Jim Helman Status: O Note that Performer itself does not (yet!) do any simplification of model geometry. Performer relies on the modeler to have provided multiresolution models of the object. Vis sim modelers like Coryphaues DWB and Multigen have LOD construction tools. I believe that one of Wavefront's modelers also has some interactive model simplification capabilities. Simplyfing patch-based models is pretty straightforward down to around the scale of the patches, i.e. just retessellate. Polygonal data is harder to deal with. Some research has been done on automatically generating simpler models from polygonal data. I've listed some of the articles below. Also, although I don't have references, Michael Garland and Paul Heckbert are doing some work in the area as well. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 @INPROCEEDINGS{Hopp93a, AUTHOR = "Hughes Hoppe and Tony DeRose and Tom DuChamp and John McDonald and Werner Stuetzle", TITLE = "Mesh optimization", BOOKTITLE = "SIGGRAPH 93 Conference Proceedings (Computer Graphics, Annual Conference Series 1993)", MONTH = Aug, YEAR = 1993, PAGES = "19-26"} @INPROCEEDINGS{Hopp94a, AUTHOR = "Hughes Hoppe and Tony DeRose and Tom DuChamp and M. Halstead and H. Jin and John McDonald and J. Schweitzer and Werner Stuetzle", TITLE = "Piecewise smooth surface reconstruction", BOOKTITLE = "SIGGRAPH 94 Conference Proceedings (Computer Graphics, Annual Conference Series 1994)", MONTH = Jul, YEAR = 1994, PAGES = "19-26"} @INPROCEEDINGS{Maci95a, AUTHOR = "Paulo W. C. Maciel and Peter Shirley", TITLE = "Visual Navigation of Large Environments Using Textured Clusters", BOOKTITLE = "Proceedings 1995 Symposium on Interactive 3D Graphics", MONTH = Jun, YEAR = 1995, PAGES = "95-102" } @INPROCEEDINGS{Ross93a, AUTHOR = "Jarek Rossignac and P. Borrel", BOOKTITLE = "Second Conference on Geometric Modelling in Computer Graphics", TITLE = "Multi-resolution 3{D} approximation for rendering complex scenes", PAGES = "453--465", MONTH = jun, YEAR = "1993", NOTE = "Genova, Italy", BIBSOURCE = "sig-11-1994", } @INPROCEEDINGS{Schr93a, AUTHOR = "William J. Schroeder, Jonathan A. Zarge, William E. Lorensen", TITLE = "Decimation of Triangle Meshes", BOOKTITLE = "SIGGRAPH 93 Conference Proceedings (Computer Graphics, Annual Conference Series 1993)", MONTH = Aug, YEAR = 1993, PAGES = "65-70"} @ARTICLE{Turk92a, AUTHOR = "Greg Turk", TITLE = "Re-Tiling Polygonal Surfaces", JOURNAL = "Computer Graphics (Proceedings SIGGRAPH '92)", VOLUME = 26, NUMBER = 2, MONTH = Aug, YEAR = 1992, PAGES = "55-64" } From guest Sun May 21 22:35:26 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA09885; Sun, 21 May 1995 22:12:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA09882; Sun, 21 May 1995 22:12:17 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05041; Sun, 21 May 95 22:12:09 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id WAA09307; Sun, 21 May 1995 22:12:07 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id WAA12582; Sun, 21 May 1995 22:12:05 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:kishore@electrogig.com id AA05035; Sun, 21 May 95 22:11:54 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA20907; Sun, 21 May 1995 22:11:46 -0700 Message-Id: <199505220511.WAA20907@surreal.asd.sgi.com> To: "AnitaKishore" Cc: info-performer@sgi.sgi.com Subject: Re: usage of engines in Inventor file format through Performer In-Reply-To: Your message of "Wed, 17 May 95 15:16:55 PDT." <9505171516.ZM7917@lee.electrogig.com> Date: Sun, 21 May 95 22:11:46 -0700 From: Jim Helman Status: O The best way to create Inventor-like engines or to embed custom behaviors in the scene graph is to have the loader define node traversal callbacks that emulate them. In 1.2, these callbacks would either have to be CULL callbacks or callbacks handled in a user traversal (see libpfutil/trav.c). We expect that 2.0 will support an APP traversal to handle these things automatically. In the release after 2.0, Performer will support fields and engines very much like Inventor's. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon May 22 01:32:20 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id BAA10260; Mon, 22 May 1995 01:21:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id BAA10257; Mon, 22 May 1995 01:21:35 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07384; Mon, 22 May 95 01:21:33 -0700 Received: from nordwest.pop.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id BAA19695; Mon, 22 May 1995 01:21:29 -0700 Received: from pink.atlas.de by nordwest.pop.de with smtp (Smail3.1.28.1 #6) id m0sDShj-00026TC; Mon, 22 May 95 10:19 MES Received: from tyrann.atlas.de mygate by pink.atlas.de (4.1/GEN-1.0.7) via CASEnet for mail.nordwest.pop.de id AA02625; Mon, 22 May 95 10:14:38 +0200 Received: by tyrann.atlas.de (5.65/Ultrix3.0-C) id AA01122; Mon, 22 May 1995 10:16:46 GMT Date: Mon, 22 May 1995 10:16:45 +0000 (GMT-1:00) From: E-Hendon To: info-performer@sgi.sgi.com Subject: pfuBuilder Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi! Does the Builder (specifically pfuMakeGSets) cause a calculation of the Bounding boxes for the Geosets? I have a problem with culling of large triangles. In pfChanTravMode PFCULL_VIEW a triangle may disappear while its right under the viewer's nose, so to speak. When PFCULL_VIEW is off (just sort and test the Geosets), this problem goes away. Of course I do not like culling this way. Any Ideas? Thanks --------------------------------------------------------------------------- E. Hendon STN-Atlas Elektronik GmbH Simulation Division Sebaldsbruecker Heerstr. 235, D-28305 Bremen email: elke@tyrann.atlas.de Telefon: 0421/457 3122 --------------------------------------------------------------------------- From guest Mon May 22 06:02:22 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA10468; Mon, 22 May 1995 05:42:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA10465; Mon, 22 May 1995 05:42:08 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11773; Mon, 22 May 95 05:42:03 -0700 Received: from malmo.trab.se by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA01786; Mon, 22 May 1995 05:41:59 -0700 Received: from trm.malmo.trab.se by malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Mon, 22 May 95 14:41:57 +0200 (MET) From: Erland Unruh Received: by trm.malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Mon, 22 May 95 14:41:56 +0200 (MET) Date: Mon, 22 May 95 14:41:56 +0200 Message-Id: <9505221241.AA03323@trm.malmo.trab.se> To: info-performer@sgi.sgi.com Subject: DisneyVision, how? Status: O Hi, I'm currently getting started on a project which share some ideas with DisneyVision, of course at a very small fraction of their resources. I'm pretty new to SGI, Performer, animation, 3D modelling etc. But I have been working with related stuff, so I belive it's feasable. To narrow down this new big world that's opening up, I wonder if someone could help me and describe, at a very high level, the steps needed to: * Get dynamic (animated, moving) objects onto Performer Other things I'm thinking of is suitable tools for creating simple "cartoon towns" or 3D modelling. Tools for creating basic animated characters? (Would be great with sound here as well.) Any other helpful comments? (I know that this is a big task to take on, but the primary goal for the moment is to show that it's feasable to do something like this in a small pilot project. If it works, we can scale it up after that.) Thanks! Erland Unruh ------------------------------------------------------------------------ Telia Research Box 85, S-201 20 Malmo, Sweden Email: eu@malmo.trab.se ------------------------------------------------------------------------ From guest Mon May 22 07:01:15 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA10534; Mon, 22 May 1995 06:38:48 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA10531; Mon, 22 May 1995 06:38:43 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12569; Mon, 22 May 95 06:38:37 -0700 Received: from igate by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA06081; Mon, 22 May 1995 06:38:35 -0700 Received: by igate (5.x/SMI-SVR4) id AA10901; Mon, 22 May 1995 09:38:01 -0400 Date: Mon, 22 May 1995 09:38:01 -0400 From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9505221338.AA10901@igate> To: info-performer@sgi.sgi.com Subject: timings: ada vs. C Status: O Hi, A while back I asked for a fast way to draw a background for some models that were being handled by performer. The lrectread, and lrectwrite routines were suggested, and implemented. They are slower than I wanted (about 400 mS each call), but I have used them. I have also used them in a different program and have them running about 80 mS per call. This program is in C (The original is written in ada to meet program requirements). I cannot see why there is such a pronounced difference in speed. They are both full screen extents (Indigo-2 Extreme 1280x1024). They both run on the same machine. I thought at first that the problem could be the ada binding supplied for gl, but I wrote my own interface to the routine, and got the same speed. I don't know how many of you are using ada out there (Writing ada bindings for all the Performer routines we used was a huge headache), but if someone has any help on this problem I would appreciate it. Thanks Mike Williams mwilliam@ldsa.com From guest Mon May 22 07:18:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA10543; Mon, 22 May 1995 06:57:01 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA10540; Mon, 22 May 1995 06:57:00 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12865; Mon, 22 May 95 06:57:00 -0700 Received: from titanium.rec.ri.cmu.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA07444; Mon, 22 May 1995 06:56:58 -0700 Received: (from wangw@localhost) by titanium.rec.ri.cmu.edu (8.6.11/8.6.11) id NAA28511 for info-performer@sgi.com; Mon, 22 May 1995 13:56:56 GMT Date: Mon, 22 May 1995 13:56:56 GMT From: Waylon Wang Message-Id: <199505221356.NAA28511@titanium.rec.ri.cmu.edu> To: info-performer@sgi.sgi.com Subject: mailing group Status: O HI, Please remove me from the group with the name: wangw@cs.cmu.edu But resubscribe me to a new email address: wangw@frc2.frc.ri.cmu.edu The first address doesn't have enough disk space to handle the amount of mailing list mails. Thanks! Waylon _______________________________________________________________________________ Waylon Wang Field Robotics Center Robotics Institute Carnegie Mellon University Pittsburgh, PA 15213 (412)268-6554 From guest Mon May 22 09:49:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA10821; Mon, 22 May 1995 09:35:27 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA10818; Mon, 22 May 1995 09:35:27 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17411; Mon, 22 May 95 09:35:16 -0700 Received: from palladium.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA27765; Mon, 22 May 1995 09:35:14 -0700 Received: from giraffe.asd.sgi.com by palladium.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for id JAA05361; Mon, 22 May 1995 09:35:12 -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 AA17403; Mon, 22 May 95 09:35:10 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA14180; Mon, 22 May 1995 09:32:50 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199505221632.JAA14180@tubes.asd.sgi.com> Subject: Re: pfLayer Culling Problems To: guest (Ran Yakir) Date: Mon, 22 May 95 9:32:50 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9505191435.ZM4247@amcor.bvr.co.il>; from "Ran Yakir" at May 19, 95 2:35 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > Hi, > > I've noticed a strange behaviour of pfLayers. In my application I create > pfLayers after loading Flight format file. i.e. I traverse through the scene > graph and create new layers in certain places. Those layers replace other nodes > which are removed from the scene graph. The strange thing is that after I > update the graph, the sub-graphs, which are under the layer nodes are not > cull-tested properly. When I look on the polygon count in the chan stats, I see > that they are tested against the far clipping plane, but not against the other > faces of the viewing frustum. i.e. I can direct my eyepoint to the sky, or to > the end of the world, and those nodes are still drawn, and, ofcourse affect my > precious hertzes ... > I've tried to modify all bounding volumes for everything after I add the > layers, to no avail. > > However, when I create my own 'layers', meaning that I implement decaling with > draw callbacks in the appropriate nodes, everything becomes normal again. the > addinional nodes (now pfGroups instead of pfLayers) are culled properly and my > hertzes are almost intact. > > Is there something I'm missing here ? > If its indeed a bug, will it be fixed in Performer 2.0 ? In 1.2, pfLayer children were not cull-tested if the pfLayer was partially visible. This was a cull optimization based on the presumed spatial coherency of layers but one which might draw unnecessary geometry. This "feature" has been removed from 2.0. From guest Mon May 22 10:16:06 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA10920; Mon, 22 May 1995 10:12:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA10917; Mon, 22 May 1995 10:12:33 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19514; Mon, 22 May 95 10:12:32 -0700 Received: from ciup1.ncc.up.pt by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA05145; Mon, 22 May 1995 10:11:36 -0700 Received: from garf.fe.up.pt (garfield.fe.up.pt) by ciup1.ncc.up.pt with SMTP id AA20647 (5.65c/IDA-1.4.4 for ); Mon, 22 May 1995 19:11:17 +0200 Received: from onyx (onyx.fe.up.pt) by garf.fe.up.pt with SMTP id AA22318 (5.65c/IDA-1.4.4 for <@garfield:info-performer@sgi.com>); Mon, 22 May 1995 19:09:06 +0100 Received: by onyx (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id MAA17415; Mon, 22 May 1995 12:11:18 -0700 Date: Mon, 22 May 1995 12:11:18 -0700 From: acoelho@onyx.fe.up.pt (Antonio Castro Coelho) Message-Id: <199505221911.MAA17415@onyx> To: info-performer@sgi.sgi.com Subject: Unsubscribe Status: O Please unsubscribe me. From guest Mon May 22 15:58:59 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA12623; Mon, 22 May 1995 15:44:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA12620; Mon, 22 May 1995 15:44:22 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12795; Mon, 22 May 95 15:08:28 -0700 Received: from paradox.idec.sdl.usu.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA13381; Mon, 22 May 1995 15:44:13 -0700 Received: by paradox.idec.sdl.usu.edu (931110.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA05030; Mon, 22 May 95 16:43:56 -0600 From: "Darin C. Partridge" Message-Id: <9505221643.ZM5028@paradox.idec.sdl.usu.edu> Date: Mon, 22 May 1995 16:43:55 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Shared Memory Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O The following code can be found in generic.c: ******************************************************* /* Get pointer to shared memory malloc arena created by pfInit()*/ arena = pfGetSharedArena(); /* * Malloc structures now, before pfConfig(), so forked processes have same * pointers. */ ViewState = (SharedViewState *) pfCalloc(1, sizeof(SharedViewState), arena); ******************************************************* My question is, can I get a pointer to "ViewState" from a completely unrelated process. I want to run a completely seperate process that can monitor/update items in this structure. Thanks for any help/code, Darin -- _ _ __(_)__ ,,, __(_)__ (_______) (o o) (_______) | |-------------------------------------oOO--(_)--OOo--| | | | Darin C. Partridge _________ | | | | Space Dynamics Laboratory (CSD) | | | | | | 1695 North Research Parkway | Gone | | | | | Logan, UT 84321 | Fishing | | | | | |_________| | | | | Voice: (801) 755-4348 ____________ | | | | Fax: (801) 755-4366 /___________/ | | | | Email: darin@sdl.usu.edu | | |_____|----------------------------------------------------|_____| (_____) (http://www.csd.sdl.usu.edu/darin_exec/homedoc) (_____) (_) (_) From guest Mon May 22 17:21:45 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA13246; Mon, 22 May 1995 17:05:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA13243; Mon, 22 May 1995 17:05:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18833; Mon, 22 May 95 17:05:01 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id RAA29916; Mon, 22 May 1995 17:04:59 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id RAA18750; Mon, 22 May 1995 17:04:57 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:darin@paradox.idec.sdl.usu.edu id AA18822; Mon, 22 May 95 17:04:53 -0700 Received: by rose.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id RAA23781; Mon, 22 May 1995 17:04:49 -0700 From: "Sharon Clay (Fischler)" Message-Id: <9505221704.ZM23779@rose.asd.sgi.com> Date: Mon, 22 May 1995 17:04:48 -0700 In-Reply-To: "Darin C. Partridge" "Shared Memory" (May 22, 4:43pm) References: <9505221643.ZM5028@paradox.idec.sdl.usu.edu> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Darin C. Partridge" , info-performer@sgi.sgi.com Subject: Re: Shared Memory Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On May 22, 4:43pm, Darin C. Partridge wrote: > Subject: Shared Memory ->The following code can be found in generic.c: -> ->******************************************************* -> ->/* Get pointer to shared memory malloc arena created by pfInit()*/ -> arena = pfGetSharedArena(); -> -> /* -> * Malloc structures now, before pfConfig(), so forked processes have same -> * pointers. -> */ -> ViewState = (SharedViewState *) pfCalloc(1, sizeof(SharedViewState), ->arena); -> ->******************************************************* -> ->My question is, can I get a pointer to "ViewState" from a completely ->unrelated process. I want to run a completely seperate process that can ->monitor/update items in this structure. This is exactly the situation that pfDataPools exist for. Look at the pfDataPool man page. You will allocate your ViewState structure with a set ID out of a named pfDataPool. Unrelated processes will be able to attach to the pfDataPool, find the item with the known ID, and then read/write it. Locking facilities exist for all ID-ed items in a pfDataPool. For a detailed example, you can look in /usr/src/Performer/src/lib/libpfutil The GUI and input handling utilities use a data pool for their shared data. The data pool is created in shmem.c and in gui.c the getGUIDataPool() routine attaches to the GUI data pool. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Graphics Dev. src@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue May 23 09:21:14 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA16430; Tue, 23 May 1995 08:52:59 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA16427; Tue, 23 May 1995 08:52:59 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21959; Tue, 23 May 95 08:52:58 -0700 Received: from itiasrvr.itia.mi.cnr.it by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA21779; Tue, 23 May 1995 08:51:29 -0700 Received: from roby.itia.mi.cnr.it by itiasrvr.itia.mi.cnr.it with ESMTP (1.37.109.15/16.2) id AA073084204; Tue, 23 May 1995 17:50:05 +0200 Organization: C.N.R.-I.T.I.A. Received: by roby.itia.mi.cnr.it (940816.SGI.8.6.9/940406.SGI.AUTO) for info-Performer@sgi.com id RAA10297; Tue, 23 May 1995 17:40:44 GMT Date: Tue, 23 May 1995 17:40:44 GMT From: mazzella@roby.itia.mi.cnr.it (Giovanna Mazzella) Message-Id: <199505231740.RAA10297@roby.itia.mi.cnr.it> Apparently-To: info-Performer@sgi.sgi.com Status: O unsuscribe me From guest Tue May 23 10:58:01 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA16627; Tue, 23 May 1995 10:42:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA16624; Tue, 23 May 1995 10:42:56 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29476; Tue, 23 May 95 10:42:51 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA14149; Tue, 23 May 1995 10:42:46 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (940816.SGI.8.6.9/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id KAA19192; Tue, 23 May 1995 10:42:01 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id KAA13211; Tue, 23 May 1995 10:41:54 -0700 From: "AnitaKishore" Message-Id: <9505231041.ZM13209@lee.electrogig.com> Date: Tue, 23 May 1995 10:41:53 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: question on pfSequence node Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O HI: Can someone throw light on pfSequence node usage? The question is: Suppose I want to translate a cube by certain amount in any direction. A simple scene graph would be: root | |-------------------| someLight pfDCS | pfGeode (with a cube) This works fine for what I want. How do I use pfSequence for translation? Do I need to create as many children (cubes with next position) of pfSequence as number of frames desired in animation or what? Where does pfDCS come into picture when using pfSequence? The manual and man pages don't give much about it. Thanks anita ------------------------------------------------------------------------------ Anita Kishore kishore@electrogig.com ------------------------------------------------------------------------------ From guest Tue May 23 09:21:17 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA16439; Tue, 23 May 1995 08:54:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA16436; Tue, 23 May 1995 08:54:03 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22004; Tue, 23 May 95 08:53:58 -0700 Received: from itiasrvr.itia.mi.cnr.it by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA22050; Tue, 23 May 1995 08:52:23 -0700 Received: from roby.itia.mi.cnr.it by itiasrvr.itia.mi.cnr.it with ESMTP (1.37.109.15/16.2) id AA073114286; Tue, 23 May 1995 17:51:27 +0200 Organization: C.N.R.-I.T.I.A. Received: by roby.itia.mi.cnr.it (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id RAA10353; Tue, 23 May 1995 17:42:12 GMT Date: Tue, 23 May 1995 17:42:12 GMT From: mazzella@roby.itia.mi.cnr.it (Giovanna Mazzella) Message-Id: <199505231742.RAA10353@roby.itia.mi.cnr.it> Apparently-To: info-performer@sgi.sgi.com Status: O unsuscribe me From guest Tue May 23 11:28:11 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA16690; Tue, 23 May 1995 11:13:52 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA16687; Tue, 23 May 1995 11:13:47 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02022; Tue, 23 May 95 11:13:41 -0700 Received: from xavier.tacom.army.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA20822; Tue, 23 May 1995 11:13:38 -0700 Received: by xavier.tacom.army.mil (931110.SGI/920502.SGI) for info-performer@sgi.com id AA04633; Tue, 23 May 95 14:13:43 -0400 Date: Tue, 23 May 95 14:13:43 -0400 From: ryagrh@xavier.tacom.army.mil (Greg Hudas) Message-Id: <9505231813.AA04633@xavier.tacom.army.mil> Apparently-To: info-performer@sgi.sgi.com Status: O unsubscribe me From guest Tue May 23 12:38:54 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA16964; Tue, 23 May 1995 12:18:45 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA16961; Tue, 23 May 1995 12:18:44 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07254; Tue, 23 May 95 12:18:43 -0700 Received: from vision.arc.nasa.gov by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA05211; Tue, 23 May 1995 12:18:42 -0700 Received: from descartes.arc.nasa.gov (descartes.arc.nasa.gov [128.102.121.143]) by vision.arc.nasa.gov (8.6.12/8.6.5) with ESMTP id MAA17488 for ; Tue, 23 May 1995 12:18:33 -0700 Received: (carlo@localhost) by descartes.arc.nasa.gov (8.6.12/8.6.5) id MAA07275 for info-performer@sgi.com; Tue, 23 May 1995 12:18:33 -0700 Date: Tue, 23 May 1995 12:18:33 -0700 From: "Carlo L. Tiana" Message-Id: <199505231918.MAA07275@descartes.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: grayscale simulation Status: O Perfolk :-) I would like to use Performer, (read: 'perfly' with as few mods as possible) to simulate a noisy greyscale 'camera'. The first question that arises is whether Performer has any hooks for greyscale rendering. The next question is whether one could use the alpha channel to model noise as a transparency phenomenon (not that this is the case, but maybe it'll look 'good enough'), and if so, how to do this. My thought was to precompute a big noise image and, on a frame-by-frame basis (noise is dynamic), copy different regions of it into the alpha channel. Finally, I expect to have a fairly sparse database, but with each object having a unique color or gray, which is not necessarily the shade with which I would like the object to appear in the final rendered image. Thus, I want to use an object's gray (or color triad) as a tag to be looked up into a LUT that tells me what that objects gray really needs to be. Any suggestions on how to do this? For extra credit :-), does anyone have comments on how to deal with the fact that turning on antialiasing will generate unforeseen 'grays' whose values will be either not valid not exist in my lookup table? Thank you very much, Carlo Tiana carlo@vision.arc.nasa.gov From guest Tue May 23 12:45:18 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA17038; Tue, 23 May 1995 12:25:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA17035; Tue, 23 May 1995 12:25:48 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA07737; Tue, 23 May 95 12:25:38 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA06465; Tue, 23 May 1995 12:25:35 -0700 Received: from crusader.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA24702; Tue, 23 May 95 15:27:16 EDT Received: by crusader.vsl.ist.ucf.edu (940816.SGI.8.6.9) id PAA02072; Tue, 23 May 1995 15:25:44 -0400 Date: Tue, 23 May 1995 15:25:42 -0400 (EDT) From: "Lance R. Marrou" To: AnitaKishore Cc: info-performer@sgi.sgi.com Subject: Re: question on pfSequence node In-Reply-To: <9505231041.ZM13209@lee.electrogig.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Tue, 23 May 1995, AnitaKishore wrote: > This works fine for what I want. How do I use pfSequence for translation? > Do I need to create as many children (cubes with next position) of pfSequence > as number of frames desired in animation or what? Where does pfDCS come into > picture when using pfSequence? The manual and man pages don't give much about > it. Your graph will be something like: | | sequence ________|___________________ | | ... | dcs0 dcs1 dcsn-1 | | ... | |_______|__________________| | | Geode (cube) Where each DCS in the sequence has its own translation and a reference to the cube geometry. In the above graph there are n frames and thus n DCSes. Of course, this allows for more than just translation, but you need the DCSes anyways. ______________________________________________________________________________ /\ ______ /\____ ______ ______ E-mail: marrou@vsl.ist.ucf.edu Visual / / / _ / / __ // ____// ____/ VSL: (407)658-5073 Systems / /__ / /_/ / / / / // /___ / __/_ R. Marrou Fax: (407)658-5059 Lab /____//____/\\/_/ /_//_____//_____/ http://www.vsl.ist.ucf.edu/~marrou "Reap the whirlwind." "We don't need no thought control." From guest Tue May 23 14:10:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA17699; Tue, 23 May 1995 14:06:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA17696; Tue, 23 May 1995 14:06:33 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14691; Tue, 23 May 95 14:06:32 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id OAA26875; Tue, 23 May 1995 14:06:29 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id OAA15430; Tue, 23 May 1995 14:06:20 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:murtland@martinique.ndhm.gtegsc.com id AA14633; Tue, 23 May 95 14:06:13 -0700 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA14947; Tue, 23 May 1995 14:06:11 -0700 From: "Michael Jones" Message-Id: <9505231406.ZM14945@babar.asd.sgi.com> Date: Tue, 23 May 1995 14:06:11 -0700 In-Reply-To: Jim Helman "Fix to Inventor Loader for Large Databases" (May 17, 1:38pm) References: <199505172038.NAA20174@surreal.asd.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Jim Helman , murtland@martinique.ndhm.gtegsc.com, angus@reading.sgi.com Subject: Re: Fix to Inventor Loader for Large Databases Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 17, 1:38pm, Jim Helman wrote: > Subject: Fix to Inventor Loader for Large Databases :I chatted about this with Chris Tanner, Mr. Builder. The :problem is that the allocation size in the builder increases :by 2X each time it overflows the existing allocation. This is :too aggressive for very large databases. : :The best thing to do is to change line 1716 in geobuilder.c : : chunkSize <<= 1; : :to: : /* limit to 8K tris/chunk */ : if (chunkSize < 8192) : chunkSize <<= 1; : :This is the fix that's in 2.0. That's the spirit, but the change must be made in both freeTris() and getPrim(). -- 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 From guest Tue May 23 14:59:18 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA17955; Tue, 23 May 1995 14:53:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA17952; Tue, 23 May 1995 14:53:43 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17178; Tue, 23 May 95 14:53:41 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id OAA06644; Tue, 23 May 1995 14:53:39 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id OAA22811; Tue, 23 May 1995 14:53:36 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:murtland@martinique.ndhm.gtegsc.com id AA17157; Tue, 23 May 95 14:53:32 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA28562; Tue, 23 May 1995 14:53:31 -0700 Message-Id: <199505232153.OAA28562@surreal.asd.sgi.com> To: "Michael Jones" Cc: murtland@martinique.ndhm.gtegsc.com, angus@reading.sgi.com, info-performer@sgi.sgi.com Subject: Re: Fix to Inventor Loader for Large Databases In-Reply-To: Your message of "Tue, 23 May 95 14:06:11 PDT." <9505231406.ZM14945@babar.asd.sgi.com> Date: Tue, 23 May 95 14:53:31 -0700 From: Jim Helman Status: O >That's the spirit, but the change must be made in both >freeTris() and getPrim(). This was included in my later posting. This modification helps, but does not eliminate the possibility that loading a very large file will run out of memory. For a very large shape, the builder needs to disgorge some pfGeoSets before completing the entire shape. I've put out a new version of the Inventor loader on sgigate.sgi.com:/pub/Performer/src/pfiv14.test.tar.Z. The "test" indicates Xperimental, because it hasn't been widely tested. The only change is large file handling, so you really only need this version if you can't load a large file. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue May 23 17:26:08 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA18650; Tue, 23 May 1995 17:22:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA18647; Tue, 23 May 1995 17:22:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA25083; Tue, 23 May 95 17:22:05 -0700 Received: from bert.arc.nasa.gov by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA07611; Tue, 23 May 1995 17:22:03 -0700 Received: by bert.arc.nasa.gov (8.6.10/1.35) id AAA14417; Wed, 24 May 1995 00:10:10 GMT Date: Wed, 24 May 1995 00:10:10 GMT From: spelk@bert.arc.nasa.gov (Steve Elkins) Message-Id: <199505240010.AAA14417@bert.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: Fog RVR Status: O Greetings, We are building an airport simulation and need to have accurate Runway Visibility Range (RVR) for fog. Has anyone done any fog calibrations using Performers fog functions? Is there a preferred fog type to use for accurate fog RVR distances? Any information would be greatly appreciated. Thanks. Steve Elkins ***************************************************************************** Steve Elkins Sterling Software NASA Ames Research Center spelk@bert.arc.nasa.gov ***************************************************************************** From guest Wed May 24 02:47:10 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA21781; Wed, 24 May 1995 02:33:40 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA21778; Wed, 24 May 1995 02:33:39 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15857; Wed, 24 May 95 02:33:27 -0700 Received: from redgate.vislab.su.edu.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA27326; Wed, 24 May 1995 02:33:19 -0700 From: ben@vislab.su.edu.au Received: from ford.vislab.su.edu.au by redgate.vislab.su.edu.au via ESMTP (950215.SGI.8.6.10/940406.SGI) for id TAA16624; Wed, 24 May 1995 19:33:06 +1000 Received: by ford.vislab.su.edu.au (950215.SGI.8.6.10/940406.SGI) for info-performer@sgi.com id TAA25282; Wed, 24 May 1995 19:28:12 +1000 Date: Wed, 24 May 1995 19:28:12 +1000 Message-Id: <199505240928.TAA25282@ford.vislab.su.edu.au> Apparently-To: info-performer@sgi.sgi.com Status: O It seems that my app is trashing shared memory somewhere. It dies deep down in pfMalloc. viz: dbx version 3.19 Nov 3 1994 19:59:46 Core from signal SIGSEGV: Segmentation violation (dbx) > where 0 _lmalloc(0x1992a130, 0x18140000, 0x40220443, 0x4) ["amalloc.c":720, 0xfb0e344] 1 _amalloc(0x1814004c, 0x18140000, 0x198766d0, 0x178) ["amalloc.c":76, 0xfb0eabc] 2 pfMalloc(nbytes = 360, arena = 0x18140000) ["/d/trees/perf1.2a102.Irix5/perf/lib/libpr/DBG.IRIX5/../../../lib/libpr/mall.c":214, 0x571f5c] 3 createIsoBar(length = 30, path = 0x19876570) ["/mnt/scratch/ben/performer/weather/DBG/../press.c":1005, 0x457c28] [ etc ] The pfmalloc request doesn't seem unreasonable - 360 bytes... Can anyone suggest a good technique to find the problem? I tried using: > Date: Tue, 16 Nov 93 15:59:01 -0800 > From: Jim Helman > [...] > amallopt(3X) to turn on M_DEBUG so the data structure will be checked > on every amalloc. Then you start sprinkling your code with pfMallocs > from the arena until you narrow it down. But it dumped core on the call to amallopt() !! :-( tsk! ben. PS: No one replied to my previous question about using cvd with performer. From guest Wed May 24 03:00:11 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA21790; Wed, 24 May 1995 02:41:50 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA21787; Wed, 24 May 1995 02:41:39 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16011; Wed, 24 May 95 02:41:38 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id CAA27609; Wed, 24 May 1995 02:41:37 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) id CAA04025; Wed, 24 May 1995 02:41:33 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id KAA20185; Wed, 24 May 1995 10:36:57 +0100 From: "Rob Jenkins" Message-Id: <9505241036.ZM20183@barney.reading.sgi.com> Date: Wed, 24 May 1995 10:36:56 +0100 In-Reply-To: spelk@bert.arc.nasa.gov (Steve Elkins) "Fog RVR" (May 24, 12:10am) References: <199505240010.AAA14417@bert.arc.nasa.gov> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: spelk@bert.arc.nasa.gov (Steve Elkins), info-performer@sgi.sgi.com Subject: Re: Fog RVR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 24, 12:10am, Steve Elkins wrote: > Subject: Fog RVR > > Greetings, > > We are building an airport simulation and need to have > accurate Runway Visibility Range (RVR) for fog. > > Has anyone done any fog calibrations using Performers > fog functions? Is there a preferred fog type to use > for accurate fog RVR distances? > > Any information would be greatly appreciated. > > Thanks. > > Steve Elkins > ***************************************************************************** > Steve Elkins > Sterling Software > NASA Ames Research Center > spelk@bert.arc.nasa.gov > ***************************************************************************** > >-- End of excerpt from Steve Elkins I don't have details of fog calibrations but man fogvertex gives calculations of the blend functions for linear and exponential fog. Using spline fog allows you to specify a set of fog density/distance points a Catmull-Rom spline interpolation is used to create hardware fog tables from this fog ramp table - man pfFog gives more details. NOTE when using spline fog from man pfFog: " PFFOG_PIX_SPLINE is only effective on RealityEngine graphics systems. The visual quality of per-pixel fogging is influenced by the ratio of the distances from the eye to the far and the eye to the near clipping planes. This ratio should be minimized for best results. " You may need to set an environment variable ( RE_FOG_MODE ) depending on the REV of you RM4 boards to get good spline fog - let me know if you want more details. also from past experience ( and help from Bob Drebin ) I have found that you may need to ensure that you have 12 bits per colour component to get best results from spline fog - it depends on the complexity of the scene 'behind' the fog: use getgconfig(GC_BITS_RED) to find the number of bits per colour component. I can't say if this is more/less accurate than exponential or linear fog though. I guess someone may have ( or I could produce ) a long 'runway' polygon with Z distance markers on to try different fog over it and measure accuracy - I you have no other response let me know and I'll do this. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Wed May 24 07:38:19 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA22044; Wed, 24 May 1995 07:25:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA22041; Wed, 24 May 1995 07:25:46 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22994; Wed, 24 May 95 07:25:45 -0700 Received: from alexandra.mtl.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA16476; Wed, 24 May 1995 07:25:42 -0700 Received: from Maddie (maddie [192.148.246.55]) by alexandra.mtl.com (8.6.10/8.6.6) with ESMTP id KAA20326; Wed, 24 May 1995 10:26:19 -0400 Received: by Maddie (940816.SGI.8.6.9/Spike-2.0) id KAA24510; Wed, 24 May 1995 10:21:37 -0400 From: "John A. Collier" Message-Id: <9505241021.ZM24508@Maddie.mtl.com> Date: Wed, 24 May 1995 10:21:37 -0400 In-Reply-To: "Carlo L. Tiana" "grayscale simulation" (May 23, 12:18pm) References: <199505231918.MAA07275@descartes.arc.nasa.gov> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Carlo L. Tiana" Subject: Re: grayscale simulation Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O One suggestion for noise that I have gotten is to put a noise pattern on a polygon on a polygon in the viewing frustum. John -- John A. Collier e-mail: jcollier@mtl.com MTL Systems, Inc. voice: (513) 426-3111 3481 Dayton-Xenia Rd. fax: (513) 426-8301 Dayton, OH 45432-2796 From guest Wed May 24 09:10:29 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA22204; Wed, 24 May 1995 09:08:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA22201; Wed, 24 May 1995 09:08:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27549; Wed, 24 May 95 09:08:05 -0700 Received: from copernicus.hpc.org by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA29187; Wed, 24 May 1995 09:07:35 -0700 Received: from galileo.hpc.org by copernicus.hpc.org (4.1/SMI-4.1) id AA08990; Wed, 24 May 95 12:13:41 EDT Received: by galileo.hpc.org (940816.SGI.8.6.9/930416.SGI) id MAA07581; Wed, 24 May 1995 12:13:50 -0400 Date: Wed, 24 May 1995 12:13:50 -0400 (EDT) From: Michael Kelley X-Sender: kelleym@galileo.hpc.org To: Performer Subject: pfGetPipeSwapFunc Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I'm getting a : Unresolved: pfGetPipeSwapFunc when I try to link my object files. I couldn't find "pfGetPipeSwapFunc" anywhere in the symbol tables of libpf.so or libpr.so (though it's in the pf.h header file.) Is it a bug or am I doing something wrong? Thanks! ____________________________________________________________________ Michael Kelley Systems Programmer Information Sciences Institute kelleym@csto.snap.org (703) 243-9422 ____________________________________________________________________ From guest Wed May 24 09:45:34 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA22435; Wed, 24 May 1995 09:42:02 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA22432; Wed, 24 May 1995 09:42:01 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29707; Wed, 24 May 95 09:41:59 -0700 Received: from paradox.idec.sdl.usu.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA06213; Wed, 24 May 1995 09:41:49 -0700 Received: by paradox.idec.sdl.usu.edu (931110.SGI/920502.SGI.AUTO) for info-performer@sgi.com id AA06938; Wed, 24 May 95 10:22:56 -0600 From: "Darin C. Partridge" Message-Id: <9505241022.ZM6936@paradox.idec.sdl.usu.edu> Date: Wed, 24 May 1995 10:22:55 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfDataPools ??? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I would like to monitor a performer with an unrelated process using shared memory. I didn't want Performer code in the unrelated process so I set up my own shared memory with usinit. This gave me an error so I switched to using pfNewDPool to set the memory up for me. The problem is that I got the very same error. The memory is set up in the unrelated process (3611 below) using: control_pool = pfNewDPool( 256, "viperfly" ); shmem = pfDPoolAlloc( control_pool, sizeof(float)*3, 0 ); I attach from the performer app using: control_pool = pfAttachDPool( "viperfly" ); shmem = pfDPoolFind( control_pool, 0 ); The problem is that I get an error when I try to attach "usinit:ERROR:Virtual Address 0x4c0000 already in use process 3614" what am I doing wrong? The complete trace is below: TRACE: Process 3611 creating new arena /usr/tmp/viperfly.pfdpool:locktype 0 maxusers 32 TRACE: Process 3611 Initializing R4000 MP LOCKS TRACE: Header size 2680 malloc arena size 49152 TRACE: arena @ 0x4c0000 gets semaphore device 0xbc0009 sfd 6 TRACE: Process 3611 added as tid 0 sfd 6 arena /usr/tmp/viperfly.pfdpool TRACE: Process 3611 usinit succeded for arena /usr/tmp/viperfly.pfdpool @ 0x4c0000 0.000000 0.000000 0.000000 TRACE: Process 3614 creating new arena /usr/tmp/pfSemaFile.a000sU:locktype 0 maxusers 65 TRACE: Process 3614 Initializing R4000 MP LOCKS TRACE: Header size 2680 malloc arena size 65536 TRACE: arena @ 0x5c0000 gets semaphore device 0xbc000a sfd 4 TRACE: Process 3614 added as tid 0 sfd 4 arena /usr/tmp/pfSemaFile.a000sU TRACE: Process 3614 usinit succeded for arena /usr/tmp/pfSemaFile.a000sU @ 0x5c0000 TRACE: Process 3614 creating new arena /usr/tmp/pfClock.3614.pfdpool:locktype 0 maxusers 32 TRACE: Process 3614 Initializing R4000 MP LOCKS TRACE: Header size 2680 malloc arena size 49152 TRACE: arena @ 0x600000 gets semaphore device 0xbc000e sfd 7 TRACE: Process 3614 added as tid 0 sfd 7 arena /usr/tmp/pfClock.3614.pfdpool TRACE: Process 3614 usinit succeded for arena /usr/tmp/pfClock.3614.pfdpool @ 0x600000 TRACE: Process 3615 already mapped to arena /usr/tmp/pfClock.3614.pfdpool TRACE: Process 3615 added as tid 1 sfd 7 arena /usr/tmp/pfClock.3614.pfdpool TRACE: Process 3614 joining existing arena /usr/tmp/viperfly.pfdpool @ 0x4c0000 usinit:ERROR:Virtual Address 0x4c0000 already in use process 3614 Performer Warning (16): pfDPoolFind() Null pfDataPool. Performer Info (16): All 4 processors available on this machine. TRACE: Process 3616 added as tid 1 sfd 4 arena /usr/tmp/pfSemaFile.a000sU TRACE: Process 3617 added as tid 2 sfd 4 arena /usr/tmp/pfSemaFile.a000sU TRACE: Process 3618 added as tid 3 sfd 4 arena /usr/tmp/pfSemaFile.a000sU TRACE: Process 3614 creating new arena /usr/tmp/pfUtilDataPool3614.pfdpool:locktype 0 maxusers 32 TRACE: Process 3614 Initializing R4000 MP LOCKS TRACE: Header size 2680 malloc arena size 106056 TRACE: arena @ 0x6c0000 gets semaphore device 0xbc000f sfd 12 TRACE: Process 3614 added as tid 0 sfd 12 arena /usr/tmp/pfUtilDataPool3614.pfdpool TRACE: Process 3614 usinit succeded for arena /usr/tmp/pfUtilDataPool3614.pfdpool @ 0x6c0000 -- _ _ __(_)__ ,,, __(_)__ (_______) (o o) (_______) | |-------------------------------------oOO--(_)--OOo--| | | | Darin C. Partridge _________ | | | | Space Dynamics Laboratory (CSD) | | | | | | 1695 North Research Parkway | Gone | | | | | Logan, UT 84321 | Fishing | | | | | |_________| | | | | Voice: (801) 755-4348 ____________ | | | | Fax: (801) 755-4366 /___________/ | | | | Email: darin@sdl.usu.edu | | |_____|----------------------------------------------------|_____| (_____) (http://www.csd.sdl.usu.edu/darin_exec/homedoc) (_____) (_) (_) From guest Wed May 24 09:23:58 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA22247; Wed, 24 May 1995 09:21:13 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA22244; Wed, 24 May 1995 09:21:12 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA28401; Wed, 24 May 95 09:21:11 -0700 Received: from mercury.arl.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA02050; Wed, 24 May 1995 09:21:00 -0700 Received: by mercury.arl.mil (4.1/SMI-4.1) id AA08331; Wed, 24 May 95 10:22:57 MDT From: mtorres@arl.mil (Torres Mario 678-3280 AMSRL-BE-M) Message-Id: <9505241622.AA08331@mercury.arl.mil> Subject: Re: Fog RVR To: spelk@bert.arc.nasa.gov (Steve Elkins) Date: Wed, 24 May 95 10:22:57 MDT Cc: info-performer@sgi.sgi.com In-Reply-To: <199505240010.AAA14417@bert.arc.nasa.gov>; from "Steve Elkins" at May 24, 95 00:10:10 am X-Mailer: ELM [version 2.4dev PL17] Status: O Hi, In the AeroSense SPIE April 1995 conference we published a paper that does exactly what you are looking for, a calibration of the fog function in comparasion with well established physical models. Title: "Representation of meteorological visibility in real-time simulation of targets and backgrounds" Mario A. Torres and Dr. Donald W. Hoock, Jr. We have found that for "realistic" representation of fog, haze or dust, we can use Performers EXP1 function and that the trick is in computing the physically correct far-fog range to submit to the pfFogRange function. We relate the far-fog range to a desired meteorological visibility as defined by Koschmider's relations. Simply, Zfog-far = (Visibility * 5500.0)/3.912 Where Visibility is given in Kilometers. This Should do the trick for you. Mario A. Torres STC for Army Research Lab. Battlefield Environment Division > > > Greetings, > > We are building an airport simulation and need to have > accurate Runway Visibility Range (RVR) for fog. > > Has anyone done any fog calibrations using Performers > fog functions? Is there a preferred fog type to use > for accurate fog RVR distances? > > Any information would be greatly appreciated. > > Thanks. > > Steve Elkins > ***************************************************************************** > Steve Elkins > Sterling Software > NASA Ames Research Center > spelk@bert.arc.nasa.gov > ***************************************************************************** > > > From guest Wed May 24 10:46:22 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA22802; Wed, 24 May 1995 10:43:09 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA22799; Wed, 24 May 1995 10:43:08 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04571; Wed, 24 May 95 10:43:07 -0700 Received: from blackhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA23045; Wed, 24 May 1995 10:43:01 -0700 Received: (from uucp@localhost) by blackhole.cae.ca (8.6.7/8.6.6) id NAA27132 for ; Wed, 24 May 1995 13:33:06 -0400 Received: from hell.cae.ca(142.39.201.1) by bhole via smap (V1.3mjr) id sma027069; Wed May 24 13:32:39 1995 Received: by cae.ca (4.1/SMI-4.1) id AA29794; Wed, 24 May 95 13:30:57 EDT Date: Wed, 24 May 95 13:30:57 EDT From: rejeanc@cae.ca (Rejean Chartrand) Message-Id: <9505241730.AA29794@cae.ca> To: info-performer@sgi.sgi.com Subject: HCV colors to RGB colors Status: O I would like to know if anybody has ever converted HCV colors to RGB colors. Presummably I need to have a "Base Color" to be able to perform the conversion but I don't have any; I just have HCV values which I would like to convert to RGB values. I would appreciate having a piece of code that does that. Thanks in advance ! Rejean Chartrand CAE Electronics Ltd., Montreal CANADA. From guest Wed May 24 13:52:37 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA23506; Wed, 24 May 1995 13:46:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA23503; Wed, 24 May 1995 13:46:19 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16332; Wed, 24 May 95 13:46:18 -0700 Received: from palladium.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA00862; Wed, 24 May 1995 13:46:15 -0700 Received: from giraffe.asd.sgi.com by palladium.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id NAA16008; Wed, 24 May 1995 13:46:12 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:kelleym@csto.snap.org id AA16319; Wed, 24 May 95 13:46:09 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA17463; Wed, 24 May 1995 13:46:09 -0700 Message-Id: <199505242046.NAA17463@surreal.asd.sgi.com> To: Michael Kelley Cc: Performer Subject: Re: pfGetPipeSwapFunc In-Reply-To: Your message of "Wed, 24 May 95 12:13:50 EDT." Date: Wed, 24 May 95 13:46:08 -0700 From: Jim Helman Status: O It's a bug. pfGetPipeSwapFunc is missing from 1.2. -jim From guest Wed May 24 13:54:44 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA23511; Wed, 24 May 1995 13:50:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA23508; Wed, 24 May 1995 13:50:50 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16554; Wed, 24 May 95 13:50:41 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id NAA01651; Wed, 24 May 1995 13:50:38 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id NAA18650; Wed, 24 May 1995 13:50:34 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:darin@paradox.idec.sdl.usu.edu id AA16538; Wed, 24 May 95 13:50:20 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA17478; Wed, 24 May 1995 13:50:20 -0700 Message-Id: <199505242050.NAA17478@surreal.asd.sgi.com> To: "Darin C. Partridge" Cc: info-performer@sgi.sgi.com Subject: Re: pfDataPools ??? In-Reply-To: Your message of "Wed, 24 May 95 10:22:55 MDT." <9505241022.ZM6936@paradox.idec.sdl.usu.edu> Date: Wed, 24 May 95 13:50:17 -0700 From: Jim Helman Status: O A characteristic of both usinit and pfDataPools is that the address at which the usinit arena is mapped must be the same in both processes. This means that if the attaching process has already allocated space, e.g. from the heap, that conflicts with the usinit arena as mapped by the creating process, usinit will fail in the attaching process. The solution (which is built into 2.0) is to use usconfig to specify a suitable ATTACH_ADDR before calling usinit or pfNewDPool. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 To: fred@vsl.ist.ucf.edu (ALFREDO) Cc: info-performer@sgi.sgi.com Subject: Re: datapools In-Reply-To: Your message of "Sun, 08 Jan 95 18:35:13 EST." <9501082335.AA26147@onyx.vsl.ist.ucf.edu> Date: Mon, 09 Jan 95 17:54:48 -0800 From: Jim Helman The problem is that pfDataPools must reside at the same space in every process (see usinit(1)). Performer currently leaves the choice of address up to IRIX. This means that pfNewDPool should be called in the larger process and pfAttachDPool should be called as early as possible in the smaller process. It's OK to make calls like pfNotifyLevel and pfAttachDPool before pfInit(). Errno 16 (EBUSY) indicates a memory conflict. In the next release, Performer will try to choose a good place in virtual address space for datapool arenas. In the meantime, you can call usconfig with CONF_ATTACHADDR, to specify an allocation address out in the boonies of addressland. Just be sure to set it back to ~0 after the call to pfNewDPool. My choice for an address would be something just below the stack, say between 0x7f000000 and 0x7ff00000. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed May 24 14:02:18 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA23552; Wed, 24 May 1995 13:58:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA23549; Wed, 24 May 1995 13:58:31 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17112; Wed, 24 May 95 13:58:29 -0700 Received: from alexandra.mtl.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA03286; Wed, 24 May 1995 13:58:27 -0700 Received: from Maddie (maddie [192.148.246.55]) by alexandra.mtl.com (8.6.10/8.6.6) with ESMTP id QAA28721 for ; Wed, 24 May 1995 16:59:04 -0400 Received: by Maddie (940816.SGI.8.6.9/Spike-2.0) id QAA26232; Wed, 24 May 1995 16:54:12 -0400 From: "John A. Collier" Message-Id: <9505241654.ZM26230@Maddie.mtl.com> Date: Wed, 24 May 1995 16:54:11 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: TravMask problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I am trying to get traversal masks working in order to display simultaneous IR and visual scenes. My goal is to tag some geodes with a VISUAL tag (0x1) and others with an IR tag (0x2) with the pfNodeTravMask(geode,PF_XXXX,VISUAL) then use a pfChanTravMask(chan,PF_XXXX,VISUAL or IR) to limit which is displayed in which channel. Should it be a PF_CULL or a PF_DRAW? If I make if PF_DRAW to prune the node as it looks like the manual states, nothing shows up. If I use PF_CULL, I do not get the correct images. It appears that both geodes are drawn ( as they have the same geometry it is hard to tell for sure) Thanks for your help, John -- John A. Collier e-mail: jcollier@mtl.com MTL Systems, Inc. voice: (513) 426-3111 3481 Dayton-Xenia Rd. fax: (513) 426-8301 Dayton, OH 45432-2796 From guest Wed May 24 14:39:04 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA24051; Wed, 24 May 1995 14:36:35 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA24048; Wed, 24 May 1995 14:36:35 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19757; Wed, 24 May 95 14:36:33 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id OAA11283; Wed, 24 May 1995 14:36:28 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id OAA26456; Wed, 24 May 1995 14:30:29 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:kishore@electrogig.com id AA19371; Wed, 24 May 95 14:30:24 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA17593; Wed, 24 May 1995 14:30:23 -0700 Message-Id: <199505242130.OAA17593@surreal.asd.sgi.com> To: "AnitaKishore" Cc: info-performer@sgi.sgi.com Subject: Re: question on pfSequence node In-Reply-To: Your message of "Tue, 23 May 95 10:41:53 PDT." <9505231041.ZM13209@lee.electrogig.com> Date: Wed, 24 May 95 14:30:23 -0700 From: Jim Helman Status: O pfSequence is for pre-computed animation sequences. Using one instead of one or more DCSes with instanced geometry is basically making a time-space tradeoff. Pre-computed sequences are very cheap to render, but consume memory because instances are flattened out. It's really not needed if you have a few animated DCSes, but if you have many of copies of an object containing many DCSes, it can save quite a bit of push/mult/popping in the graphics pipe. In this case, you would create a pfSequence with SCSes as children (so they can be flattened) and then pfFlatten() the pfSequence so that SCSes are eliminated and the transformations are applied directly to the geometry in place rather than at run time. However when this would only eliminate a few or few dozen DCSes in the scene, it probably isn't worthwhile. Instead, you should directly animate the DCS(es) using callbacks or application code (at least until we get Engines in Performer). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed May 24 14:57:49 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA24113; Wed, 24 May 1995 14:54:52 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA24110; Wed, 24 May 1995 14:54:51 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20971; Wed, 24 May 95 14:54:50 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id OAA15341; Wed, 24 May 1995 14:54:49 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id OAA00099; Wed, 24 May 1995 14:54:45 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:jcollier@alexandra.mtl.com id AA20948; Wed, 24 May 95 14:54:41 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA17654; Wed, 24 May 1995 14:54:41 -0700 Message-Id: <199505242154.OAA17654@surreal.asd.sgi.com> To: "John A. Collier" Cc: info-performer@sgi.sgi.com Subject: Re: TravMask problems In-Reply-To: Your message of "Wed, 24 May 95 16:54:11 EDT." <9505241654.ZM26230@Maddie.mtl.com> Date: Wed, 24 May 95 14:54:41 -0700 From: Jim Helman Status: O You want the DRAW mask. The CULL traversal mask is for controlling trivial accepts. Are you sure that you're ending up with the mask values that you expect in the scene graph? You may want to use pfPrint to check on the mask values in the scene. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed May 24 15:27:16 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA24440; Wed, 24 May 1995 15:22:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA24437; Wed, 24 May 1995 15:22:31 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22878; Wed, 24 May 95 15:22:28 -0700 Received: from ag.aes.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA21760; Wed, 24 May 1995 15:22:27 -0700 Received: from [159.4.130.90] by ag.aes.com (4.1/CERFnet-1.0) id AA27412; Wed, 24 May 95 15:20:44 PDT Date: Wed, 24 May 95 15:20:44 PDT Message-Id: <9505242220.AA27412@ag.aes.com> X-Sender: turnerm@ag.aes.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: turnerm@post.aes.com (Mark Turner) Subject: unsubscribe Status: O Please unsubscribe me. I tried to send mail to info-performer-request@sgi.com to unsubscribe like a good citizen, but my mail was returned. Sorry I have to post it here. -- Mark Turner From guest Wed May 24 17:20:37 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA24912; Wed, 24 May 1995 17:04:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA24909; Wed, 24 May 1995 17:04:21 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27730; Wed, 24 May 95 17:04:13 -0700 Received: from ix2.ix.netcom.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA11454; Wed, 24 May 1995 17:04:17 -0700 Received: from by ix2.ix.netcom.com (8.6.12/SMI-4.1/Netcom) id RAA12262; Wed, 24 May 1995 17:03:28 -0700 Date: Wed, 24 May 1995 17:03:28 -0700 Message-Id: <199505250003.RAA12262@ix2.ix.netcom.com> From: blastarr@ix.netcom.com (Kent Miller) Subject: Fwd: HCV colors to RGB colors To: info-performer@sgi.sgi.com >From: rejeanc@cae.ca (Rejean Chartrand) >Subject: HCV colors to RGB colors Status: O > >I would like to know if anybody has ever converted HCV colors >to RGB colors. Presummably I need to have a "Base Color" to be able >to perform the conversion but I don't have any; I just have HCV values >which I would like to convert to RGB values. I would appreciate having >a piece of code that does that. If you mean HSV (Hue-Saturation-Value) I have HSV-to-RGB and RGB-to-HSV routines at work (I'm at home now). If no one posts anything by tomorrow, I'll try to remember to bring them home (no net access at work) and post them to the group. From guest Wed May 24 17:42:55 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA25047; Wed, 24 May 1995 17:39:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA25044; Wed, 24 May 1995 17:39:21 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29481; Wed, 24 May 95 17:39:07 -0700 Received: from eagle.lmsc.lockheed.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA19235; Wed, 24 May 1995 17:39:17 -0700 Received: from aic.lockheed.com by eagle.lmsc.lockheed.com (8.6.11/DEC-Ultrix/4.3) id RAA23019; Wed, 24 May 1995 17:38:41 -0700 Received: from phobos.aic.lockheed.com (phobos.rdd.lmsc.lockheed.com) by aic.lockheed.com (4.1/SMI-4.1/AIC-PostOffice-Brent-930416-01) id AA21565; Wed, 24 May 95 17:39:15 PDT Date: Wed, 24 May 95 17:39:15 PDT From: stiles@aic.lockheed.com (Randy Stiles) Message-Id: <9505250039.AA21565@aic.lockheed.com> Received: by phobos.aic.lockheed.com (4.1/SMI-4.1/AIC-Client-Brent-930416-01) id AA28032; Wed, 24 May 95 17:39:14 PDT To: info-performer@sgi.sgi.com Subject: Rqst Info on Yale Astron. Chart files Status: O Hi Everyone, A while ago Jim Helman listed some file formats that Performer 2.0 can handle. Lots of interesting formats, but one that caught my interest was: yale Astronomy chart translator Does anyone have a set of star chart files in this format that is publicly available? Thanks, // Randy Stiles Office: 415.354.5256 Orgn 9620 Bldg 255 // stiles@aic.lockheed.com Fax: 415.354.5235 3251 Hanover Street // Lockheed AI Center Lab: 415.424.2690 Palo Alto, CA 94304-1191 // http://hitchhiker.space.lockheed.com/~stiles/HOME.html From guest Wed May 24 18:24:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA25225; Wed, 24 May 1995 18:20:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA25222; Wed, 24 May 1995 18:20:15 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01486; Wed, 24 May 95 18:19:33 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id SAA26160; Wed, 24 May 1995 18:19:48 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id SAA01160; Wed, 24 May 1995 18:06:27 -0700 Received: from babar.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:stiles@aic.lockheed.com id AA00837; Wed, 24 May 95 18:05:50 -0700 Received: by babar.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id SAA17303; Wed, 24 May 1995 18:06:05 -0700 From: "Michael Jones" Message-Id: <9505241806.ZM17301@babar.asd.sgi.com> Date: Wed, 24 May 1995 18:06:04 -0700 In-Reply-To: stiles@aic.lockheed.com (Randy Stiles) "Rqst Info on Yale Astron. Chart files" (May 24, 5:39pm) References: <9505250039.AA21565@aic.lockheed.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: stiles@aic.lockheed.com (Randy Stiles), info-performer@sgi.sgi.com Subject: Re: Rqst Info on Yale Astron. Chart files Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 24, 5:39pm, Randy Stiles wrote: > Subject: Rqst Info on Yale Astron. Chart files :Hi Everyone, : :A while ago Jim Helman listed some file formats :that Performer 2.0 can handle. Lots of interesting :formats, but one that caught my interest was: : :yale Astronomy chart translator : :Does anyone have a set of star chart files in this :format that is publicly available? : :Thanks, : :// Randy Stiles Office: 415.354.5256 Orgn 9620 Bldg 255 :// stiles@aic.lockheed.com Fax: 415.354.5235 3251 Hanover Street :// Lockheed AI Center Lab: 415.424.2690 Palo Alto, CA 94304-1191 :// http://hitchhiker.space.lockheed.com/~stiles/HOME.html : >-- End of excerpt from Randy Stiles Here is a file that has gone through many steps since it was in the Yale Compact Star Chart format. I have not decided if it's this one or the Yale CSC loader that we'll distribute. Anyway, here are the 3010 brightest stars as viewed from earth, with a rather arbitrary brightness factor that is related to magnitude. They are projected onto a unit sphere, so you will probably want to place them under a pfDCS node to scale them up. Michael Jones P.S. No, Sol's not in here. it's at [0,0,0] if you care. # # data derived from the yale star catalog # s -0.18746032 0.93921369 -0.28763914 1.00 Sirius s -0.06323564 0.60291260 -0.79529721 1.00 Canopus s -0.78377002 -0.52700269 0.32859191 1.00 Arcturus s 0.18718566 0.73014212 0.65715599 1.00 Capella s 0.12507832 -0.76942003 0.62637711 0.99 Vega s 0.13051330 0.68228769 0.71933979 0.99 Capella s 0.19507207 0.97036278 -0.14262892 0.98 Rigel s -0.37387931 -0.31261155 -0.87320572 0.94 Rigil Kentaurus s -0.41809806 0.90381104 0.09121194 0.94 Procyon s 0.49255905 0.22369388 -0.84103900 0.92 Achernar s -0.42400947 -0.25435105 -0.86920738 0.90 Hadar (Agena) s 0.45922387 -0.87484610 0.15413558 0.88 Altair s -0.44939077 -0.05239382 -0.89179754 0.87 Acrux s 0.02091211 0.99145067 0.12879559 0.87 Betelgeuse s 0.34393576 0.89501035 0.28401536 0.86 Aldebaran s -0.91413081 -0.35632819 -0.19337822 0.84 Spica s -0.34477949 -0.82641578 -0.44515619 0.82 Antares s -0.39155090 0.79122889 0.46972838 0.81 Pollux s 0.83737743 -0.23360345 -0.49419478 0.81 Fomalhaut s 0.45576218 -0.53630841 0.71039015 0.79 Deneb s -0.49362421 -0.10432278 -0.86339557 0.79 Mimosa s -0.86449331 0.45788679 0.20734258 0.77 Regulus s -0.22139786 0.84642529 -0.48430070 0.75 Adara s -0.09167211 -0.79229814 -0.60320795 0.73 Shaula s 0.15061858 0.98238552 0.11060166 0.73 Bellatrix s 0.12870057 0.86849886 0.47869188 0.73 Alnath s -0.53791767 -0.07360590 -0.83977783 0.72 s -0.25883171 0.23061061 -0.93798983 0.72 s 0.10363775 0.99439460 -0.02094242 0.72 Alnilam s 0.60287035 -0.31976473 -0.73095679 0.71 s -0.45912650 0.11504068 0.88089073 0.70 Dubhe s -0.54442662 -0.13078900 0.82854927 0.70 Alioth s 0.40505084 0.50168633 0.76435900 0.70 Mirfak s 0.08686216 -0.82069385 -0.56472701 0.69 Kaus Australis s -0.36286592 0.57215303 -0.73550612 0.69 s -0.26337534 0.85611504 -0.44463518 0.69 s -0.07226745 -0.72777444 -0.68199837 0.69 s -0.58142883 -0.29476303 0.75832397 0.69 Benetnasch s -0.29565978 0.41252938 -0.86162919 0.69 s 0.00144110 0.70772213 0.70648944 0.68 Menkalinan s -0.85243040 0.39757028 0.33955887 0.68 s 0.32557604 -0.44146630 -0.83612663 0.68 s -0.15716268 0.94635260 0.28234145 0.68 s -0.10958351 -0.34063178 -0.93378878 0.68 s -0.38031429 0.43474835 -0.81630564 0.68 s -0.09407244 0.94666320 -0.30818695 0.67 Mirzam s -0.77790534 0.61004680 -0.15068571 0.67 s -0.34062544 0.77780986 0.52819133 0.67 Castor s 0.81966311 0.57047671 -0.05204546 0.67 Mira s -0.45141363 -0.77794683 0.43706343 0.67 s 0.77976841 0.48331988 0.39794865 0.67 Hamal s 0.93399954 0.17978951 -0.30874035 0.66 Diphda s 0.01034223 0.00802346 0.99991435 0.66 Polaris s 0.08377425 0.99590361 -0.03402735 0.66 s 0.77559036 0.24355093 0.58235943 0.66 Mirach s 0.05259512 0.98439729 -0.16791590 0.66 s 0.21409547 -0.87054640 -0.44307119 0.66 s 0.87332904 0.03195992 0.48608121 0.66 Alpheratz s -0.10654096 -0.97021127 0.21757543 0.66 Ras Alhague s -0.68517464 -0.42269087 -0.59318477 0.66 s -0.20078707 -0.18514585 0.96198004 0.66 Kocab s -0.44938698 -0.05242649 -0.89179754 0.65 s 0.63384563 0.38041386 0.67344266 0.65 s 0.64494330 -0.22627737 -0.72996348 0.65 s -0.96675450 0.04615476 0.25150633 0.64 Denebola s 0.51465893 0.55278999 0.65540016 0.64 Algol s -0.64575577 -0.11827565 -0.75432777 0.64 s 0.12179551 0.99254143 -0.00523596 0.63 Mintaka s 0.44379860 -0.62094009 0.64612401 0.63 s 0.54285669 0.09698264 0.83420676 0.63 Schedar s -0.00923830 -0.62267375 0.78242707 0.63 Rastaban s -0.52917659 -0.71961868 0.44957885 0.63 Alphecca s -0.53109062 0.49525002 -0.68751013 0.63 s -0.38729382 0.33341944 -0.85955513 0.62 s -0.39334756 0.65734452 -0.64278764 0.62 s -0.53642911 -0.20573670 0.81848413 0.62 Mizar s 0.51238209 0.02050475 0.85851276 0.62 Caph s -0.53964424 -0.25130597 -0.80351067 0.62 s -0.46038586 -0.80009717 -0.38456386 0.62 s -0.24783947 -0.78804439 -0.56352603 0.62 s -0.51482832 -0.43944606 -0.73609710 0.62 s -0.57718515 -0.46531403 -0.67107385 0.61 s -0.53590840 0.13896967 0.83276027 0.60 Merak s 0.73477256 0.08463706 -0.67301250 0.60 s -0.66943967 -0.58699673 0.45528594 0.60 Pulcherrima s 0.81717455 -0.55024052 0.17164253 0.60 Eniph s -0.05931236 -0.77451193 -0.62977242 0.60 s -0.20677552 -0.94014233 -0.27088046 0.59 s -0.59179771 0.01597055 0.80592829 0.59 Phecda s 0.35089511 -0.29815134 0.88768148 0.59 Alderamin s -0.31281772 0.81403309 -0.48938245 0.59 s 0.55013937 -0.62063617 0.55871052 0.59 s -0.44258744 0.36446258 -0.81931883 0.58 s 0.93712717 -0.23032479 0.26218918 0.58 Markab s 0.69823539 0.71228886 0.07149744 0.58 Mekab s -0.59380007 -0.32756990 -0.73491460 0.58 s 0.85585463 -0.21424818 0.47075528 0.57 s -0.91784972 0.18632171 0.35047984 0.57 Zozca, Zosma s 0.47423589 0.11977998 0.87221158 0.57 s -0.34768119 -0.91950518 -0.18337947 0.57 s 0.11298976 0.94522208 -0.30624920 0.57 Arneb s -0.63273555 -0.02306323 -0.77402443 0.57 s -0.95127195 -0.06575470 -0.30126059 0.57 s 0.23399331 -0.83502078 -0.49798331 0.57 s -0.64402556 -0.74742848 -0.16303897 0.56 Zuben el Chamali s -0.45099273 -0.82574946 -0.33873791 0.56 s 0.07344438 0.82496053 -0.56039810 0.56 Phakt s 0.82027239 0.44838849 0.35510695 0.56 Sheratan s -0.55467093 -0.82453036 0.11175800 0.56 Unukalhay s 0.00098470 0.79652929 0.60459912 0.56 s -0.51931322 -0.51270866 -0.68369848 0.56 s -0.90744573 -0.13717063 -0.39714789 0.56 s -0.61741239 0.20428927 -0.75964981 0.55 s 0.46206892 0.18158694 0.86805445 0.55 s -0.83253479 -0.45524886 0.31564903 0.55 Muphrid s 0.07938872 -0.86398113 -0.49722639 0.55 s 0.22726129 0.80580777 0.54683280 0.55 s -0.35151672 -0.05753685 -0.93441182 0.55 s -0.10119151 -0.78901100 -0.60598838 0.55 s -0.26344872 0.75281799 -0.60320795 0.55 s 0.43951896 -0.87913579 0.18423727 0.55 Tarazed s -0.19410953 -0.43589216 0.87881714 0.55 s -0.44397655 -0.89373249 -0.06424203 0.55 s -0.70603108 -0.65198237 -0.27647609 0.54 s -0.75255895 -0.27608043 -0.59785837 0.54 s 0.10641714 0.98896384 -0.10308187 0.54 s -0.40814400 0.14263014 -0.90170676 0.54 s -0.44473919 -0.60738111 -0.65825164 0.54 s 0.22470157 0.97039086 -0.08860456 0.54 Cursa s -0.07184886 -0.99423265 0.07961901 0.54 Kelb al Rai s -0.35528347 -0.86002839 0.36623058 0.54 Kornephoros s -0.07864413 -0.60621691 0.79140139 0.54 Alwaid s 0.21930589 0.02474445 -0.97534233 0.53 s -0.48145169 0.77386057 -0.41151434 0.53 s -0.28682154 -0.80198014 0.52398592 0.53 s -0.51764023 -0.03426811 -0.85491186 0.53 s 0.80342811 -0.52658290 -0.27787358 0.53 Deneb Algiedi s -0.31620046 -0.82247835 -0.47280711 0.53 s 0.96348435 0.05569476 0.26190847 0.53 Algenib s -0.94582248 -0.26311484 0.19023786 0.53 Vindemiatrix s 0.10992763 -0.89637017 -0.42946059 0.53 s 0.12913544 0.92617595 -0.35429105 0.53 s -0.23176520 -0.38250154 -0.89441460 0.53 s -0.08535831 -0.55945241 -0.82445556 0.53 s 0.44324550 0.72425640 0.52819133 0.53 s 0.44834271 -0.21264909 -0.86819881 0.53 s 0.41362095 0.23584551 -0.87937170 0.52 s 0.31192467 -0.63275260 0.70875043 0.52 s 0.49882481 0.76434493 0.40859598 0.52 Alcyone s -0.37689880 -0.81943631 -0.43182340 0.52 s -0.76126260 -0.18992166 0.62000728 0.52 Cor Caroli s 0.79371262 -0.60046172 -0.09729340 0.52 Sadalsud s 0.38922885 0.65979165 0.64278764 0.52 s 0.27979490 -0.89055741 -0.35863951 0.52 s -0.09241690 0.91913372 0.38295215 0.52 s -0.23498127 -0.27736655 -0.93158555 0.52 s -0.36729315 0.91887981 0.14406836 0.52 Gomeisa s -0.45284608 -0.77534127 -0.44020039 0.52 s -0.13715194 0.61950535 -0.77291816 0.51 s 0.87835246 -0.47798163 -0.00552685 0.51 Sadalmelik s -0.07894433 -0.63949174 -0.76473403 0.51 s 0.41170254 0.42931941 0.80385685 0.51 s -0.95061666 -0.12451831 -0.28429425 0.51 s 0.81581420 -0.28489506 0.50327134 0.51 s 0.49335873 0.83783549 -0.23372820 0.51 Zaurak s -0.76283687 0.50562882 0.40301293 0.50 s 0.18071502 0.69835424 0.69256294 0.50 s 0.09080715 0.92820776 0.36081082 0.50 s -0.86528879 -0.31031537 -0.39367452 0.50 s 0.27336812 -0.93157470 0.23966326 0.50 s -0.17248498 0.88873875 0.42472619 0.50 MEbsuta s 0.02181781 -0.86194307 -0.50653547 0.50 s -0.92219621 -0.04080162 -0.38456386 0.50 s 0.69190150 0.43881172 0.57333815 0.50 s 0.67753023 -0.41546214 -0.60691357 0.50 s -0.69631726 0.15543282 0.70070177 0.50 s -0.07655677 0.86205029 -0.50100732 0.50 s 0.37837088 0.55527788 0.74060917 0.50 s -0.04141130 -0.76361197 -0.64434606 0.50 s -0.24842143 0.88034546 -0.40407753 0.50 s -0.68194920 0.30964497 0.66262007 0.50 s -0.61809450 -0.48327029 0.62000728 0.49 s -0.19964445 -0.23947904 0.95015359 0.49 s -0.36514327 -0.07475945 -0.92794472 0.49 s 0.55809754 -0.78956836 -0.25516450 0.49 s 0.11829176 -0.36111328 0.92498881 0.49 s 0.34054390 -0.81492847 0.46895781 0.49 Albireo s 0.43050832 -0.52426434 -0.73471731 0.48 s 0.06157411 -0.79870981 -0.59855765 0.48 s -0.68904048 0.71727097 0.10366054 0.48 s 0.03197347 0.81077379 -0.58448571 0.48 s -0.91544139 0.29032198 -0.27871174 0.48 s -0.43345651 0.32896170 -0.83898729 0.48 s -0.14801188 -0.53949875 -0.82887489 0.48 s -0.52659851 -0.52270663 -0.67042661 0.48 s -0.45120066 0.04785443 -0.89113855 0.48 s -0.17692153 -0.89012104 0.41998014 0.48 s -0.23067285 -0.75293034 -0.61634892 0.48 s -0.63449681 0.52747136 0.56496704 0.48 s -0.47122213 0.47445437 0.74353397 0.47 Talitha s -0.35264847 0.23098658 -0.90679890 0.47 s -0.15604344 -0.78537965 0.59902358 0.47 s 0.17390932 0.73164678 0.65912712 0.47 s -0.11961512 0.71928978 -0.68433505 0.47 s 0.26297542 -0.20426042 0.94293243 0.47 Alphirk s -0.32116202 -0.27551231 -0.90606177 0.47 s -0.49654025 0.37129071 0.78459609 0.47 s -0.09111156 -0.40102944 0.91152292 0.47 s 0.17636789 -0.87337679 -0.45399049 0.47 s 0.29911578 0.94651359 0.12100314 0.47 s 0.64441282 -0.57549721 0.50352269 0.47 s 0.21797466 0.89871138 -0.38053244 0.47 s -0.05988827 0.92193645 0.38268343 0.47 s -0.03533501 -0.79732746 -0.60251170 0.47 s -0.26476842 -0.95042938 0.16303897 0.47 s -0.48421040 -0.58409816 -0.65143657 0.47 s 0.21357986 -0.01931197 0.97673470 0.46 Alrai s -0.42782041 -0.90014207 -0.08193851 0.46 s -0.27625582 0.67330223 -0.68581831 0.46 s 0.54202002 -0.84024471 -0.01425304 0.46 s 0.21405357 -0.81399381 0.53999555 0.46 Sulaphat s 0.84575307 0.14659369 0.51304197 0.46 s 0.09268724 -0.99442381 -0.05030242 0.46 s 0.20995440 0.53300029 -0.81965226 0.46 s -0.09822376 0.46013153 -0.88240075 0.46 s -0.76105374 -0.46812725 -0.44905910 0.46 s 0.92328894 -0.27064458 -0.27256012 0.46 Skat s 0.14859778 0.22715329 -0.96245521 0.46 s -0.14958394 -0.89387834 -0.42261827 0.45 s 0.65730232 0.19496182 -0.72797221 0.45 s -0.32280341 -0.40196517 0.85686755 0.45 s -0.54291767 -0.03661582 0.83898729 0.45 Megrez s -0.43981728 0.17766052 -0.88033944 0.45 Megrez s -0.30542991 0.15269795 -0.93989146 0.45 s 0.25499839 -0.84816056 -0.46432686 0.45 s -0.08326543 -0.54733652 -0.83276027 0.45 s 0.19582930 0.94011426 -0.27899113 0.45 s -0.62792563 -0.65061462 -0.42709485 0.45 s -0.15101212 -0.71274817 -0.68497109 0.45 s 0.20550896 0.41407076 -0.88674206 0.44 s -0.94479841 0.19114837 0.26611695 0.44 s -0.00422795 -0.98544830 -0.16992286 0.44 s 0.15421760 0.98716140 -0.04158502 0.44 s -0.41642070 0.80608112 -0.42050806 0.44 s -0.29821402 0.38770521 0.87221158 0.44 s -0.19141783 0.95578170 0.22325011 0.44 s 0.46831468 -0.24158593 0.84989268 0.44 s -0.45052665 -0.54978323 -0.70339471 0.44 s -0.91578776 -0.40152600 -0.01047178 0.44 s 0.36386406 -0.92986393 0.05436927 0.44 s -0.66100901 0.74200892 0.11175800 0.44 s 0.38923788 0.21221939 0.89635754 0.44 s -0.96902460 -0.23980923 0.05901600 0.44 s -0.43215251 0.20825201 -0.87742537 0.44 s 0.92505246 -0.33007839 0.18795274 0.43 Homam s -0.39145190 -0.67892623 -0.62114781 0.43 s -0.41047239 -0.45701069 -0.78908408 0.43 s 0.05306834 0.45894864 -0.88687646 0.43 s -0.38399485 0.25597170 -0.88714510 0.43 s 0.67417717 0.27358362 -0.68603003 0.43 s -0.05223639 -0.88358033 0.46535707 0.43 s 0.37326720 0.88652366 0.27339965 0.43 s -0.66319853 -0.34340242 -0.66501313 0.43 s 0.48571777 0.84696811 0.21615562 0.43 s 0.76590681 0.41189557 0.49368894 0.43 s 0.54339010 0.53515434 -0.64678979 0.43 s 0.31167477 -0.35451192 0.88157821 0.43 s 0.26600966 -0.30345955 -0.91495967 0.43 s 0.18100056 -0.81531858 0.54999495 0.43 Sheliak s 0.28402635 -0.95503008 -0.08512709 0.43 s -0.82599336 0.39974546 0.39741483 0.43 s 0.52045333 0.11323932 0.84634811 0.43 s -0.38155916 0.34668523 -0.85686755 0.43 s 0.94048357 0.29022917 -0.17679845 0.43 s -0.65976042 0.31787598 0.68093395 0.42 s 0.75550532 0.65271008 0.05640237 0.42 s -0.82416737 0.15095326 0.54585826 0.42 s -0.23505063 0.85165226 -0.46844387 0.42 s -0.29367635 0.52556175 -0.79846042 0.42 s -0.65471596 -0.33943284 -0.67537570 0.42 s -0.80977929 0.56097937 0.17192909 0.42 s -0.54960877 -0.62947369 0.54926592 0.42 s 0.59488690 -0.19171357 -0.78061223 0.42 s 0.46696907 -0.81896025 0.33353263 0.42 s -0.53401983 -0.54318553 0.64789838 0.42 Nekkar s 0.86717367 -0.27334976 0.41628081 0.42 s -0.19042586 -0.94975334 0.24840812 0.42 s 0.08164751 -0.69026470 -0.71893555 0.42 s 0.47126061 -0.88182133 0.01745241 0.42 s 0.86414129 0.42178112 -0.27451870 0.42 s 0.23254204 -0.90350789 -0.35999683 0.42 s 0.38470000 -0.12188006 0.91495967 0.42 s 0.53821993 0.56313294 0.62705708 0.42 s 0.88222283 -0.45827830 0.10799935 0.41 s -0.55384320 0.81712651 0.15988119 0.41 s -0.31759623 0.87120867 0.37433687 0.41 Wasat s -0.84410006 0.45197052 0.28847480 0.41 s -0.25677931 -0.73427385 0.62841570 0.41 s 0.55381840 0.81517404 -0.16963618 0.41 s 0.36669397 0.87038088 0.32859191 0.41 s -0.49786922 0.29659346 -0.81495923 0.41 s -0.09407933 -0.95949417 -0.26555610 0.41 s -0.84354466 0.09984009 -0.52769727 0.41 s 0.05501411 0.96510792 -0.25600818 0.41 s 0.98458898 0.08368783 -0.15356073 0.41 s 0.51513886 0.34910315 -0.78278923 0.41 s 0.35807529 0.74987817 -0.55629563 0.41 s -0.51334995 -0.62172925 -0.59154421 0.41 s -0.53775209 -0.84099400 -0.05959675 0.41 s -0.56938469 -0.39647010 -0.72014755 0.41 s 0.02724542 -0.29556635 0.95493364 0.41 s -0.09863980 0.31889999 -0.94264150 0.41 s -0.40082386 0.81773162 0.41310441 0.41 s 0.55308396 -0.80436671 -0.21700758 0.41 s -0.22924352 -0.75374138 -0.61589068 0.41 s -0.95178890 0.17068234 -0.25488323 0.41 s -0.48841876 0.47324172 0.73313665 0.41 s -0.32039970 0.90352762 0.28457311 0.41 s -0.68017197 -0.53061265 0.50578284 0.41 s 0.21505727 -0.34178066 -0.91484225 0.41 s 0.60158956 0.27410734 0.75030339 0.41 s 0.18263824 0.97591895 -0.11927044 0.40 s -0.60498190 0.46129021 -0.64900553 0.40 s 0.61407155 -0.74791521 0.25206935 0.40 Rotanev s -0.51517010 -0.71572614 -0.47152501 0.40 s -0.06157968 -0.48574832 -0.87192690 0.40 s 0.61877620 0.76971698 0.15700907 0.40 s -0.34942970 0.70649987 -0.61543220 0.40 s -0.49179676 -0.04598343 -0.86949492 0.40 s -0.18932696 0.80746388 0.55871052 0.40 s 0.06259237 0.92209119 -0.38187706 0.40 s 0.92404860 0.35478613 -0.14234102 0.40 s 0.65539765 0.60047364 0.45813251 0.40 s -0.86757469 0.44882801 -0.21416709 0.40 s -0.99870187 0.04054843 0.03082926 0.40 Zawijah s -0.30486819 -0.08492956 -0.94860023 0.40 s -0.09859344 0.31891432 -0.94264150 0.40 s 0.88851464 0.37479037 0.26471469 0.40 s -0.38818985 0.46139854 -0.79775935 0.40 s 0.71581513 -0.18540023 0.67322761 0.40 s -0.02655304 -0.42600515 -0.90433097 0.40 s -0.39449832 0.02481967 -0.91856140 0.39 s 0.49345389 0.76838762 0.40753371 0.39 Atlas s 0.40777862 0.87249523 0.26920000 0.39 s -0.20809567 -0.70914137 -0.67365772 0.39 s 0.58154839 0.09462435 0.80798990 0.39 s 0.36152646 -0.37826082 -0.85218388 0.39 s -0.37042993 -0.22345768 0.90158099 0.39 Thuban s -0.50194037 -0.70804209 -0.49672151 0.39 s -0.36118892 0.27333024 0.89153415 0.39 s 0.92191952 -0.38738132 -0.00029089 0.39 s 0.10666521 0.97921681 0.17250219 0.39 s 0.78493893 -0.54919469 -0.28680322 0.39 s 0.90994221 -0.20402180 -0.36108211 0.39 s -0.53143394 -0.80430645 0.26583657 0.39 s 0.01856304 -0.64118099 -0.76716512 0.39 s -0.53849858 -0.68811131 0.48633540 0.39 s -0.98320395 -0.18074743 -0.02530457 0.39 s 0.29422757 0.95074064 0.09758290 0.39 s 0.54333377 0.30101991 -0.78369343 0.38 s -0.54781771 0.63251108 -0.54756325 0.38 s 0.98097295 -0.18550418 0.05727362 0.38 s -0.00850191 -0.87245458 0.48862123 0.38 s 0.59852648 0.71024871 -0.37055743 0.38 s 0.50751889 0.75859994 0.40859598 0.38 Electra s -0.67069167 0.04087443 0.74060917 0.38 s 0.47919452 -0.87060165 0.11146893 0.38 s -0.53265584 -0.84271425 0.07816910 0.38 s 0.01522965 0.96946830 -0.24474335 0.38 s -0.35717896 0.67022651 -0.65055329 0.38 s 0.00118872 0.58377624 0.81191373 0.38 s 0.28271061 0.95825225 0.04274754 0.38 s 0.60961920 0.77445608 0.16906281 0.38 s 0.86973280 0.45977125 -0.17937458 0.38 Baten s 0.52006382 -0.49814272 0.69382089 0.38 s 0.03161889 -0.98558581 0.16619509 0.38 s 0.59160018 -0.51973379 0.61634892 0.38 s 0.09249251 0.99467951 -0.04536299 0.38 s -0.74782109 -0.66307187 0.03315518 0.38 s 0.59040618 0.79017019 -0.16447377 0.38 s -0.39199558 -0.85949266 0.32804239 0.38 s -0.62340361 0.23525384 -0.74566984 0.38 s 0.72514129 -0.57336760 -0.38133928 0.38 s -0.05271227 -0.99748433 0.04739701 0.38 s -0.48997906 0.47254783 -0.73254287 0.38 s -0.01542062 -0.54637170 0.83740085 0.38 s 0.59171128 -0.24122198 0.76921374 0.38 s -0.15511373 -0.49034050 -0.85761642 0.38 s 0.25864050 -0.89218408 -0.37028724 0.37 s 0.79617882 -0.42780229 0.42788377 0.37 s 0.39189056 0.86928928 0.30126059 0.37 s -0.24029249 0.32552803 -0.91448951 0.37 s 0.94871718 -0.28726330 -0.13196805 0.37 s 0.61701846 -0.73761857 0.27423897 0.37 Svalocin s 0.40852863 0.61256278 0.67666179 0.37 s 0.41218764 0.38002291 0.82806033 0.37 s 0.65894055 -0.73386419 -0.16504760 0.37 s 0.23625541 -0.57248890 0.78513682 0.37 s 0.19701055 -0.56322998 0.80247045 0.37 s 0.17973220 -0.12412395 -0.97585326 0.37 s 0.37737980 -0.57214558 0.72817165 0.37 s 0.03539465 0.93374127 -0.35619444 0.37 s -0.49565694 0.14799727 -0.85581601 0.37 s -0.32324216 0.82340634 0.46638662 0.37 s -0.43492931 0.27446416 0.85761642 0.37 s 0.47996372 0.52149975 0.70545936 0.37 s -0.06218541 -0.69165927 0.71954185 0.37 s 0.42817128 -0.84595317 0.31785631 0.37 s -0.37875801 -0.92484844 0.03460879 0.37 s -0.61063480 0.51770341 0.59925646 0.37 s -0.47741526 0.20297870 -0.85491186 0.37 s -0.79214334 0.23727773 0.56232393 0.37 s 0.31014612 0.80324084 -0.50854057 0.37 s -0.87782651 0.38131046 -0.28986710 0.37 s -0.50535500 -0.74047565 0.44307119 0.36 s -0.64535737 -0.36611754 -0.67042661 0.36 s -0.28625861 0.84571481 -0.45035818 0.36 s 0.47178242 0.70153522 0.53410643 0.36 s 0.15350550 -0.30073038 0.94127429 0.36 s 0.02880851 -0.87611330 0.48124376 0.36 s -0.35018602 0.04392831 0.93564951 0.36 s -0.33901769 0.35398790 -0.87164187 0.36 s 0.90906191 -0.41596106 -0.02414137 0.36 Sadachbia s -0.66472590 0.32876861 -0.67085820 0.36 Sadachbia s 0.03485099 0.62744862 -0.77787769 0.36 s -0.49432269 -0.82636219 0.26976022 0.36 s -0.19532841 -0.39798242 -0.89635754 0.36 s -0.08040877 0.83064461 -0.55096638 0.36 s 0.23778461 0.35319462 -0.90482706 0.36 s -0.01302397 -0.79589546 0.60529399 0.36 s 0.09586697 -0.92374045 0.37082759 0.36 s 0.15140244 -0.97800159 -0.14349262 0.36 s -0.44269514 0.52463222 -0.72717398 0.36 s 0.58514005 0.65024412 -0.48455518 0.36 s -0.65324527 -0.10843695 -0.74934107 0.36 s -0.91630816 0.36641991 0.16160382 0.36 s 0.37343472 0.88602054 0.27479839 0.36 s 0.33010915 0.66209644 -0.67279732 0.36 s -0.14145760 -0.12720142 -0.98173803 0.36 s 0.75873768 0.19181404 0.62251467 0.36 s 0.05602641 -0.93158412 -0.35918251 0.36 s -0.44147730 -0.49002355 -0.75164801 0.36 s 0.33863035 0.90792125 -0.24699901 0.36 s -0.61653435 -0.35124922 -0.70463419 0.36 s 0.10199812 0.80787092 -0.58046609 0.36 s -0.21344616 0.88679415 -0.40992305 0.36 s -0.34188968 -0.05030806 0.93839252 0.36 s 0.69720364 0.02861202 -0.71630192 0.36 s -0.44657362 -0.74987811 -0.48811358 0.35 s -0.57232249 0.09830014 -0.81411552 0.35 s -0.74940199 0.66088027 0.04042244 0.35 s -0.71255046 -0.29897997 -0.63473052 0.35 s -0.99616516 -0.08671530 -0.01163527 0.35 s -0.30372962 -0.04331728 -0.95177305 0.35 s 0.50338006 0.75920403 0.41257456 0.35 Maia s -0.75374293 -0.64975297 -0.09845136 0.35 s 0.68547946 -0.06731219 0.72497380 0.35 s -0.07109441 -0.17922135 -0.98123664 0.35 s -0.81861621 0.57400024 -0.01977911 0.35 s -0.29261893 -0.62562138 0.72316808 0.35 s 0.40611422 -0.71043217 0.57476723 0.35 s -0.59226656 0.80284160 -0.06830551 0.35 s 0.68755871 -0.15132655 -0.71018535 0.35 s 0.70942992 0.68758553 -0.15471038 0.35 s -0.76370120 0.47366861 0.43863258 0.35 s -0.56991982 -0.78107774 -0.25516450 0.35 Zuben el Hakrabi s -0.45991635 0.51976448 -0.71994573 0.35 Zuben el Hakrabi s 0.48537654 0.86803424 0.10452846 0.35 s 0.09510852 -0.37483296 -0.92220098 0.35 s 0.17218901 -0.69905132 0.69403034 0.35 s -0.22096020 -0.82897258 0.51379085 0.35 s 0.75106835 -0.65385306 0.09150162 0.35 s 0.35646743 0.93247855 -0.05843522 0.35 s -0.63487768 -0.07809374 -0.76865578 0.35 s -0.62555188 0.71529645 0.31150579 0.34 s 0.52572650 -0.53881025 0.65825164 0.34 s 0.71844774 0.08249195 -0.69067210 0.34 s 0.33205193 -0.89206684 -0.30652609 0.34 s -0.42162970 0.89146107 -0.16590825 0.34 s 0.60372871 0.25393918 -0.75566298 0.34 s 0.54481113 0.16756241 -0.82164693 0.34 s -0.12852442 0.27001274 -0.95424032 0.34 s -0.44452655 -0.70419157 -0.55363381 0.34 s -0.18191068 0.82337958 -0.53754491 0.34 s -0.50237405 0.11463605 -0.85701746 0.34 s -0.15046759 0.93202126 -0.32969064 0.34 s -0.97099972 0.15408099 0.18280753 0.34 s 0.43841186 0.41700786 0.79617804 0.34 s 0.25932786 0.15494849 0.95327854 0.34 s 0.86990362 -0.28881648 0.39981586 0.34 s 0.00272056 0.73352718 -0.67965472 0.34 s 0.33702368 0.75726390 -0.55943406 0.34 s 0.00275967 -0.99868596 0.05117396 0.34 s -0.52872318 0.52580923 0.66631556 0.34 s 0.14766772 -0.25427139 -0.95579302 0.34 s -0.38296413 0.78678954 -0.48404619 0.34 s -0.60981727 -0.03102546 -0.79193455 0.34 s 0.27172112 -0.70878285 -0.65099502 0.34 s 0.66945153 -0.27980909 -0.68814355 0.34 s 0.92686063 -0.15108719 -0.34365970 0.34 s -0.52487582 0.62496877 -0.57785761 0.34 s -0.06443319 0.99190229 -0.10944518 0.34 s -0.44358045 -0.82381821 -0.35293055 0.34 s -0.12351326 0.35451567 -0.92685658 0.34 s 0.02875518 0.77496243 0.63135284 0.34 s -0.34425709 0.31197086 -0.88552880 0.34 s 0.51740682 -0.09721952 -0.85019910 0.34 s -0.25149122 0.11144554 -0.96142191 0.34 s 0.37504441 -0.55882692 0.73963112 0.34 s 0.42905787 -0.29072177 0.85521352 0.34 s 0.80801821 0.46658784 -0.35972542 0.34 s -0.47779953 0.16203614 -0.86339557 0.33 s -0.42803815 -0.84007275 -0.33325839 0.33 s 0.05943620 -0.31281129 -0.94795382 0.33 s -0.36535451 0.27469003 -0.88941640 0.33 s 0.68583524 0.46835685 0.55702055 0.33 s -0.53438097 -0.20839123 0.81915206 0.33 Alcor s -0.28609955 0.28004709 -0.91636276 0.33 s -0.60091323 -0.51307726 -0.61290705 0.33 s 0.46745640 0.44314754 -0.76492143 0.33 s 0.38940632 -0.74367929 0.54341871 0.33 s 0.25177455 -0.66777050 -0.70049417 0.33 s 0.52345043 -0.68588424 0.50553191 0.33 s -0.25700000 -0.45378369 0.85324752 0.33 s -0.59968072 0.65138692 -0.46484205 0.33 s 0.92652929 -0.29391250 -0.23485936 0.33 s 0.31885916 0.94610506 -0.05669279 0.33 s 0.93255830 -0.36101365 -0.00203622 0.33 s 0.99282265 -0.00296028 0.11955926 0.33 s 0.56239903 -0.41621646 0.71447265 0.33 s 0.26449934 -0.95916760 -0.10018806 0.33 s 0.24836110 -0.93313801 0.25994277 0.33 s -0.52664548 -0.12789547 -0.84040898 0.33 s -0.58284658 0.65474755 0.48124376 0.33 s 0.31412986 0.59496105 0.73982686 0.33 s 0.60782039 -0.76951897 0.19594614 0.33 s -0.98019481 0.16784112 0.10510703 0.33 s -0.90777647 -0.03328675 -0.41813135 0.33 s -0.99164581 0.06130298 0.11349223 0.33 s -0.64529181 -0.45414990 -0.61428523 0.33 s 0.12052937 0.47822800 0.86992568 0.33 s -0.27113307 -0.58034432 -0.76791102 0.33 s -0.50219357 -0.41354713 -0.75946057 0.33 s -0.61765170 -0.53526270 -0.57619458 0.33 s -0.85452938 -0.44231546 0.27228025 0.33 s 0.40883139 0.70068353 0.58472168 0.33 s -0.47798070 -0.51632303 -0.71059483 0.32 s -0.48350343 0.55425054 -0.67751807 0.32 s 0.45128015 0.88441485 -0.11898164 0.32 s -0.49783993 -0.36569983 0.78639627 0.32 s 0.43965548 0.47589427 0.76172680 0.32 s -0.15627247 -0.57900393 -0.80020833 0.32 s -0.94158745 0.14541475 -0.30375591 0.32 s -0.43695399 -0.03522048 -0.89879405 0.32 s 0.69266593 -0.65760297 -0.29626375 0.32 s -0.33726162 -0.39320043 -0.85536426 0.32 s 0.56990474 0.27688453 0.77365595 0.32 s 0.76747859 0.64104819 -0.00581773 0.32 s -0.12865001 0.18625696 -0.97404182 0.32 s 0.89226854 0.18694642 0.41098404 0.32 s -0.22913127 0.95074493 -0.20876521 0.32 s -0.36248967 0.81480306 0.45243469 0.32 s 0.26652572 0.93512958 0.23344536 0.32 s 0.64106393 0.65463287 -0.40061557 0.32 s -0.41180399 0.30346957 -0.85925764 0.32 s -0.91682392 0.24666297 -0.31399244 0.32 s 0.72614831 -0.59814692 0.33901161 0.32 s 0.29639998 0.21093261 -0.93147975 0.32 s -0.82445544 -0.55618978 -0.10452846 0.32 s 0.09923295 0.98190105 0.16131675 0.32 s -0.02646434 0.13457902 0.99054939 0.32 s 0.68419135 0.30748782 0.66131186 0.32 s -0.31657606 0.61313605 -0.72377050 0.32 s -0.23508507 -0.32570383 -0.91577947 0.32 s 0.23547690 -0.75294244 -0.61451471 0.32 Alkes s 0.28408867 0.23749994 -0.92891735 0.32 s -0.48142695 0.02839123 -0.87602627 0.32 s 0.23269466 -0.73763913 -0.63383096 0.32 s -0.81856644 0.51406687 -0.25628939 0.32 s 0.58667320 0.49519256 -0.64077991 0.32 s -0.51503652 -0.79866993 0.31122935 0.32 s 0.49260244 0.42896804 0.75718510 0.31 s -0.26443046 0.92598975 -0.26948011 0.31 s 0.58526862 -0.15440676 -0.79600203 0.31 s 0.59035015 0.77541316 0.22410066 0.31 s 0.60750300 -0.65251303 -0.45295346 0.31 s -0.01025204 0.98579681 0.16762912 0.31 s 0.66707534 -0.27716455 -0.69151306 0.31 s -0.98814970 -0.02249619 0.15183589 0.31 s 0.35895193 -0.65248108 -0.66739941 0.31 s 0.08221054 -0.65000218 -0.75547242 0.31 s 0.29390681 0.59532911 0.74779809 0.31 s -0.46446162 0.56519359 -0.68178558 0.31 s 0.59952325 -0.67704242 -0.42683181 0.31 s 0.99136460 -0.08695132 0.09816188 0.31 s 0.15520068 0.97851622 -0.13571557 0.31 s 0.71064180 -0.34666735 0.61221731 0.31 s -0.37431335 -0.02874705 -0.92685658 0.31 s -0.30838275 0.95122236 -0.00872654 0.31 s 0.71267658 -0.06104586 0.69883150 0.31 s -0.42874172 -0.01288084 -0.90333527 0.31 s 0.74876690 -0.50196564 0.43287256 0.31 s -0.45408455 -0.76768792 0.45217529 0.31 s -0.63181585 0.76872903 0.09931975 0.31 s 0.14209107 -0.04750850 -0.98871285 0.31 s -0.50096697 -0.81617123 -0.28791770 0.31 s -0.18436371 0.07126328 -0.98027116 0.31 s -0.11828869 0.93090725 0.34557119 0.31 s -0.25852746 0.89986330 0.35129702 0.31 s 0.89205569 -0.43115664 -0.13542737 0.31 s -0.29138267 -0.76288897 -0.57714522 0.31 s -0.47390026 -0.85817409 -0.19737218 0.31 s -0.01650070 0.91852814 0.39501110 0.31 s 0.45031801 0.06529301 0.89047772 0.31 s -0.51108068 -0.68400496 0.52051300 0.31 s 0.43516204 0.67957258 -0.59060568 0.31 s -0.32226920 0.78658801 0.52670854 0.30 s -0.13339429 -0.90243369 -0.40965769 0.30 s 0.83778226 -0.30217054 -0.45476785 0.30 s -0.57438034 -0.38882390 0.72034937 0.30 s 0.50336176 0.76278454 0.40593928 0.30 Merope s -0.82308817 -0.53912699 -0.17851602 0.30 s -0.04399658 -0.13142839 0.99034888 0.30 s 0.48785031 -0.24049295 0.83914554 0.30 s 0.12645185 0.98654163 0.10366054 0.30 s 0.18528001 -0.91785240 0.35102463 0.30 s 0.92790794 -0.30732512 0.21104047 0.30 s 0.22806664 -0.76483017 -0.60251170 0.30 s -0.73787886 0.31365427 0.59762514 0.30 s 0.81036866 -0.23256053 -0.53779018 0.30 s 0.56871974 -0.64470798 0.51079303 0.30 s 0.02375556 -0.99876577 0.04361939 0.30 s -0.27012950 -0.68664193 0.67494655 0.30 s -0.44969833 0.80409110 -0.38885596 0.30 s -0.04795090 -0.88300848 -0.46690121 0.30 s 0.11462571 0.94090474 0.31868362 0.30 s -0.73235875 -0.37901062 -0.56568682 0.30 s 0.02896175 -0.31874880 0.94739664 0.30 s 0.10540187 -0.45458442 -0.88444525 0.30 s 0.30645600 0.39603135 0.86558872 0.30 s 0.27587408 -0.36088258 0.89087445 0.30 s -0.38028371 -0.70466661 -0.59902358 0.30 s 0.96922141 -0.18890923 -0.15787083 0.30 s 0.37126979 0.84745014 0.37945613 0.30 s 0.57711387 0.53153604 0.62000728 0.30 s 0.50426984 0.76804245 -0.39474386 0.30 s 0.20365217 -0.97553504 -0.08280820 0.30 s 0.97475415 -0.19683982 -0.10539631 0.30 s -0.68740052 0.69655925 0.20563488 0.29 s -0.58197945 -0.79238963 0.18280753 0.29 s -0.07120511 -0.20409080 -0.97635895 0.29 s -0.31676531 0.58768266 -0.74450576 0.29 s -0.31003043 -0.76144725 -0.56927955 0.29 s 0.54484439 -0.35789570 0.75832397 0.29 s 0.39060059 0.54008955 0.74547601 0.29 s 0.58631188 -0.50334436 0.63473052 0.29 s -0.75078756 -0.37303457 -0.54512686 0.29 s 0.32670757 -0.25882903 -0.90899378 0.29 s 0.26722196 0.70254332 0.65956450 0.29 s 0.06248241 0.01932660 0.99785894 0.29 s 0.64782757 0.20270647 0.73432249 0.29 s 0.55169207 -0.80547488 -0.21643962 0.29 s 0.53928310 0.40264073 -0.73963112 0.29 s 0.73234373 0.63736504 -0.23966326 0.29 s 0.27295154 0.55973691 -0.78242707 0.29 s 0.42283687 0.03711737 -0.90544534 0.29 s -0.78711438 0.33749309 -0.51628423 0.29 s 0.35409567 0.91845560 0.17622580 0.29 s -0.36274102 0.57223225 -0.73550612 0.29 s 0.34101611 0.11703305 -0.93274397 0.29 s -0.19778989 -0.14841489 0.96894383 0.29 s -0.33025989 -0.62617242 0.70628357 0.29 s -0.07896269 -0.97168779 -0.22268298 0.29 s -0.08512223 0.98700494 -0.13629195 0.29 s -0.38149175 0.78812963 0.48302770 0.29 s -0.42546928 0.59192157 0.68454713 0.29 s 0.00020220 0.69528580 0.71873331 0.29 s -0.86212444 -0.50597411 0.02704930 0.29 s -0.61687529 -0.18536478 -0.76492143 0.29 s -0.43453643 -0.51110548 -0.74158567 0.29 s -0.53031689 0.19481206 -0.82511348 0.29 s -0.74331349 -0.17651118 -0.64523548 0.29 s 0.85407937 -0.46163839 -0.23966326 0.29 s 0.55363095 0.74671185 -0.36866540 0.29 s 0.74033910 0.64887905 0.17565310 0.29 s -0.84079927 -0.27265143 0.46767271 0.29 s 0.46975747 0.55950457 -0.68284887 0.29 s 0.88469696 0.43820551 0.15901968 0.29 s 0.70558977 -0.16652358 -0.68877643 0.29 s 0.63856256 -0.71765184 0.27787358 0.29 s 0.34128547 0.91463387 0.21672359 0.29 s 0.21749777 0.96413338 -0.15212339 0.29 s -0.18507284 -0.01483641 -0.98261279 0.29 s 0.72485971 -0.06937057 0.68539482 0.29 s 0.78954196 0.59577316 0.14723399 0.29 s -0.74256283 -0.11014879 0.66065699 0.29 s 0.73922509 -0.60801703 -0.28958869 0.29 s 0.95343763 0.26859784 0.13715641 0.29 s 0.98410851 -0.13845389 0.11117985 0.29 s 0.78258818 -0.31817394 -0.53508973 0.29 s -0.82961398 0.02570924 -0.55774516 0.29 s -0.36232013 -0.88710028 -0.28596711 0.29 s 0.40193683 -0.26742569 0.87574553 0.29 s 0.30286130 -0.46025965 0.83452743 0.29 s 0.30639973 0.86825496 0.39019555 0.29 s 0.25202176 -0.66330659 -0.70463419 0.29 s 0.58470744 0.81121415 -0.00698126 0.29 s -0.07978841 -0.77707183 -0.62433416 0.29 s -0.12255805 0.08816155 0.98853785 0.29 s 0.37474379 -0.20815149 0.90346003 0.28 s 0.17088434 0.95853204 -0.22806767 0.28 s -0.65239161 0.75558072 0.05901600 0.28 s 0.43490034 0.88708872 0.15471038 0.28 s 0.30304489 0.56154299 0.76995665 0.28 s 0.36644024 0.84578091 0.38778374 0.28 s -0.12312420 -0.85840148 -0.49798331 0.28 s 0.38134199 0.87164766 0.30791017 0.28 s -0.32212123 0.56799728 -0.75737506 0.28 s 0.01903404 -0.86943024 -0.49368894 0.28 s 0.18837866 -0.77718014 0.60042024 0.28 s -0.22436044 0.67510802 -0.70277417 0.28 s -0.11813304 -0.17522195 0.97741592 0.28 s 0.50502074 0.75724661 0.41416380 0.28 Taygeta s 0.84316581 0.22041415 -0.49039683 0.28 s -0.95090920 -0.13392384 -0.27899113 0.28 s 0.74250144 -0.38652179 0.54707634 0.28 s -0.99484557 0.10039487 -0.01425304 0.28 s 0.11392406 0.38490945 0.91589630 0.28 s -0.49870408 -0.61860287 0.60714477 0.28 s -0.64534056 0.72707772 -0.23429383 0.28 s 0.63708252 -0.77055651 -0.01919744 0.28 s 0.32039529 0.88548440 -0.33654746 0.28 s -0.44131935 0.01987937 -0.89712989 0.28 s -0.08840758 -0.06597704 -0.99389696 0.28 s -0.73455310 0.55495054 0.39046335 0.28 s -0.44927967 -0.00594673 -0.89337140 0.28 s -0.32485694 0.38504052 -0.86383551 0.28 s -0.37072846 0.91566747 0.15528513 0.28 s -0.37429100 -0.87153536 -0.31675291 0.28 s -0.45287281 -0.31803834 -0.83292127 0.28 s -0.44083837 -0.82388532 -0.35619444 0.28 s 0.79251856 -0.53196466 0.29820794 0.28 s 0.66502851 0.36440682 0.65187788 0.28 s -0.63916934 -0.15079889 -0.75413680 0.28 s 0.06992368 -0.80530256 0.58872616 0.28 s 0.86055112 0.50707191 0.04826868 0.28 Kaitain s -0.16587691 -0.96074104 -0.22239940 0.28 s -0.53052640 -0.49321112 -0.68940884 0.28 s -0.42755157 -0.59968185 -0.67644757 0.28 s 0.69696379 -0.46591651 -0.54512686 0.28 s 0.54413867 0.17448561 0.82065088 0.28 s -0.05831341 0.86840004 0.49242356 0.28 s -0.56206453 -0.65712464 -0.50226551 0.28 s -0.40546757 0.35179511 -0.84370387 0.28 s -0.52841204 0.38098603 -0.75870311 0.28 s -0.12711592 0.90879208 -0.39741483 0.28 s -0.19314420 0.30924550 -0.93116194 0.28 s 0.48313892 -0.20218405 0.85187936 0.28 s -0.53141648 0.84551036 -0.05204546 0.28 s -0.12481058 0.17717636 -0.97623301 0.28 s 0.01657722 -0.44328278 -0.89622849 0.28 s 0.02726736 0.41007856 -0.91164249 0.28 s -0.60328889 -0.35436046 -0.71447265 0.28 s -0.14519799 -0.98675245 0.07236785 0.28 s 0.62105811 -0.25873357 0.73982686 0.28 s 0.15383331 -0.77721184 0.61014515 0.28 s -0.66706240 0.73803663 0.10163508 0.28 s 0.45020887 0.06237153 -0.89074224 0.28 s -0.56426257 -0.41823137 -0.71182179 0.28 s -0.12951040 0.50747281 0.85187936 0.28 s 0.19354033 -0.93014061 0.31205857 0.28 s -0.00721569 -0.05915827 0.99822253 0.28 s 0.40733019 -0.70741576 -0.57762021 0.28 s -0.64164531 -0.39332911 -0.65847057 0.28 s 0.25727370 -0.74331141 0.61749363 0.28 s -0.87467813 -0.10326705 0.47357589 0.28 s 0.63095373 0.69849455 0.33764294 0.28 s 0.40602708 0.53186256 0.74314481 0.28 s 0.52819836 0.10111756 -0.84307873 0.27 s 0.03574583 -0.93403858 0.35537890 0.27 s 0.00872630 0.81625903 -0.57762021 0.27 s 0.40948597 -0.91203427 -0.02268733 0.27 s 0.82104433 0.13328655 0.55508643 0.27 s 0.19749078 0.95434600 -0.22410066 0.27 s 0.40227178 -0.86169302 0.30929363 0.27 s 0.04831494 -0.47496331 -0.87867826 0.27 s 0.29454890 0.94303006 0.15471038 0.27 s 0.82632977 0.54176551 0.15384817 0.27 s -0.05900552 0.81568360 -0.57548118 0.27 s 0.44676554 0.81182420 0.37595475 0.27 s -0.94933814 -0.29909754 -0.09642483 0.27 s 0.11343280 -0.17998312 0.97710752 0.27 s -0.86933190 0.46271852 0.17364818 0.27 s 0.78449422 -0.09290864 -0.61313689 0.27 s -0.27948725 -0.94378513 0.17651214 0.27 s 0.40698856 -0.86261410 0.30042836 0.27 s 0.85962111 0.14597280 0.48963612 0.27 s 0.45594722 -0.38309401 -0.80333745 0.27 s 0.24532411 -0.73586309 0.63112724 0.27 s -0.71549881 0.19121562 -0.67193604 0.27 s 0.28730941 0.95311737 -0.09497707 0.27 s -0.23189633 0.92749894 -0.29320613 0.27 s -0.09149895 0.59505367 -0.79846042 0.27 s -0.50811285 0.86031389 0.04100374 0.27 s 0.49430963 -0.29141256 -0.81898516 0.27 s -0.26389098 0.82254076 0.50377399 0.27 s -0.30532590 0.85372001 -0.42182720 0.27 s -0.00559402 -0.86425668 0.50301993 0.27 s -0.12800963 0.57920784 -0.80506635 0.27 s 0.88919020 0.22672062 0.39741483 0.27 s 0.92560524 -0.13812649 -0.35238618 0.27 s -0.15792862 -0.91948944 -0.35999683 0.27 s -0.50389570 0.79836911 -0.32969064 0.27 s 0.97057372 -0.18032317 -0.15959403 0.27 s 0.02298781 0.93780893 0.34638995 0.27 s -0.69764161 -0.71552402 0.03635301 0.27 s -0.11436637 -0.89071536 0.43993917 0.27 s 0.94396490 0.06042309 -0.32446775 0.27 s 0.60750091 0.32858872 -0.72316808 0.27 s -0.82101715 0.53538460 0.19822760 0.27 s -0.83818758 0.15465540 0.52299452 0.27 s 0.24585836 -0.05687385 0.96763581 0.27 s -0.90903783 0.23368321 0.34502518 0.27 s 0.10816327 0.98038495 0.16476071 0.27 s -0.50053382 -0.39323345 -0.77125442 0.27 s -0.62616485 -0.45091245 -0.63607824 0.27 s -0.03198988 0.96644253 0.25488323 0.27 s 0.90729553 -0.13816090 0.39714789 0.27 s 0.82951438 -0.15062399 -0.53779018 0.27 s -0.15635182 0.93683267 -0.31288755 0.27 s -0.65044034 -0.59749973 -0.46895781 0.27 s 0.66568834 -0.74105436 -0.08773529 0.27 s 0.99445486 0.00853383 -0.10481776 0.27 s 0.54335117 0.53519386 -0.64678979 0.26 s -0.28532508 0.84946090 -0.44385335 0.26 s 0.63170600 -0.73022681 0.26022366 0.26 s 0.55902636 -0.25016221 0.79051143 0.26 s 0.49707261 -0.68499923 0.53263015 0.26 s 0.34305730 -0.84151071 0.41733843 0.26 s 0.22324082 0.34884837 0.91020238 0.26 s 0.53914094 0.81571263 -0.20961857 0.26 s 0.15973820 0.56908119 0.80661654 0.26 s -0.74105436 -0.62818170 0.23712075 0.26 s 0.25302231 0.70039827 -0.66739941 0.26 s -0.42077187 0.63541561 -0.64745510 0.26 s 0.43730050 0.88936502 -0.13340963 0.26 s -0.54583728 -0.82806736 0.12793015 0.26 s -0.63756454 0.76817757 0.05843522 0.26 s 0.96897388 0.20898332 0.13196805 0.26 s 0.00763378 -0.99971348 0.02268733 0.26 s -0.10318242 0.99142396 0.08019892 0.26 s 0.22276326 0.45910269 -0.86000073 0.26 s 0.39577371 -0.90931243 0.12850712 0.26 s -0.45596060 0.65992540 -0.59715861 0.26 s -0.15565290 0.05224441 -0.98642927 0.26 s -0.50058872 0.19316117 -0.84385997 0.26 s 0.89951193 0.42631832 0.09555619 0.26 s 0.20221521 0.95750892 -0.20563488 0.26 s -0.04400897 0.51290411 0.85731709 0.26 s -0.36911169 0.84839237 -0.37945613 0.26 s -0.53182423 0.53143775 -0.65934581 0.26 s 0.62466496 0.56782043 -0.53607237 0.26 s -0.41771671 0.64723849 -0.63764805 0.26 s 0.09275122 -0.27109694 0.95807290 0.26 s 0.80378616 -0.24376182 -0.54268587 0.26 s 0.62345457 -0.53287286 0.57214588 0.26 s -0.26585022 -0.62015063 -0.73806292 0.26 s -0.63366157 -0.02235858 -0.77328718 0.26 s -0.69899946 0.56276351 0.44124481 0.26 s 0.20210670 0.97808576 0.05001190 0.26 s -0.34811842 -0.86306834 -0.36595988 0.26 s -0.98018581 0.18757142 -0.06366144 0.26 s -0.67784494 -0.54249001 0.49621651 0.26 s -0.20716073 0.97741026 0.04187566 0.26 s 0.26480609 0.96383625 0.02995700 0.26 s -0.70452130 0.02721883 -0.70916069 0.26 s -0.40856650 0.80113685 -0.43732503 0.26 s 0.38925508 -0.16660047 -0.90593863 0.26 s 0.89065450 -0.21102051 -0.40274668 0.26 s -0.45587739 0.42190093 0.78369343 0.26 s -0.90120387 0.19299564 -0.38805184 0.26 s -0.05045146 0.96806020 0.24558938 0.26 s -0.10329635 0.83625352 -0.53852570 0.26 s 0.71236694 0.62527919 -0.31868362 0.26 s 0.67778945 -0.36762643 -0.63675135 0.26 s 0.56094795 0.67048979 0.48557267 0.26 s 0.96517771 -0.07292499 -0.25122479 0.25 s 0.73895180 -0.65099657 0.17364818 0.25 s -0.14189059 0.98161840 0.12764165 0.25 s -0.72010159 0.38517159 0.57714522 0.25 s -0.36743286 0.68645763 -0.62751019 0.25 s -0.21327783 0.65092087 -0.72857022 0.25 s -0.71369743 -0.69636691 -0.07555886 0.25 s -0.21615162 0.20664918 -0.95424032 0.25 s 0.67346323 -0.24340282 0.69799876 0.25 s 0.30583215 0.23270060 0.92321020 0.25 s 0.26141232 -0.58405304 0.76846969 0.25 s -0.18567276 0.95557445 0.22891724 0.25 s 0.68822092 -0.34357196 0.63899159 0.25 s -0.88279295 0.46971869 -0.00639950 0.25 s -0.49567762 0.36400029 0.78854769 0.25 s 0.74115986 -0.39249256 -0.54463905 0.25 s -0.36440089 0.40935403 -0.83644563 0.25 s 0.67480201 -0.27784649 0.68369848 0.25 s 0.41336924 -0.00015016 -0.91056347 0.25 s 0.38267970 0.88379163 0.26920000 0.25 s -0.38175198 -0.85843664 -0.34256676 0.25 s -0.87254339 0.25177783 0.41865975 0.25 s -0.50728703 0.23413090 -0.82936275 0.25 s -0.32204565 -0.39551240 -0.86014915 0.25 s -0.37304124 0.81089437 -0.45087752 0.25 s -0.85138297 -0.43037537 0.29987341 0.25 s 0.66048938 -0.62060261 -0.42261827 0.25 s 0.99645156 -0.07820349 0.03112001 0.25 s 0.40457919 -0.46527845 -0.78729385 0.25 s 0.73335540 -0.56927592 -0.37163791 0.25 s 0.31990430 0.80695707 -0.49646902 0.25 s 0.82319587 0.26614946 0.50151074 0.25 s 0.02470163 0.55647260 -0.83049870 0.25 s -0.64062685 0.49490950 -0.58707905 0.25 s 0.45158872 -0.76157039 -0.46484205 0.25 s -0.53488928 -0.77488375 0.33682138 0.25 s 0.03656990 0.77426517 0.63180387 0.25 s 0.09047091 0.99330837 0.07178759 0.25 s -0.39217600 0.27626556 -0.87742537 0.25 s 0.35407215 -0.40250036 0.84417200 0.25 s 0.72161698 -0.66356099 -0.19737218 0.25 s 0.64864552 0.58353084 0.48862123 0.25 s 0.19237731 -0.32394671 0.92630959 0.25 s 0.23198865 0.40548515 -0.88417363 0.25 s -0.12580250 -0.78724450 0.60367191 0.25 s -0.45387483 -0.17112784 -0.87447864 0.25 s 0.53647828 -0.59887815 0.59458894 0.25 s -0.33770442 0.74648452 -0.57333815 0.25 s -0.79905123 -0.55492443 -0.23146492 0.25 s 0.79834443 0.06399954 0.59879065 0.25 s 0.96800303 -0.24194893 0.06656414 0.25 s 0.73601788 0.16255364 0.65715599 0.25 s 0.63665992 -0.13373001 0.75946057 0.25 s -0.40142643 -0.15409318 -0.90283561 0.25 s -0.00021793 0.99855232 -0.05378835 0.25 s -0.61796004 -0.64243567 0.45321280 0.25 s 0.49390432 -0.73385423 0.46638662 0.25 s 0.43454850 -0.77633882 -0.45658040 0.25 s 0.96030891 -0.22612272 0.16332595 0.25 s -0.62891078 -0.69980556 -0.33873791 0.24 s -0.51664102 -0.34028479 0.78567696 0.24 s 0.03401508 -0.69445330 -0.71873331 0.24 s 0.48986655 -0.46243426 0.73904353 0.24 s -0.50578004 -0.61987156 -0.59995484 0.24 s -0.14457670 -0.98551857 -0.08860456 0.24 s -0.37350896 0.90396094 0.20819621 0.24 s 0.65281177 0.12906288 0.74644464 0.24 s -0.41628081 -0.57234859 -0.70648944 0.24 s 0.15154028 0.82130450 0.54999495 0.24 s 0.19555639 0.79045355 -0.58046609 0.24 s -0.93710291 0.04917980 0.34557119 0.24 s -0.14026335 0.90998548 -0.39019555 0.24 s -0.38329273 -0.82793999 -0.40939230 0.24 s 0.95437431 0.01554788 -0.29820794 0.24 s 0.96645570 -0.13088454 0.22098114 0.24 s -0.05843167 0.21781656 0.97423905 0.24 s 0.59977728 0.55694115 0.57452917 0.24 s 0.02577494 0.88582867 0.46329606 0.24 s 0.47718054 -0.47794464 0.73747385 0.24 s 0.72669274 -0.55786312 0.40088210 0.24 s -0.24129805 0.60699749 0.75718510 0.24 s -0.56601530 -0.41933897 -0.70977569 0.24 s -0.27756321 0.20448150 0.93869376 0.24 s -0.64761055 0.47825977 0.59318477 0.24 s -0.77119023 -0.41995740 -0.47843644 0.24 s 0.26393247 -0.18153717 0.94730347 0.24 s 0.24160342 0.41324770 -0.87798297 0.24 s 0.88082170 -0.04263008 -0.47152501 0.24 s 0.31477603 0.40985370 0.85611683 0.24 s -0.79842144 0.60174471 -0.02065159 0.24 s 0.59429884 -0.26299495 0.76002800 0.24 s 0.03100398 -0.87868637 -0.47639167 0.24 s -0.56933069 0.53776222 0.62183148 0.24 s -0.51899892 0.24307092 -0.81948560 0.24 s -0.46431106 0.16093341 -0.87092805 0.24 s 0.43375525 -0.80333018 0.40806493 0.24 s -0.49780715 0.31076255 0.80970037 0.24 s 0.62478304 -0.28791878 0.72577471 0.24 s 0.21837626 -0.89666557 0.38510081 0.24 s -0.40000933 -0.78775179 -0.46844387 0.24 s -0.58271664 0.36524224 -0.72597480 0.24 s 0.60759264 -0.65080404 0.45528594 0.24 s 0.44558331 0.61942911 -0.64634597 0.24 s 0.44807515 0.65705884 -0.60621977 0.24 s -0.38400185 0.79140645 -0.47562420 0.24 s -0.37759697 -0.19957590 0.90420681 0.24 s -0.07294838 -0.68447828 -0.72537440 0.24 s 0.14177898 -0.38603708 0.91152292 0.24 s 0.90184158 -0.15645072 0.40274668 0.24 s 0.68237066 0.12436663 -0.72034937 0.24 s 0.22337872 -0.72685570 -0.64944804 0.24 s -0.29138216 -0.28530109 0.91307157 0.24 s -0.38911173 -0.88870269 0.24248636 0.23 s 0.10682285 0.99070156 -0.08425757 0.23 s 0.14400120 0.98809874 0.05407881 0.23 s -0.47652251 -0.15552144 -0.86529726 0.23 s 0.37150717 -0.82760704 -0.42077196 0.23 s -0.02413862 -0.30557412 0.95186228 0.23 s -0.65826267 0.61366093 -0.43601662 0.23 s 0.27440950 0.57682210 0.76939952 0.23 s -0.85426462 0.46810013 -0.22608463 0.23 s -0.79012364 0.61104399 -0.04826868 0.23 s 0.53713828 -0.01316654 0.84339142 0.23 s -0.76703280 0.21734965 -0.60367191 0.23 s -0.27872720 0.33153710 0.90132916 0.23 s -0.47359625 -0.76981950 -0.42788377 0.23 s -0.12446178 0.98464006 -0.12244676 0.23 s -0.48465982 0.10165546 -0.86877561 0.23 s -0.48737666 -0.60907125 -0.62569660 0.23 s 0.77844036 0.05818966 0.62501562 0.23 s -0.45049474 0.10704608 -0.88633829 0.23 s -0.71847332 -0.63137943 0.29181531 0.23 s 0.50809246 -0.63933206 0.57714522 0.23 s -0.69282335 -0.64259183 0.32721791 0.23 s 0.33564925 -0.90092820 -0.27507806 0.23 s 0.00210433 -0.99793214 -0.06424203 0.23 s -0.38918781 -0.62688118 0.67494655 0.23 s 0.87834603 0.47475484 0.05582150 0.23 s 0.51723754 0.57085049 0.63764805 0.23 s 0.99478614 0.02315390 -0.09931975 0.23 s -0.58503211 -0.79194981 -0.17479393 0.23 s 0.24218698 -0.96746147 0.07323819 0.23 s -0.37310010 0.81086731 -0.45087752 0.23 s -0.59885019 0.52172047 -0.60760689 0.23 s -0.14610070 -0.78194159 0.60598838 0.23 s -0.47400570 0.82210612 -0.31537300 0.23 s 0.12116331 0.98442906 -0.12735313 0.23 s -0.30682901 0.57063848 -0.76172680 0.23 s -0.01604458 0.93875706 0.34420598 0.23 s -0.09553067 -0.98536265 -0.14118922 0.23 s -0.58047736 0.06417061 -0.81174392 0.23 s -0.40491894 -0.58468646 -0.70298105 0.23 s -0.64980280 0.74960184 -0.12591040 0.23 s -0.48396870 -0.75676107 0.43941665 0.23 s 0.49695498 0.12544136 0.85866189 0.23 s -0.38730085 -0.91039860 -0.14550747 0.23 s -0.35573354 0.80481172 -0.47511238 0.23 s -0.96337789 0.23566283 0.12793015 0.23 s 0.44609889 -0.76417220 0.46587193 0.23 s 0.58184826 -0.21937862 0.78315109 0.23 s -0.49828222 -0.12112272 -0.85851276 0.23 s 0.47608897 0.77462870 -0.41628081 0.23 s 0.06349154 -0.46100545 -0.88512301 0.23 s 0.10769976 -0.73154998 -0.67322761 0.23 s -0.90241557 0.17868304 0.39206955 0.23 s -0.54091758 -0.11095237 -0.83372521 0.23 s 0.45694363 0.79091817 -0.40700236 0.23 s -0.99333221 -0.00375623 0.11522610 0.23 s 0.22847429 0.90126789 0.36812454 0.23 s -0.48068103 -0.76171064 -0.43444526 0.23 s -0.75465822 -0.13267063 -0.64256477 0.23 s 0.87245959 0.45215955 -0.18538077 0.23 s -0.33055645 0.79119009 -0.51453930 0.23 s -0.31852117 -0.57002389 -0.75737506 0.23 s 0.03147732 -0.98790437 0.15183589 0.23 s -0.55713308 -0.27975208 -0.78188330 0.23 s 0.62316930 -0.15484412 0.76660508 0.23 s 0.01165268 0.45254412 -0.89166588 0.23 s -0.28983584 0.83503139 -0.46767271 0.23 s 0.90527886 -0.00882178 0.42472619 0.23 s -0.25941166 -0.46575218 -0.84603810 0.22 s -0.48044780 0.17780249 -0.85881090 0.22 s 0.86267912 0.28760239 0.41601631 0.22 s 0.11286896 -0.49662730 0.86059391 0.22 s -0.17516178 0.96946234 0.17164253 0.22 s 0.17168473 0.27044490 0.94730347 0.22 s -0.60092962 -0.26269567 0.75490040 0.22 s 0.66950482 0.57917672 0.46509957 0.22 s 0.35484865 0.89910966 0.25628939 0.22 s -0.29607716 -0.93666083 -0.18709558 0.22 s 0.36333355 -0.78467703 0.50226551 0.22 s 0.88835812 0.28636122 0.35891101 0.22 s -0.97578120 -0.16876592 -0.13917311 0.22 s 0.07013466 -0.88784420 -0.45476785 0.22 s -0.22559093 0.91128641 -0.34447908 0.22 s 0.60129213 -0.59450883 -0.53386050 0.22 s 0.60646892 -0.75362128 0.25347656 0.22 s 0.91551906 -0.40156692 0.02385057 0.22 s 0.36859131 -0.92957336 -0.00581773 0.22 s -0.47385913 -0.67527664 -0.56520700 0.22 s 0.00020911 -0.95757133 0.28819627 0.22 s -0.64713687 -0.12164438 -0.75260645 0.22 s -0.52312970 -0.24602675 0.81596947 0.22 s -0.32998198 0.29995352 0.89506412 0.22 s 0.76538110 -0.55057293 -0.33325839 0.22 s 0.39664608 0.51397216 0.76059484 0.22 s 0.72679162 -0.66394222 0.17593946 0.22 s 0.23092206 0.93603152 0.26555610 0.22 s 0.27591616 0.94483531 0.17651214 0.22 s -0.02599334 0.96580160 -0.25797603 0.22 s -0.60834932 0.70426166 0.36595988 0.22 s -0.69911027 0.20719647 0.68433505 0.22 s 0.00115989 -0.99709654 0.07613896 0.22 s 0.51674223 -0.35481530 0.77915567 0.22 s -0.79543382 0.29450297 0.52967256 0.22 s -0.81257063 0.57719737 0.08106875 0.22 s 0.89433539 -0.30976406 -0.32281640 0.22 s 0.47836727 -0.26693976 -0.83660501 0.22 s -0.37578639 0.82173586 -0.42840952 0.22 s 0.33179748 0.90260923 0.27423897 0.22 s 0.80585849 -0.57614058 -0.13658011 0.22 s -0.49201900 0.21032917 -0.84479523 0.22 s 0.33367622 0.18293479 -0.92476755 0.22 s 0.10183129 -0.98260719 -0.15528513 0.22 s -0.50443983 0.86310112 -0.02443218 0.22 s -0.91509014 -0.38827568 -0.10886688 0.22 s 0.92776096 -0.10864491 -0.35700971 0.22 s -0.42139581 0.43516329 -0.79564971 0.22 s 0.90221822 -0.20042992 -0.38187706 0.22 s 0.74652761 0.45077863 -0.48938245 0.22 s 0.38334435 0.88798147 0.25403929 0.22 s 0.13636713 -0.31990126 0.93758583 0.22 s -0.72719985 0.57165080 -0.37999436 0.22 s 0.73155534 -0.07984903 -0.67709005 0.22 s 0.16005714 0.91826838 -0.36216691 0.22 s 0.28197667 0.16601412 0.94494891 0.22 s -0.63551754 -0.18910378 -0.74857008 0.22 s 0.27797318 0.36025047 -0.89047772 0.22 s 0.13165614 0.99111515 -0.01890661 0.22 s -0.84907401 -0.35046884 -0.39527830 0.22 s 0.64356589 -0.54990029 -0.53238392 0.22 s 0.54723161 0.54137325 0.63832009 0.22 s 0.12298000 -0.96001065 -0.25150633 0.22 s -0.24138652 0.22976883 -0.94283551 0.22 s 0.69942433 0.69769716 0.15499777 0.22 s -0.81875283 0.07085166 -0.56975776 0.22 s 0.20468327 -0.97374678 -0.09960920 0.22 s 0.33670008 0.68200994 0.64922684 0.22 s 0.43405506 -0.78440046 -0.44307119 0.22 s -0.67887157 0.55367440 -0.48226342 0.22 s 0.46918985 0.20380674 0.85925764 0.22 s -0.31006375 0.60624379 -0.73234487 0.22 s 0.47290644 -0.86872417 0.14723399 0.22 s -0.38618940 -0.21771760 -0.89635754 0.22 s 0.09444781 -0.02779006 0.99514186 0.22 s -0.85799474 0.49428251 0.13974920 0.22 s 0.94456476 0.11618715 0.30707979 0.22 s 0.13567491 0.75279284 0.64412361 0.21 s -0.52826363 0.81905031 -0.22381717 0.21 s -0.45131665 -0.00850153 -0.89232337 0.21 s 0.12658942 0.52242672 -0.84323514 0.21 s -0.74081689 -0.39313945 -0.54463905 0.21 s -0.74722964 -0.40234149 -0.52893215 0.21 s -0.47091872 -0.49242955 -0.73194855 0.21 s 0.18109690 -0.97080469 -0.15729633 0.21 s 0.34682295 0.13650067 0.92794472 0.21 s -0.47548035 -0.09594555 -0.87447864 0.21 s -0.33511201 -0.62031531 -0.70916069 0.21 s 0.67573118 -0.72042030 -0.15614715 0.21 s 0.69763827 -0.06763587 -0.71325046 0.21 s 0.16611966 0.98608291 -0.00669038 0.21 s -0.26851073 0.75510830 -0.59809148 0.21 s -0.71657395 -0.25216976 0.65033239 0.21 s 0.78140461 -0.53370470 -0.32336697 0.21 s -0.94705522 0.06304171 -0.31482089 0.21 s 0.51429278 0.37922710 0.76921374 0.21 s -0.53353524 -0.77593553 -0.33654746 0.21 s -0.69247901 0.57337755 -0.43784818 0.21 s 0.28128532 0.92751664 0.24615330 0.21 s 0.72724044 -0.48991469 0.48073372 0.21 s -0.94824213 -0.08594919 0.30569530 0.21 s -0.18816109 -0.98210680 -0.00785390 0.21 s -0.08253916 -0.17771381 -0.98061466 0.21 s -0.28566617 0.11784035 -0.95105654 0.21 s 0.32143158 -0.75939459 0.56568682 0.21 s 0.60425419 0.79188216 -0.08831481 0.21 s -0.76209050 0.33169585 0.55605388 0.21 s -0.39315727 0.02017448 -0.91924989 0.21 s 0.56172287 0.47050673 -0.68050778 0.21 s -0.39691365 0.61451441 -0.68178558 0.21 s -0.75366765 0.52145863 -0.40008247 0.21 s -0.22999281 0.94615936 0.22778443 0.21 s 0.36666298 -0.06690929 0.92794472 0.21 s -0.33974862 -0.60542524 0.71974379 0.21 s 0.20176587 -0.71401590 -0.67042661 0.21 s 0.38105929 -0.27201617 0.88362944 0.21 s -0.46364540 -0.67893577 -0.56927955 0.21 s -0.89441341 -0.31848612 -0.31399244 0.21 s 0.18962508 0.17449650 -0.96622634 0.21 s -0.72857916 -0.38657746 0.56544697 0.21 s -0.96705627 0.25084803 -0.04332877 0.21 s 0.03110767 0.79468858 0.60621977 0.21 s -0.70743579 0.28140369 0.64834142 0.21 s -0.51736784 -0.34946200 0.78115737 0.21 s -0.21296214 0.63067943 -0.74625105 0.21 s 0.83046091 0.44863835 0.33023983 0.21 s 0.56175494 -0.79732305 -0.22069743 0.21 s -0.50239944 -0.31975570 -0.80333745 0.21 s 0.03292004 0.99893647 0.03228298 0.21 s 0.11335223 -0.03710397 0.99286181 0.21 s -0.00086491 -0.91484183 -0.40381145 0.21 s 0.87255561 -0.48707217 -0.03751577 0.21 s -0.98031247 0.10008065 -0.17020950 0.21 s 0.76004672 0.59425884 -0.26303121 0.21 s -0.25628382 0.40611970 -0.87714618 0.21 s 0.37856477 0.39730066 0.83596706 0.21 s 0.96471202 0.18839484 -0.18395136 0.21 s -0.89227659 -0.35801476 -0.27507806 0.21 s -0.20304488 0.96910387 0.14003722 0.21 s -0.49736601 -0.79018611 0.35809636 0.21 s 0.65251034 0.09001134 -0.75241488 0.21 s -0.46823519 -0.48402569 0.73923945 0.21 s 0.68545693 0.63381481 -0.35836795 0.21 s 0.83598286 0.30207160 0.45813251 0.21 s -0.43852594 0.51701605 -0.73511183 0.21 s 0.37128833 0.84816349 0.37784079 0.21 s -0.57593590 -0.40596455 -0.70957077 0.21 s -0.20989536 -0.70840639 -0.67387265 0.21 s 0.10045542 0.84036529 0.53263015 0.21 s 0.30840084 -0.38226208 -0.87107098 0.21 s -0.05561549 -0.64817166 -0.75946057 0.21 s 0.87889165 -0.20654689 0.42998594 0.21 s 0.23229678 0.76738673 0.59762514 0.21 s -0.99026525 0.12897924 -0.05233596 0.21 s 0.40489575 -0.67686707 -0.61474419 0.21 s -0.71789730 -0.51728797 -0.46587193 0.21 s -0.27205423 0.26606664 0.92476755 0.21 s 0.30395427 -0.88004363 0.36487678 0.20 s 0.79772556 0.45094857 0.40034905 0.20 s 0.57576817 -0.75820315 -0.30597228 0.20 s -0.77357334 0.13942026 0.61817980 0.20 s 0.07702870 -0.53842491 0.83914554 0.20 s -0.61819369 -0.06502022 0.78333193 0.20 s -0.06247783 -0.37318552 -0.92565066 0.20 s 0.22381185 0.00154625 -0.97463113 0.20 s 0.97317219 0.22922632 -0.01977911 0.20 s -0.92278069 -0.24266094 0.29931834 0.20 s 0.10812674 0.98862654 -0.10452846 0.20 s 0.50197315 -0.74936742 0.43182340 0.20 s -0.73400724 0.49416265 -0.46587193 0.20 s -0.74875665 0.62958127 -0.20734258 0.20 s -0.37439087 -0.71134895 0.59482276 0.20 s -0.02901771 0.35200873 0.93554682 0.20 s -0.37688380 -0.79282290 -0.47894722 0.20 s -0.42391863 0.75182301 -0.50502986 0.20 s 0.36529380 0.88810158 0.27899113 0.20 s 0.08367763 -0.41640168 -0.90532190 0.20 s 0.62517256 0.11605701 0.77180958 0.20 s -0.44561729 0.67645597 -0.58637238 0.20 s 0.49011189 -0.51986682 0.69966334 0.20 s 0.25292557 0.94283420 -0.21700758 0.20 s 0.24751100 0.37406650 0.89376312 0.20 s 0.67416251 -0.33020788 -0.66065699 0.20 s 0.26882088 -0.14023751 0.95292646 0.20 s 0.79985726 -0.36740011 0.47460037 0.20 s 0.57489902 0.08020000 0.81428438 0.20 s -0.34570813 -0.83684957 -0.42446283 0.20 s -0.35612595 -0.12132186 -0.92652863 0.20 s 0.91718292 -0.38995078 0.08193851 0.20 s -0.12591429 0.72644579 0.67559022 0.20 s -0.93893272 -0.33065030 0.09526664 0.20 s -0.33079737 0.52708077 0.78278923 0.20 s -0.03276205 -0.76440698 -0.64390105 0.20 s -0.35692322 0.36644524 -0.85925764 0.20 s -0.28695485 0.26202586 0.92141163 0.20 s 0.46988896 0.11078843 0.87574553 0.20 s -0.79750377 -0.60205412 -0.03896915 0.20 s 0.62409198 -0.00431145 0.78133899 0.20 s 0.64884913 0.74532014 -0.15327330 0.20 s 0.59465134 -0.71806508 0.36162457 0.20 s -0.11367029 -0.90668434 -0.40620512 0.20 s 0.09127966 0.98787004 -0.12562183 0.20 s 0.66875166 0.41984609 0.61359632 0.20 s 0.38763788 0.87167239 0.29987341 0.20 s 0.00791206 0.89914143 0.43758664 0.20 s -0.02579050 0.57347327 -0.81881821 0.20 s 0.25079817 0.95996678 -0.12475602 0.20 s -0.40645882 0.14346907 -0.90233469 0.20 s -0.91056448 0.34248549 -0.23146492 0.20 s -0.03639071 -0.36060649 0.93200785 0.20 s -0.85394716 0.39941239 0.33353263 0.20 s -0.35593855 0.29616234 -0.88633829 0.20 s -0.67093390 -0.46112010 0.58070296 0.20 s -0.63491046 -0.64674765 0.42261827 0.20 s -0.84814042 -0.25600144 0.46381152 0.20 s -0.16368993 0.60178709 -0.78170192 0.20 s 0.93658501 0.05981393 0.34529820 0.20 s -0.95854139 -0.23167410 -0.16590825 0.20 s -0.61903071 -0.07194365 -0.78206462 0.20 s -0.89559877 -0.08827452 0.43601662 0.20 s -0.75676310 0.63228476 -0.16590825 0.20 s 0.10336103 -0.93064398 -0.35102463 0.20 s 0.58137041 -0.48452261 -0.65364075 0.20 s -0.91233605 -0.13981064 0.38483235 0.20 s 0.82175195 -0.29193929 0.48938245 0.20 s -0.22313856 0.38519248 -0.89545292 0.20 s -0.47536597 -0.53174561 -0.70090926 0.20 s -0.41436145 -0.90993375 0.01803409 0.20 s 0.20976567 0.94004279 0.26891983 0.20 s -0.62135917 0.45532158 0.63764805 0.20 s -0.43291122 -0.68767315 0.58283234 0.20 s 0.15127839 0.80607933 -0.57214588 0.20 s 0.07536690 -0.31162876 0.94721031 0.20 s 0.17850585 -0.87575579 0.44853920 0.20 s -0.25370240 -0.96448362 -0.07352830 0.20 s -0.97038752 0.15101901 -0.18852413 0.20 s -0.38616669 0.53872937 -0.74876297 0.20 s 0.21593592 -0.89656359 -0.38671097 0.20 s 0.50076246 0.12253579 0.85686755 0.20 s -0.30131468 0.86749166 -0.39581266 0.20 s -0.45295489 -0.80290943 0.38751557 0.20 s -0.44376576 0.38508028 0.80918795 0.20 s -0.21720505 0.91290885 -0.34557119 0.20 s -0.22778793 0.73529595 -0.63832009 0.20 s -0.41530225 0.14276354 -0.89841115 0.20 s -0.04014044 -0.84986371 -0.52547169 0.20 s 0.94902354 -0.07573150 -0.30597228 0.20 s -0.48490441 0.68369472 -0.54537070 0.20 s 0.53507072 0.63046890 0.56232393 0.20 s 0.04679495 -0.41097867 0.91044319 0.20 s 0.07772610 0.37991428 -0.92175037 0.20 s 0.24508192 -0.96412981 -0.10192446 0.20 s -0.18240361 -0.11492124 0.97648454 0.20 s -0.67676693 -0.58537310 0.44645810 0.20 s 0.83229905 0.10188630 -0.54488295 0.20 s -0.21111830 -0.66201967 0.71913773 0.20 s 0.37596491 -0.57180840 0.72916770 0.20 s 0.67773950 -0.65220314 -0.33955887 0.20 s -0.73429620 -0.33257636 0.59177870 0.20 s 0.46593019 -0.51324898 0.72075278 0.20 s -0.15505734 -0.82324350 0.54610193 0.20 s 0.65142590 0.26203662 0.71202606 0.20 s 0.44063172 0.88312691 0.16102967 0.20 s 0.70852768 -0.24569598 -0.66153008 0.20 s 0.64471787 -0.12026765 0.75490040 0.20 s 0.90895122 -0.37356064 -0.18509492 0.20 s -0.98757005 0.06350274 0.14378048 0.20 s 0.28569826 0.25176615 -0.92465687 0.20 s 0.44551736 -0.64954650 0.61611980 0.20 s 0.26505041 0.31582814 0.91104382 0.20 s -0.51743925 0.21265711 0.82887489 0.20 s -0.76289868 -0.48789388 0.42419943 0.20 s 0.59051758 0.33127010 -0.73590016 0.20 s 0.44506428 -0.77909589 -0.44150588 0.20 s -0.68036729 0.30892670 -0.66457856 0.20 s -0.14509122 -0.40365073 0.90333527 0.20 s -0.16533522 0.95553166 -0.24417922 0.20 s 0.59883142 0.39342111 0.69758207 0.20 s 0.91825777 0.38121569 0.10713176 0.20 s -0.35172370 0.85053533 -0.39099887 0.19 s 0.07813374 0.95546496 0.28457311 0.19 s 0.51730055 -0.06802738 0.85309577 0.19 s 0.75081527 0.62759346 -0.20591953 0.19 s 0.56378180 -0.18964235 -0.80385685 0.19 s 0.18000060 0.19979399 0.96316260 0.19 s -0.62442708 -0.17772542 -0.76059484 0.19 s -0.32987714 0.71187925 -0.62000728 0.19 s -0.44915211 -0.05220038 -0.89192909 0.19 s -0.75142878 -0.24433523 -0.61290705 0.19 s 0.64378905 0.76294625 0.05872561 0.19 s -0.22997481 0.08933602 0.96908754 0.19 s -0.96463782 0.25591934 0.06308083 0.19 s -0.36472803 -0.90958202 0.19908288 0.19 s 0.87474823 -0.47651559 0.08802506 0.19 s 0.29274210 -0.85563815 -0.42683181 0.19 s 0.09069140 -0.99412888 0.05901600 0.19 s -0.62354118 0.73190314 -0.27479839 0.19 s -0.54722100 0.28805929 -0.78585690 0.19 s -0.41052175 0.13563468 -0.90170676 0.19 s 0.28668535 0.62581432 0.72537440 0.19 s -0.33213502 0.41260073 -0.84820223 0.19 s -0.00998397 -0.71501333 -0.69903958 0.19 s -0.35555473 -0.78109699 0.51329166 0.19 s -0.28928342 -0.33766189 -0.89571172 0.19 s -0.78675956 -0.54961693 0.28094590 0.19 s 0.80654240 0.45014569 -0.38322085 0.19 s 0.42962658 0.66526783 -0.61060601 0.19 s 0.13056912 0.91838384 0.37352750 0.19 s -0.39061978 0.45567679 -0.79985929 0.19 s 0.68341964 0.46554205 0.56232393 0.19 s -0.55830467 0.66713309 -0.49318290 0.19 s 0.99804622 -0.00580664 -0.06220988 0.19 s 0.43760321 0.88138503 -0.17794354 0.19 s 0.15795927 0.76668626 0.62228698 0.19 s -0.49121752 -0.83544898 -0.24643521 0.19 s 0.49505082 -0.11744348 0.86089009 0.19 s -0.19736454 -0.80402803 -0.56087983 0.19 s -0.68817520 -0.13730271 0.71243441 0.19 s -0.17540766 -0.51896459 0.83660501 0.19 s 0.04356901 0.90843391 0.41575176 0.19 s -0.75370693 -0.64173865 0.14176513 0.19 s -0.37203613 -0.13034596 -0.91902071 0.19 s 0.42125380 -0.84152979 -0.33819047 0.19 s -0.10184380 0.49798256 0.86118591 0.19 s 0.15624267 -0.79760277 -0.58259594 0.19 s 0.59881485 0.70339775 -0.38295215 0.19 s 0.77377772 0.62594092 0.09729340 0.19 s 0.72888887 -0.26799837 0.62999833 0.19 s 0.02495420 0.83060968 -0.55629563 0.19 s 0.20216906 -0.77153599 -0.60320795 0.19 s -0.06711224 -0.92681342 -0.36947647 0.19 s 0.65597028 0.24634525 0.71345431 0.19 s 0.51943636 -0.02934419 0.85400516 0.19 s -0.00721955 -0.74640971 -0.66544753 0.19 s 0.43627560 -0.17409295 -0.88281101 0.19 s -0.06916926 -0.56674707 0.82098317 0.19 s -0.06895115 -0.56701422 0.82081705 0.19 s -0.61379522 0.63829201 -0.46458447 0.19 s 0.56279957 -0.00245569 0.82658976 0.19 s -0.54807293 0.22319970 -0.80610049 0.19 s 0.56142515 -0.61286694 -0.55605388 0.19 s -0.22136331 0.66917747 -0.70936573 0.19 s -0.96770489 -0.17884387 0.17765729 0.19 s 0.78558135 0.58103442 -0.21274617 0.19 s 0.96262485 0.04729073 -0.26667771 0.19 s 0.26954514 -0.61102027 -0.74431151 0.19 s 0.63036680 -0.46319139 0.62296981 0.19 s -0.76719207 0.46921542 -0.43732503 0.19 s 0.23884109 0.75654775 0.60876143 0.19 s 0.63112193 -0.77440661 -0.04449121 0.19 s -0.42357191 0.84847194 0.31730467 0.19 s 0.46617064 -0.51104391 -0.72216278 0.19 s -0.83042198 0.31365228 -0.46045801 0.19 s -0.80757344 -0.51870161 -0.28066671 0.19 s -0.41918802 0.01488249 -0.90777743 0.19 s 0.18677704 -0.97182381 -0.14378048 0.19 s -0.82957613 -0.22331911 0.51179296 0.19 s -0.17564401 0.68388212 0.70813447 0.19 s -0.38067678 -0.68253899 -0.62387955 0.19 s 0.04447455 0.97471189 0.21899480 0.19 s -0.34522679 0.74742484 0.56760424 0.19 s -0.11584885 -0.40423518 0.90728879 0.19 s -0.13233583 -0.31360084 -0.94028813 0.19 s 0.90096557 0.35316014 -0.25206935 0.19 s -0.08696792 0.99488091 -0.05146447 0.19 s -0.23030896 -0.94776076 0.22069743 0.18 s -0.20421101 0.00034154 -0.97892684 0.18 s 0.68985879 0.54800171 -0.47306341 0.18 s 0.21535380 0.92269146 0.31978625 0.18 s -0.22812514 -0.61628968 0.75375462 0.18 s -0.80883425 -0.18190791 -0.55919290 0.18 s 0.61572093 0.70147747 0.35891101 0.18 s 0.94898671 -0.27555671 0.15327330 0.18 s -0.12883791 -0.08872730 -0.98768836 0.18 s -0.26317337 -0.66881788 -0.69528586 0.18 s 0.23751955 0.90887028 -0.34284005 0.18 s 0.61553019 0.13317606 0.77677971 0.18 s -0.56310928 -0.64003438 -0.52274656 0.18 s 0.58039623 0.49680117 0.64523548 0.18 s -0.75909036 0.04471052 -0.64944804 0.18 s 0.34931159 -0.71408540 0.60668230 0.18 s -0.89722914 0.33285958 -0.29014549 0.18 s 0.07640335 0.99674088 0.02588616 0.18 s 0.59592098 -0.68021530 0.42683181 0.18 s 0.60672218 -0.79332078 -0.05030242 0.18 s 0.38132721 -0.22765498 0.89597028 0.18 s -0.03724449 0.47544655 0.87895590 0.18 s -0.05118047 0.12195206 0.99121553 0.18 s -0.28900653 -0.68612248 0.66761601 0.18 s 0.29472715 -0.53371400 0.79264450 0.18 s -0.48682529 -0.16348018 -0.85806489 0.18 s -0.61452729 -0.53884691 -0.57619458 0.18 s -0.49635291 -0.09184428 -0.86324877 0.18 s 0.14579892 -0.61637163 0.77384019 0.18 s -0.30085358 0.95080912 -0.07381839 0.18 s 0.37507841 0.92699265 -0.00087266 0.18 s -0.82713884 -0.42928243 0.36270913 0.18 s -0.23800248 0.73613745 0.63360596 0.18 s -0.45093250 -0.82578236 -0.33873791 0.18 s -0.11178944 0.65687108 -0.74566984 0.18 s -0.42516062 -0.30499357 -0.85218388 0.18 s 0.98937410 -0.14374621 0.02181488 0.18 s -0.69630247 -0.70230341 -0.14809710 0.18 s -0.17843515 0.62330371 -0.76134974 0.18 s -0.47475380 0.51901150 -0.71079946 0.18 s -0.02084864 0.95867562 -0.28373644 0.18 s 0.34078816 0.66061860 -0.66891444 0.18 s 0.74790740 -0.38878325 -0.53803539 0.18 s -0.31961322 -0.89716506 -0.30486429 0.18 s 0.16374253 0.91194499 0.37622428 0.18 s -0.72515899 -0.24163838 0.64479095 0.18 s -0.53455228 -0.14502597 0.83259910 0.18 s -0.90703493 -0.21476220 0.36216691 0.18 s 0.86951858 -0.06080266 0.49014330 0.18 s -0.91496825 -0.39847246 0.06366144 0.18 s -0.44700110 -0.87728965 -0.17479393 0.18 s 0.08344409 0.99631613 -0.01977911 0.18 s -0.88299310 -0.10216565 0.45813251 0.18 s -0.62070960 -0.66156673 0.42077196 0.18 s -0.61844587 -0.76508135 -0.17937458 0.18 s -0.75392783 0.51695025 -0.40540752 0.18 s -0.46656194 0.03897337 -0.88362944 0.18 s 0.34665465 0.74694562 0.56736475 0.18 s -0.58923596 0.51394796 -0.62342483 0.18 s -0.24656884 0.55608672 -0.79370737 0.18 s -0.49797058 0.86483264 -0.06395174 0.18 s 0.21917123 -0.81795818 0.53189135 0.18 s 0.31839654 -0.51260453 -0.79740846 0.18 s 0.20676997 0.76169670 0.61405569 0.18 s -0.73283750 -0.61893040 0.28262049 0.18 s -0.86358720 0.20998752 -0.45839104 0.18 s 0.72335118 0.47139680 0.50452763 0.18 s -0.26726878 0.10929718 -0.95740354 0.18 s 0.69581270 -0.21262066 0.68603003 0.18 s -0.37797147 0.16802026 0.91044319 0.18 s 0.44350588 -0.66668826 0.59902358 0.18 s 0.46405286 0.56011373 0.68624163 0.18 s -0.10645624 -0.22194259 0.96923089 0.18 s 0.15319481 0.98767799 0.03199225 0.18 s 0.43009767 -0.81690460 0.38429531 0.18 s 0.42828166 -0.67594987 0.59972215 0.18 s -0.05048408 0.95929015 0.27787358 0.18 s 0.37905547 -0.68489116 0.62228698 0.18 s -0.86427528 -0.19834244 0.46226457 0.18 s -0.73368162 -0.67830724 -0.04013179 0.18 s -0.91158015 -0.06507652 0.40593928 0.18 s -0.33782956 -0.05159463 0.93979210 0.18 s 0.58027601 0.57556885 0.57619458 0.18 s -0.45406240 0.75930941 0.46612930 0.18 s -0.40916622 0.87364173 -0.26331183 0.18 s 0.08203785 -0.92376596 0.37406713 0.18 s -0.16036083 0.63999856 -0.75145608 0.18 s -0.80804950 0.49098003 -0.32556817 0.18 s 0.39993599 -0.52089244 0.75413680 0.18 s -0.00786288 0.98290390 -0.18395136 0.18 s 0.68768060 0.32274318 0.65033239 0.18 s 0.37414676 0.80557001 0.45942485 0.18 s 0.01266205 0.56338376 0.82609832 0.18 s 0.53362268 -0.80405450 0.26218918 0.18 s 0.66935116 0.12849292 0.73175037 0.18 s 0.40723345 -0.90507883 -0.12244676 0.18 s 0.09607170 -0.68903852 -0.71832871 0.18 s -0.29339334 -0.49700797 0.81664157 0.18 s 0.66313875 0.22569703 -0.71365809 0.18 s 0.66448891 0.31623346 0.67709005 0.18 s 0.68812907 -0.04198734 0.72437245 0.18 s -0.98901290 0.13921668 0.04972137 0.18 s -0.99439210 -0.08852836 0.05785443 0.18 s -0.52373785 -0.74994665 -0.40407753 0.18 s -0.30614492 0.85640281 -0.41575176 0.18 s 0.00608533 -0.92975658 0.36812454 0.17 s 0.46866211 0.68425024 0.55871052 0.17 s -0.69467783 -0.52434886 -0.49242356 0.17 s 0.55009466 -0.61542708 0.56448686 0.17 s 0.40572971 0.84367198 0.35156935 0.17 s -0.42437962 0.78569287 0.45009845 0.17 s -0.33193147 0.88523877 -0.32584319 0.17 s -0.33813775 0.01486194 -0.94097924 0.17 s 0.31428838 -0.89205652 -0.32474291 0.17 s 0.01571404 0.79725361 -0.60343993 0.17 s -0.78298187 0.59037656 0.19594614 0.17 s 0.37325928 0.88398695 0.28150418 0.17 s 0.23938936 0.42012000 -0.87532389 0.17 s 0.25061789 -0.45251483 0.85581601 0.17 s 0.62164336 -0.17698199 0.76304448 0.17 s -0.13223910 -0.17456104 0.97572601 0.17 s 0.24225706 -0.96744388 0.07323819 0.17 s 0.84879494 -0.09689528 0.51976764 0.17 s 0.31196800 -0.81129372 0.49444762 0.17 s 0.23072335 0.38948518 0.89166588 0.17 s -0.14153410 -0.33336607 0.93211329 0.17 s -0.89982146 -0.36545566 0.23825097 0.17 s -0.71604592 0.11720360 0.68814355 0.17 s -0.87827933 -0.27292302 -0.39260468 0.17 s -0.72245282 0.68568194 0.08889429 0.17 s -0.62768620 0.74793684 -0.21587159 0.17 s 0.45964015 -0.07105318 0.88525838 0.17 s 0.04429956 -0.85240042 0.52100962 0.17 s 0.97023469 -0.17559271 -0.16676876 0.17 s -0.22562863 0.46768966 0.85460991 0.17 s -0.52378267 -0.24908385 -0.81462198 0.17 s 0.14320262 0.60441506 0.78369343 0.17 s 0.49464625 0.18024023 0.85019910 0.17 s 0.31087279 0.30758953 -0.89930350 0.17 s -0.27034497 0.95990705 -0.07410849 0.17 s -0.35769463 0.16119225 -0.91982150 0.17 s 0.31793088 0.17626220 0.93158555 0.17 s -0.72951365 -0.32023406 0.60436738 0.17 s 0.14757581 0.94284779 0.29876319 0.17 s -0.27882656 -0.57817471 -0.76679182 0.17 s -0.52879095 0.80398750 -0.27200034 0.17 s -0.37448764 -0.64548403 -0.66566461 0.17 s 0.64838588 0.30011147 0.69966334 0.17 s -0.18170454 0.80519444 -0.56448686 0.17 s 0.16936840 -0.50680053 0.84526181 0.17 s 0.89935613 0.43242818 -0.06453231 0.17 s -0.23820779 -0.94023728 0.24333288 0.17 s 0.54852194 -0.46662214 0.69382089 0.17 s 0.05396115 -0.51520890 0.85536426 0.17 s -0.96129376 0.25420913 0.10626407 0.17 s -0.45545447 -0.60322106 0.65474081 0.17 s 0.16115043 0.98498553 0.06191955 0.17 s 0.37247863 -0.74355233 0.55532837 0.17 s -0.23516375 0.94114900 -0.24276856 0.17 s 0.12204800 0.78498334 0.60737586 0.17 s -0.42895958 -0.75382859 0.49773106 0.17 s 0.43363494 -0.00457264 -0.90107703 0.17 s -0.88614577 -0.10481694 0.45139676 0.17 s 0.40325671 0.51637721 0.75547242 0.17 s 0.47992542 0.69993025 -0.52893215 0.17 s 0.75965726 0.48131862 0.43732503 0.17 s -0.42586836 -0.51723224 -0.74236578 0.17 s 0.02369375 -0.72538787 0.68793243 0.17 s -0.83601922 -0.06035437 0.54537070 0.17 s 0.21975727 -0.89609730 -0.38563767 0.17 s 0.73229980 -0.38759634 -0.55991614 0.17 s -0.38524410 0.88811922 -0.25066161 0.17 s -0.83729082 -0.54512942 0.04216629 0.17 s -0.25946692 -0.51739180 -0.81546468 0.17 s 0.52075309 0.85215467 -0.05146447 0.17 s -0.44853103 -0.84430450 0.29320613 0.17 Marsik s 0.43754211 -0.72591859 -0.53065914 0.17 Marsik s -0.33749714 0.81663746 0.46818686 0.17 s 0.24672720 0.41526073 0.87560505 0.17 s -0.56970519 -0.04733885 -0.82048464 0.17 s 0.33880645 0.91714281 -0.20990299 0.17 s 0.96553367 -0.08539315 -0.24587135 0.17 s 0.88855392 -0.40720236 0.21132480 0.17 s -0.52465111 0.47621152 -0.70566553 0.17 s -0.50321400 0.37184927 -0.78006655 0.17 s -0.06670985 0.96918708 -0.23712075 0.17 s 0.50016826 0.29550418 0.81394655 0.17 s -0.40213344 0.50231874 -0.76548320 0.17 s 0.34273711 -0.93467659 -0.09439790 0.17 s -0.36031541 0.91882658 0.16102967 0.17 s -0.01440218 0.46693632 -0.88417363 0.17 s -0.74793547 0.55749387 -0.36026818 0.17 s 0.07592720 -0.77727610 -0.62456137 0.17 s 0.22855709 0.16433577 -0.95955998 0.17 s -0.33708319 0.11760464 0.93410069 0.17 s -0.16382687 0.72745055 0.66631556 0.17 s 0.60898530 -0.63856715 0.47049862 0.17 s -0.43846753 -0.78575277 -0.43627837 0.17 s -0.79692823 0.12901470 -0.59013611 0.17 s -0.16477108 -0.16175532 -0.97297776 0.17 s -0.07073296 0.64847267 0.75794458 0.17 s -0.43433005 0.72094536 -0.53999555 0.17 s -0.16386078 -0.93646842 0.31012341 0.17 s -0.89291054 -0.42406482 -0.15126082 0.17 s -0.35204539 -0.04653003 0.93482566 0.17 s -0.30230522 0.91163969 0.27843237 0.17 s 0.93505436 0.08914340 -0.34311330 0.17 s 0.25797424 -0.43912116 -0.86059391 0.17 s 0.71908939 -0.46817285 -0.51354122 0.16 s -0.38681760 0.72546053 -0.56927955 0.16 s -0.63339144 0.25285771 -0.73135370 0.16 s -0.49279210 -0.79893798 -0.34475213 0.16 s 0.19425279 -0.98029906 0.03577162 0.16 s -0.02616014 0.79557204 -0.60529399 0.16 s -0.01037754 -0.22527897 0.97423905 0.16 s -0.77202582 -0.08744934 0.62954640 0.16 s 0.22386324 0.86821896 -0.44281039 0.16 s -0.80635703 0.57933736 0.11898164 0.16 s -0.77473152 -0.43194821 0.46174860 0.16 s 0.25386330 -0.22591932 -0.94048595 0.16 s -0.02028307 0.41287136 -0.91056347 0.16 s 0.43245807 -0.83996928 0.32776758 0.16 s 0.33079135 -0.84770668 -0.41469324 0.16 s 0.16270012 0.82579267 0.53999555 0.16 s -0.36734426 -0.84065157 -0.39794865 0.16 s 0.37738651 -0.86209434 0.33819047 0.16 s -0.93786019 -0.14476933 0.31537300 0.16 s 0.04679161 -0.91446626 -0.40194780 0.16 s 0.37731570 -0.01991192 0.92587060 0.16 s 0.47436985 -0.83887225 -0.26695806 0.16 s -0.21836285 0.61210710 0.76002800 0.16 s 0.37737671 0.89810944 0.22580127 0.16 s -0.26413020 0.75812346 -0.59622484 0.16 s 0.86829877 0.00877738 -0.49596393 0.16 s -0.57591957 -0.54098207 -0.61290705 0.16 s 0.02615859 -0.43129316 0.90183252 0.16 s -0.80131453 0.23078260 0.55193698 0.16 s -0.84321249 -0.43832520 -0.31122935 0.16 s 0.93376052 -0.35020304 -0.07381839 0.16 s -0.20359614 -0.23649350 0.95006287 0.16 s 0.38491449 -0.92167395 -0.04855923 0.16 s 0.15423897 0.62972766 -0.76134974 0.16 s 0.72115761 0.50005180 0.47945786 0.16 s 0.18084733 -0.65824509 0.73075825 0.16 s -0.21240333 -0.81958181 -0.53213763 0.16 s -0.07007767 0.97465330 0.21246192 0.16 s -0.01277948 0.89652419 -0.44281039 0.16 s 0.00401573 0.98608470 -0.16619509 0.16 s 0.78568518 0.48414472 0.38510081 0.16 s 0.53198296 0.26557511 -0.80402982 0.16 s -0.03015074 -0.63153541 0.77476060 0.16 s 0.61779445 -0.44495326 0.64834142 0.16 s 0.14398615 0.81693333 0.55846924 0.16 s -0.33521050 0.81580633 0.47126848 0.16 s 0.15210295 -0.58323652 -0.79793471 0.16 s 0.69311810 0.03122177 0.72014755 0.16 s 0.25007528 -0.14547427 0.95723540 0.16 s 0.30267802 -0.36854115 -0.87895590 0.16 s 0.41304904 0.47599688 0.77641320 0.16 s -0.32275188 0.84649634 0.42340899 0.16 s 0.28800875 0.91600162 -0.27927044 0.16 s 0.27943048 -0.53327250 0.79846042 0.16 s -0.23311166 -0.00486602 -0.97243780 0.16 s -0.17636877 -0.96610183 0.18852413 0.16 s -0.13325506 0.70048445 0.70111668 0.16 s -0.45814952 -0.60213369 0.65386087 0.16 s 0.97343242 -0.18547164 -0.13427445 0.16 s 0.20571722 -0.54405600 -0.81343931 0.16 s 0.68847221 0.21054181 0.69403034 0.16 s -0.86829501 0.30145237 0.39394191 0.16 s -0.43040574 0.86688840 -0.25150633 0.16 s 0.22775489 -0.93576658 -0.26920000 0.16 s 0.41420671 0.48978612 0.76716512 0.16 s 0.24760483 0.44876680 0.85866189 0.16 s -0.91322881 -0.29694626 -0.27899113 0.16 s 0.26595786 0.75156277 -0.60367191 0.16 s -0.24274412 -0.09454035 -0.96547264 0.16 s -0.26661336 -0.86888808 0.41707408 0.16 s -0.36963487 0.59917176 -0.71018535 0.16 s 0.45284790 -0.23194195 0.86089009 0.16 s -0.84073025 0.52279967 -0.14090124 0.16 s 0.03039026 0.18432136 0.98239607 0.16 s -0.59053475 0.70920104 -0.38510081 0.16 s 0.62994766 -0.75664574 0.17508033 0.16 s 0.20564054 0.56435430 0.79950994 0.16 s -0.81894219 -0.54642493 0.17536673 0.16 s 0.32391906 -0.55339664 0.76735169 0.16 s 0.48562524 -0.52958006 0.69549489 0.16 s 0.10466919 -0.55616307 0.82445556 0.16 s -0.57993406 -0.23848909 -0.77897328 0.16 s -0.05141716 0.99214125 -0.11407023 0.16 s -0.12123197 0.98913980 -0.08309810 0.16 s -0.13956992 -0.09990688 -0.98515928 0.16 s -0.20874575 0.80114859 -0.56087983 0.16 s 0.58214474 -0.70296288 0.40859598 0.16 s 0.49307725 0.76792389 0.40886146 0.16 Pleione s -0.01378243 0.36081892 -0.93253404 0.16 s 0.99639559 -0.05919723 0.06075819 0.16 s 0.41550991 -0.86610496 -0.27787358 0.16 s -0.46081218 0.03319986 -0.88687646 0.16 s -0.73476475 0.19871338 0.64856285 0.16 s -0.30616567 0.63510132 -0.70916069 0.16 s 0.98072690 -0.17138484 0.09381871 0.16 s -0.40067616 0.86449945 0.30347878 0.16 s 0.06140629 -0.65163404 0.75604385 0.16 s 0.94434553 -0.03098365 0.32749277 0.16 s 0.34524393 0.44993067 0.82363158 0.16 s 0.14803295 -0.75540298 0.63832009 0.16 s -0.45190197 -0.30180869 -0.83946180 0.16 s 0.53343135 0.82350844 0.19309282 0.16 s -0.64481777 -0.76371437 0.03082926 0.16 s 0.66649467 0.74521559 -0.02094242 0.16 s 0.15077847 0.89541537 -0.41892388 0.16 s 0.72870725 -0.46498343 0.50276852 0.16 s 0.23165703 -0.90662402 -0.35265836 0.16 s 0.76497048 -0.47307050 0.43706343 0.16 s 0.26845479 0.65483177 -0.70648944 0.16 s -0.79442042 0.55462497 -0.24756272 0.16 s -0.92432320 0.38145050 -0.01105353 0.16 s 0.17233962 0.87471837 -0.45295346 0.16 s -0.74908549 0.19780023 0.63225472 0.16 s -0.23428003 0.33992541 -0.91080379 0.16 s -0.04544374 -0.36966518 0.92805308 0.16 s 0.15433279 0.98789865 -0.01541646 0.16 s -0.20380603 0.96643227 -0.15643446 0.16 s 0.25439864 0.05475124 -0.96554834 0.16 s 0.98119104 -0.07133667 0.17937458 0.16 s 0.02436526 -0.92532986 0.37837937 0.16 s -0.58860439 0.37516287 -0.71609896 0.15 s -0.46194518 -0.65596259 0.59692526 0.15 s -0.72841114 0.10048162 -0.67773199 0.15 s -0.15207404 -0.69601458 -0.70173866 0.15 s -0.59550828 0.32266200 -0.73570317 0.15 s 0.50439709 0.23462394 -0.83098447 0.15 s -0.78709233 0.59329611 0.16877609 0.15 s -0.85162187 0.33546278 -0.40274668 0.15 s 0.33238351 0.90298653 0.27228025 0.15 s 0.48180160 -0.77934229 0.40061557 0.15 s 0.82735240 -0.51048446 -0.23429383 0.15 s 0.26296449 -0.10124983 0.95947808 0.15 s 0.93489206 0.20284259 0.29125878 0.15 s -0.92484528 0.36058214 0.12100314 0.15 s -0.47316825 0.18080375 -0.86221910 0.15 s 0.11598864 0.81625587 0.56592667 0.15 s 0.03936996 0.14783332 0.98822838 0.15 s -0.16537774 -0.73909891 0.65298009 0.15 s -0.02208448 0.04712748 0.99864471 0.15 s 0.63381797 0.38045993 0.67344266 0.15 s 0.71141148 -0.18199791 0.67880076 0.15 s -0.35343891 0.69804943 -0.62274224 0.15 s -0.35171160 0.62610251 -0.69591278 0.15 s -0.21543092 -0.56292957 0.79793471 0.15 s 0.70478398 -0.24233232 0.66674930 0.15 s 0.96433622 -0.15669255 0.21331459 0.15 s 0.10672535 0.98979729 -0.09439790 0.15 s -0.80434096 -0.58546108 0.10134569 0.15 s -0.44462878 0.67197329 -0.59224755 0.15 s -0.36064413 0.48033285 -0.79950994 0.15 s -0.93467414 0.15068683 -0.32199031 0.15 s 0.52683890 -0.14096096 0.83819497 0.15 s -0.01175990 0.26276821 -0.96478730 0.15 s 0.67258501 -0.32640859 -0.66414368 0.15 s -0.18863004 -0.31233603 -0.93105578 0.15 s 0.82108092 -0.54862875 -0.15758358 0.15 s -0.31704253 -0.36778373 -0.87419629 0.15 s -0.46615618 0.50620151 -0.72557455 0.15 s 0.48259425 -0.53370708 -0.69444907 0.15 s 0.51341516 -0.19034269 0.83676434 0.15 s -0.96401709 -0.06748133 0.25713280 0.15 s 0.45162922 0.70574063 0.54585826 0.15 s -0.14619303 0.98902190 -0.02152407 0.15 s 0.28270045 -0.93980598 0.19195104 0.15 s 0.57816845 0.09191772 0.81072336 0.15 s -0.58337480 0.37674052 0.71954185 0.15 s -0.23149998 0.58495075 -0.77732897 0.15 s 0.81739342 -0.57474053 0.03925982 0.15 s -0.71517992 -0.28219751 -0.63943899 0.15 s 0.82994008 0.46645516 0.30597228 0.15 s 0.48806441 -0.80312032 0.34174678 0.15 s -0.55534136 0.16564244 0.81495923 0.15 s 0.59251988 0.72359568 0.35401902 0.15 s -0.85043699 0.10103228 -0.51628423 0.15 s 0.15062897 -0.07022616 -0.98609293 0.15 s -0.52674681 0.39072141 -0.75490040 0.15 s -0.41801155 0.06739122 -0.90593863 0.15 s 0.22943363 0.96994233 -0.08106875 0.15 s 0.02641997 -0.86063260 0.50854057 0.15 s 0.07473200 0.14360982 0.98680866 0.15 s 0.33593950 -0.94169378 0.01890661 0.15 s -0.32794499 0.87771225 0.34938985 0.15 s 0.59681720 -0.41718477 0.68539482 0.15 s 0.60716718 0.59294081 0.52893215 0.15 s -0.53192049 -0.84508425 -0.05378835 0.15 s 0.27921873 0.90433758 0.32281640 0.15 s -0.26955020 0.75455308 -0.59832460 0.15 s -0.46727878 0.37069273 -0.80264401 0.15 s 0.01727275 0.39168891 -0.91993558 0.15 s -0.12639612 0.09362784 -0.98755145 0.15 s 0.43046552 0.70005399 -0.56975776 0.15 s 0.99856752 0.00791551 -0.05291693 0.15 s 0.35058278 0.36177334 -0.86383551 0.15 s -0.80496764 -0.28064772 -0.52274656 0.15 s 0.60551894 -0.00281819 -0.79582590 0.15 s -0.45603809 0.79722834 -0.39554548 0.15 s 0.41765857 -0.39900675 -0.81630564 0.15 s 0.61096931 -0.72790986 -0.31122935 0.15 s 0.36193520 0.92118275 -0.14291683 0.15 s 0.10154863 0.43609178 -0.89415425 0.15 s 0.56828129 -0.41275430 0.71182179 0.15 s 0.25498965 0.37153298 0.89271694 0.15 s 0.85942304 0.35422859 -0.36866540 0.15 s 0.40172178 0.90087068 0.16447377 0.15 s 0.34066239 -0.81487894 0.46895781 0.15 Albireo s 0.93869764 0.31590667 -0.13802078 0.15 s -0.50469112 0.06245268 -0.86103803 0.15 s 0.40791148 -0.22344092 0.88525838 0.15 s -0.74534911 -0.11727393 -0.65627855 0.15 s -0.50548059 0.83246022 0.22693461 0.15 s 0.64736825 0.35283452 -0.67559022 0.15 s 0.08143780 -0.76731503 0.63607824 0.15 s 0.03640246 -0.93868822 0.34284005 0.15 s -0.11154346 -0.70859045 -0.69674790 0.15 s 0.79680496 -0.20051321 -0.56999677 0.15 s 0.29843661 -0.63397044 0.71345431 0.15 s 0.31611747 -0.37656751 -0.87078506 0.15 s 0.13880281 -0.00477641 -0.99030852 0.15 s 0.39644027 -0.89955938 -0.18337947 0.15 s -0.54123181 0.46889850 -0.69799876 0.15 s -0.38763058 0.13736247 0.91152292 0.15 s -0.04398226 -0.90063351 0.43234807 0.15 s -0.89190334 0.04381640 -0.45009845 0.15 s -0.80179626 -0.57924914 0.14694627 0.15 s -0.28070769 0.75028789 0.59855765 0.15 s -0.21414740 -0.01141035 0.97673470 0.15 s -0.12239677 -0.36937311 -0.92118537 0.15 s 0.08019531 -0.87206590 0.48277298 0.15 s -0.37554398 0.56954247 -0.73115528 0.15 s 0.25466657 -0.47255549 0.84370387 0.15 s -0.08364433 0.35042375 0.93284875 0.15 s -0.64925671 0.38365093 0.65671736 0.15 s 0.22123408 0.97212934 -0.07758909 0.15 s -0.04274754 -0.61647081 -0.78621650 0.15 s 0.16822396 -0.52031416 0.83724183 0.15 s -0.47151604 -0.82707530 0.30597228 0.15 s 0.12569174 -0.48081669 -0.86776549 0.15 s -0.26910865 0.94419205 0.18995228 0.15 s -0.93870091 -0.19375508 0.28513080 0.15 s -0.72021723 -0.36282238 -0.59130967 0.14 s 0.14892398 -0.77033281 -0.62000728 0.14 s 0.31581187 -0.94798499 0.03984114 0.14 s 0.45800373 -0.87036890 0.18080525 0.14 s -0.58937627 0.79710221 0.13139135 0.14 s 0.98881406 0.06249969 -0.13542737 0.14 s 0.10716314 0.98980510 -0.09381871 0.14 s 0.29580128 -0.74949610 0.59224755 0.14 s 0.66345173 0.50009799 -0.55653733 0.14 s 0.59549761 0.77887845 0.19680183 0.14 s -0.73796844 -0.01180772 -0.67473191 0.14 s -0.14842023 0.67086565 -0.72657466 0.14 s -0.41072562 0.90895134 -0.07149744 0.14 s -0.51023084 0.72834700 0.45735663 0.14 s 0.07556891 0.51072371 -0.85641730 0.14 s 0.14948641 -0.97029036 -0.19023786 0.14 s -0.81967646 -0.57145977 -0.03955048 0.14 s 0.84535825 -0.38710943 -0.36812454 0.14 s -0.07385466 0.95438200 -0.28931028 0.14 s -0.39872786 -0.77445513 -0.49115714 0.14 s -0.74396861 -0.48668489 -0.45787391 0.14 s 0.70429319 0.11396549 0.70070177 0.14 s 0.61274081 0.35985237 -0.70360142 0.14 s -0.45874187 -0.62707829 0.62954640 0.14 s -0.71631390 0.16779010 -0.67730415 0.14 s 0.44885936 0.06451503 -0.89127052 0.14 s 0.14828564 -0.75610983 0.63742399 0.14 s -0.38063267 -0.03687421 -0.92399085 0.14 s 0.63851017 -0.71769845 0.27787358 0.14 s 0.34279588 -0.87621206 0.33873791 0.14 s -0.37737098 0.74450970 0.55072361 0.14 s 0.96466798 -0.21592300 0.15097328 0.14 s 0.08517011 0.52976066 0.84385997 0.14 s -0.60988873 -0.21667199 0.76229191 0.14 s -0.15449269 -0.89675051 0.41469324 0.14 s -0.01417178 0.94136387 0.33709526 0.14 s 0.25612664 -0.30001810 -0.91890603 0.14 s -0.46809283 0.88314134 0.03082926 0.14 s -0.47014302 0.04502815 -0.88144088 0.14 s 0.16208820 -0.15557289 -0.97443545 0.14 s -0.25437757 -0.28912750 0.92287451 0.14 s -0.68161726 0.62806135 0.37541556 0.14 s -0.19968495 0.62585282 -0.75394571 0.14 s -0.47806463 0.04810347 -0.87700641 0.14 s -0.87704825 -0.47967267 -0.02646773 0.14 s -0.33028823 0.67944700 -0.65518045 0.14 s 0.62128580 -0.33721370 0.70731246 0.14 s -0.31443247 -0.93747389 0.14924772 0.14 s -0.25338361 0.37826183 -0.89034528 0.14 s 0.76864433 -0.62856811 0.11869281 0.14 s 0.41759083 -0.90374857 0.09410831 0.14 s -0.36235255 0.36425492 -0.85791546 0.14 s -0.02238593 -0.76553017 0.64301044 0.14 s -0.35814691 0.17950952 -0.91624624 0.14 s -0.73072714 -0.00674888 0.68263632 0.14 s -0.38211140 0.88300729 0.27256012 0.14 s -0.17529207 0.93666506 0.30320159 0.14 s 0.96656686 -0.20662613 0.15183589 0.14 s -0.61316741 -0.78930491 0.03199225 0.14 s -0.42245820 0.48741269 -0.76417142 0.14 s 0.41422662 0.48771980 0.76846969 0.14 s -0.08416583 0.37221089 0.92432415 0.14 s -0.78801560 -0.44818592 -0.42209092 0.14 s -0.45870003 0.10470535 -0.88240075 0.14 s -0.50659931 0.19662403 0.83946180 0.14 s 0.06903592 -0.22181919 0.97264087 0.14 s -0.70677716 -0.65152907 -0.27563736 0.14 s 0.78502470 0.07253665 0.61520290 0.14 s 0.17440438 -0.58564967 -0.79157919 0.14 s 0.35445094 -0.91186154 0.20705801 0.14 s -0.49267292 0.52855814 0.69130290 0.14 s -0.34438080 0.60951811 -0.71406549 0.14 s -0.52304274 -0.71084374 -0.47024187 0.14 s 0.63608229 0.49740911 0.58990127 0.14 s -0.28777620 0.26745725 0.91959310 0.14 s -0.16515258 0.84049535 -0.51603508 0.14 s -0.65479702 0.26472130 -0.70792907 0.14 s -0.41461384 0.03721604 -0.90923613 0.14 s 0.64075679 -0.76769757 -0.00843566 0.14 s 0.71590853 0.69517839 -0.06482258 0.14 s 0.10824348 -0.76174736 -0.63876784 0.14 s 0.94105452 0.33232093 0.06308083 0.14 s 0.81249684 0.26053837 0.52150613 0.14 s 0.07945547 0.89616936 0.43654010 0.14 s -0.60726762 -0.15446152 -0.77933800 0.14 s -0.13505751 0.87241888 0.46972838 0.14 s 0.94275677 -0.28643131 0.17078274 0.14 s 0.54944444 0.16872506 0.81831694 0.14 s 0.22793384 0.18794987 0.95536435 0.14 s 0.02442006 0.61356992 -0.78926271 0.14 s 0.67367715 -0.69995207 0.23712075 0.14 s -0.25196028 0.17163409 0.95239580 0.14 s 0.25090206 -0.17072636 0.95283824 0.14 s 0.98301232 0.01930388 -0.18252154 0.14 s -0.58881932 -0.75535125 -0.28763914 0.14 s -0.24477141 0.42552730 -0.87121379 0.14 s 0.12973437 -0.93996525 -0.31564903 0.14 s -0.47779059 0.48246926 -0.73412502 0.14 s 0.20484214 0.12495440 0.97078633 0.14 s 0.94531739 -0.03569593 -0.32419261 0.14 s -0.15181985 0.52685499 -0.83628613 0.14 s -0.95539171 0.01660694 -0.29487428 0.14 s 0.40712503 0.91102779 -0.06540313 0.14 s -0.50345230 0.06226221 -0.86177677 0.14 s 0.21161649 0.91297638 0.34884468 0.14 s -0.89297754 -0.09510355 0.43993917 0.14 s 0.32460347 -0.27390674 0.90532190 0.14 s 0.63867557 -0.03552133 -0.76865578 0.14 s -0.58569723 -0.79466248 -0.15959403 0.14 s 0.46598056 -0.67390317 0.57333815 0.14 s -0.43399256 0.06540923 -0.89853889 0.14 s -0.35878837 0.31650010 0.87812221 0.14 s 0.51115358 -0.76139426 0.39874908 0.14 s -0.24535114 0.87850207 0.40992305 0.14 s 0.87090838 0.08200559 -0.48455518 0.14 s 0.13992450 -0.59813666 -0.78908408 0.14 s 0.29098514 -0.64873290 0.70318794 0.14 s -0.27223888 0.70797515 0.65165722 0.14 s -0.93971997 -0.28677809 -0.18623824 0.14 s -0.25248471 -0.00863311 -0.96756238 0.14 s -0.09704016 0.36321509 -0.92663801 0.14 s -0.98208505 0.18512318 0.03519021 0.14 s -0.60078019 -0.75382024 0.26611695 0.14 s 0.05159251 0.84353006 -0.53459817 0.14 s 0.45668665 0.32685509 0.82740742 0.14 s -0.52663618 -0.12793377 -0.84040898 0.14 s -0.45485091 0.85755533 -0.24022804 0.14 s 0.00601798 -0.92975700 0.36812454 0.14 s -0.13333216 0.96759146 -0.21445121 0.14 s 0.02887921 0.23421654 -0.97175545 0.14 s 0.29897171 0.14409965 0.94331926 0.14 s 0.90704733 0.12095883 -0.40327913 0.14 s 0.31715938 -0.83878475 0.44254956 0.14 s -0.65397400 0.22667190 0.72176021 0.14 s 0.79839122 -0.55103070 -0.24276856 0.14 s 0.51933831 0.37876591 0.76604444 0.14 s 0.61396229 -0.58051032 -0.53484398 0.14 s -0.43988755 0.84787458 -0.29598594 0.14 s 0.20105453 0.93983644 0.27619654 0.14 s -0.17962578 0.97075015 -0.15930687 0.14 s -0.35592538 0.70883399 0.60899216 0.14 s -0.21476994 0.25804180 -0.94195980 0.13 s 0.95297831 -0.15669660 -0.25938097 0.13 s -0.46504408 0.65589482 -0.59458894 0.13 s -0.49128267 0.58384776 -0.64634597 0.13 s -0.06116697 0.94268066 0.32804239 0.13 s 0.42081940 0.77991527 0.46329606 0.13 s 0.15924455 -0.20474288 0.96577507 0.13 s 0.70926005 0.08781926 0.69945550 0.13 s 0.25836661 0.53396147 0.80506635 0.13 s -0.25291184 -0.38447297 0.88781536 0.13 s 0.27516562 0.94073892 0.19822760 0.13 s 0.48495126 -0.73106271 0.47996831 0.13 s 0.95937037 0.21319973 -0.18480904 0.13 s 0.74351019 0.53303742 -0.40381145 0.13 s -0.11854678 0.99293464 -0.00523596 0.13 s -0.35902935 -0.34545133 -0.86704171 0.13 s 0.86070520 0.11382345 0.49621651 0.13 s 0.00509023 0.99993813 -0.00989004 0.13 s 0.71660507 0.21840455 -0.66240215 0.13 s -0.38629067 0.46056727 -0.79916036 0.13 s -0.42627689 0.08911860 -0.90019214 0.13 s 0.98624498 0.15289912 -0.06279052 0.13 s -0.16602515 -0.89615381 -0.41151434 0.13 s 0.36198872 -0.69119596 0.62546968 0.13 s -0.20391709 0.71055806 -0.67344266 0.13 s -0.97149432 -0.19596101 0.13340963 0.13 s 0.01105530 0.50164056 0.86500549 0.13 s -0.67375857 0.69012481 0.26415363 0.13 s 0.73430067 0.64377552 0.21530350 0.13 s -0.38457423 0.60599214 -0.69633049 0.13 s 0.39889148 -0.69148028 0.60227954 0.13 s -0.12931421 0.75618792 0.64144963 0.13 s -0.77791482 -0.22950613 0.58495766 0.13 s -0.84192574 0.49477822 0.21530350 0.13 s 0.87137192 -0.34024474 -0.35347486 0.13 s 0.44321352 0.37410271 -0.81462198 0.13 s -0.30303067 -0.31604341 -0.89904892 0.13 s -0.56773055 0.62029344 -0.54121912 0.13 s -0.49132115 -0.56553239 -0.66240215 0.13 s -0.18025237 -0.43959165 -0.87992513 0.13 s -0.52061033 -0.54534304 -0.65693671 0.13 s -0.90442127 -0.38841426 -0.17651214 0.13 s 0.42247456 -0.45503479 -0.78387409 0.13 s 0.22938950 -0.66274875 -0.71284258 0.13 s -0.16441131 0.47804958 0.86280793 0.13 s 0.57119364 -0.14065112 -0.80867493 0.13 s -0.65892768 -0.69821924 -0.27982903 0.13 s -0.26562271 0.95888728 -0.09989863 0.13 s -0.34339333 -0.75671411 0.55629563 0.13 s -0.45343792 0.29860890 0.83977783 0.13 s 0.26990762 -0.24833749 0.93031090 0.13 s 0.27667129 -0.21470495 -0.93667221 0.13 s 0.35151562 0.93519223 -0.04303816 0.13 s 0.24458846 -0.80714661 0.53729963 0.13 s -0.67637116 -0.59840262 -0.42946059 0.13 s -0.93162912 -0.32435158 0.16389990 0.13 s 0.11847549 -0.99295086 -0.00349065 0.13 s 0.95712709 -0.17264563 -0.23259673 0.13 s -0.45534566 -0.40647101 -0.79211217 0.13 s -0.06114270 0.52015686 0.85187936 0.13 s -0.84071398 0.06714997 -0.53729963 0.13 s -0.39376539 -0.27533352 -0.87700641 0.13 s 0.41716170 -0.15462321 0.89558238 0.13 s 0.43708777 0.88244039 0.17393464 0.13 s 0.61421466 0.13809074 -0.77696288 0.13 s 0.76850414 -0.09680080 0.63248003 0.13 s -0.61275458 0.63646847 0.46844387 0.13 s -0.07011418 0.54231924 -0.83724183 0.13 s -0.88880092 -0.30596644 -0.34119999 0.13 s -0.13596512 0.64450389 0.75241488 0.13 s -0.10312644 0.97436631 -0.19993800 0.13 s 0.71026742 0.70225507 -0.04855923 0.13 s -0.43122861 0.56478924 -0.70360142 0.13 s -0.43665609 0.43010059 -0.79015499 0.13 s -0.69950527 0.40848482 -0.58637238 0.13 s 0.42357069 -0.88241303 0.20478079 0.13 s -0.90951341 -0.28669578 0.30098322 0.13 s -0.79918230 0.12128111 -0.58872616 0.13 s -0.92195153 0.38432211 -0.04797813 0.13 s 0.55972898 0.77240723 -0.30015090 0.13 s -0.01834423 0.99300122 -0.11667074 0.13 s 0.12002154 0.50137103 0.85686755 0.13 s 0.71923244 -0.25651953 0.64567983 0.13 s 0.12362710 0.73515362 0.66653246 0.13 s 0.29488084 -0.94967145 0.10568557 0.13 s -0.09371943 -0.62709135 -0.77328718 0.13 s -0.43728861 -0.87562937 -0.20506549 0.13 s -0.20713522 0.90530765 0.37082759 0.13 s -0.36733630 0.49862233 -0.78513682 0.13 s -0.37198785 0.92031693 0.12100314 0.13 s 0.46029225 -0.78129083 0.42156342 0.13 s 0.42858052 -0.62994730 0.64767671 0.13 s 0.56794459 -0.53473610 0.62569660 0.13 s -0.30868447 -0.94675308 0.09150162 0.13 s 0.49918163 0.76623023 -0.40460962 0.13 s -0.13557866 0.97032428 0.20022301 0.13 s -0.31054384 0.61266744 -0.72677451 0.13 s -0.71798486 0.67099744 0.18509492 0.13 s 0.90956503 0.17989253 -0.37460658 0.13 s 0.78013527 0.51050621 0.36162457 0.13 s -0.38550007 0.67119557 -0.63315576 0.13 s 0.29957521 0.35137796 -0.88701081 0.13 s 0.15742670 -0.74489611 -0.64834142 0.13 s 0.18599802 0.40758544 -0.89402395 0.13 s -0.41862455 -0.54269654 -0.72817165 0.13 s 0.54476684 -0.42009541 0.72577471 0.13 s -0.75206733 0.64973992 -0.11060166 0.13 s 0.37581992 -0.09448674 0.92186314 0.13 s 0.26913154 0.33433366 0.90321052 0.13 s -0.90653199 -0.36037117 -0.21984620 0.13 s 0.18202271 -0.82303441 0.53803539 0.13 s 0.94039494 0.31343549 0.13196805 0.13 s -0.10788880 -0.66735429 -0.73688418 0.13 s -0.54654366 0.48177236 -0.68497109 0.13 s -0.41204578 0.13686973 -0.90082461 0.13 s 0.80560827 -0.51257056 0.29709712 0.13 s -0.89964634 0.26862371 -0.34420598 0.13 s -0.14668721 0.70936471 0.68940884 0.13 s 0.75714290 -0.52028918 -0.39501110 0.13 s -0.08270165 -0.17826730 -0.98050046 0.13 s 0.06076293 -0.03056059 0.99768430 0.13 s -0.26042533 0.72967982 -0.63225472 0.13 s -0.40362784 -0.09966978 0.90947813 0.13 s -0.05540575 -0.57805371 -0.81411552 0.13 s -0.39091381 0.91981941 0.03344591 0.13 s 0.15386409 0.95837390 -0.24051040 0.13 s 0.07602989 -0.71388662 -0.69612163 0.13 s -0.45576081 0.53386337 -0.71223027 0.13 s 0.55720693 0.83012402 -0.02036077 0.13 s -0.89297158 0.42768046 -0.14032523 0.13 s -0.67016059 0.07063377 -0.73884755 0.13 s 0.81674349 0.04185084 -0.57548118 0.13 s 0.48703286 -0.24864662 0.83724183 0.13 s -0.11137044 0.78334624 -0.61152703 0.13 s -0.39871994 -0.42120478 0.81462198 0.13 s -0.35634673 -0.86635017 0.34993491 0.13 s -0.44305205 -0.62008613 0.64745510 0.13 s 0.70519340 -0.61508894 -0.35265836 0.13 s 0.05440074 -0.26878902 0.96166158 0.13 s 0.84582371 0.40570468 0.34638995 0.13 s -0.13872989 0.83348423 -0.53484398 0.13 s -0.27988419 -0.95403755 -0.10713176 0.13 s -0.29456681 -0.19141573 0.93626410 0.13 s -0.38842645 -0.91193920 -0.13225639 0.13 s 0.66090304 0.65640050 0.36379322 0.12 s 0.48357025 0.76137269 0.43182340 0.12 s 0.56944275 -0.76038265 -0.31233492 0.12 s -0.92203552 -0.08296557 -0.37811011 0.12 s -0.16179666 0.77195299 -0.61474419 0.12 s -0.34765592 0.86336946 0.36568916 0.12 s -0.05136766 -0.46871871 0.88185269 0.12 s -0.78895050 -0.52915406 -0.31233492 0.12 s 0.33832982 0.30736208 -0.88941640 0.12 s -0.93667310 0.29870537 0.18280753 0.12 s -0.21003513 -0.80633694 0.55290687 0.12 s -0.62218875 0.44237071 0.64590192 0.12 s -0.32997212 0.41021925 -0.85019910 0.12 s -0.52044511 0.17174293 -0.83644563 0.12 s -0.47820115 0.40806174 -0.77769482 0.12 s -0.69199562 -0.22278616 -0.68666464 0.12 s -0.35100248 0.03684025 0.93564951 0.12 s -0.14819650 -0.32449934 0.93420446 0.12 s 0.78873444 0.61346048 0.03955048 0.12 s -0.56356961 0.03216638 0.82544208 0.12 s 0.09461639 -0.94723767 0.30624920 0.12 s 0.36127043 0.91929418 -0.15614715 0.12 s -0.55071205 -0.34507048 0.76002800 0.12 s -0.61168605 -0.38197657 0.69277275 0.12 s 0.16935675 0.52122647 0.83644563 0.12 s -0.57007861 0.69238073 -0.44228870 0.12 s 0.05200468 0.99230850 0.11233611 0.12 s -0.47790226 0.07017992 -0.87560505 0.12 s 0.10559542 0.99080843 -0.08454742 0.12 s 0.24778764 -0.93977469 0.23542483 0.12 s 0.68267161 0.72295743 -0.10626407 0.12 s -0.51769173 0.15699896 -0.84103900 0.12 s -0.57722312 -0.65521127 0.48735172 0.12 s 0.68764740 0.71384376 -0.13254473 0.12 s 0.23387201 -0.77340257 0.58919632 0.12 s 0.40576598 0.87614930 0.26022366 0.12 s 0.87846410 0.34714362 0.32831717 0.12 s 0.57634026 -0.51417726 -0.63518000 0.12 s -0.12002426 0.04905226 0.99155837 0.12 s 0.89528370 -0.29284033 -0.33572561 0.12 s -0.53579998 -0.84347183 0.03838781 0.12 s 0.62997037 0.26126438 0.73135370 0.12 s -0.40152627 0.16861427 -0.90019214 0.12 s -0.42398489 0.37412173 -0.82478464 0.12 s -0.57714450 -0.79790407 0.17393464 0.12 s -0.92810172 0.07800288 0.36406416 0.12 s 0.76240194 0.36425978 -0.53484398 0.12 s 0.96104401 -0.07366706 -0.26639736 0.12 s 0.94998562 0.05047940 -0.30818695 0.12 s 0.37158355 0.21374194 0.90346003 0.12 s 0.05200186 0.96932262 0.24022804 0.12 s 0.94554079 -0.05776250 -0.32033744 0.12 s 0.32490820 0.54395878 0.77365595 0.12 s -0.36229202 0.19121696 -0.91223931 0.12 s -0.00345435 -0.86368203 -0.50402522 0.12 s -0.75788528 -0.56311190 0.32941601 0.12 s -0.27939829 0.57242858 0.77088398 0.12 s 0.71903962 0.47097453 -0.51104307 0.12 s -0.55247313 0.33288962 0.76417142 0.12 s 0.16333190 0.47682714 -0.86368895 0.12 s -0.55960965 0.28089359 -0.77970237 0.12 s 0.00971903 -0.93456841 0.35565078 0.12 s 0.49401391 0.86903316 -0.02704930 0.12 s 0.59563541 0.71765870 0.36081082 0.12 s 0.94726121 -0.06540853 -0.31371626 0.12 s -0.30164275 0.84187669 -0.44749898 0.12 s 0.14894459 0.11603720 -0.98201370 0.12 s 0.13500974 0.00591433 -0.99082661 0.12 s 0.23121576 -0.86668950 0.44202778 0.12 s 0.00991777 -0.04068428 -0.99912286 0.12 s 0.07611801 -0.90725565 0.41363415 0.12 s 0.40097681 -0.21998340 0.88928336 0.12 s -0.41369769 0.36020339 0.83612663 0.12 s 0.21511197 -0.36713865 0.90495086 0.12 s 0.81426620 0.58045310 -0.00669038 0.12 s -0.19787100 0.16987078 -0.96539682 0.12 s -0.76643693 0.10408048 0.63383096 0.12 s -0.16598460 0.23252299 -0.95832258 0.12 s -0.11229525 -0.02450144 0.99337280 0.12 s 0.43029010 0.43355680 0.79175687 0.12 s -0.10037923 -0.68947929 -0.71731609 0.12 s 0.44389755 0.88596010 0.13427445 0.12 s 0.27883106 -0.12326995 -0.95239580 0.12 s 0.10719346 -0.06768849 -0.99193138 0.12 s 0.26501417 0.12149618 0.95655954 0.12 s 0.53986120 -0.77543432 -0.32749277 0.12 s -0.54026252 0.73637569 -0.40726805 0.12 s -0.66632855 0.74492079 -0.03315518 0.12 s 0.47608939 -0.85683000 0.19794248 0.12 s 0.18812527 0.11430701 0.97547054 0.12 s 0.32625011 -0.92364955 0.20107792 0.12 s 0.69356960 0.52343339 0.49495322 0.12 s -0.24531905 -0.81467670 0.52547169 0.12 s -0.94175786 -0.00349298 -0.33627352 0.12 s -0.22192785 0.89370263 -0.38992769 0.12 s -0.19660860 0.94834495 -0.24897163 0.12 s 0.69252145 0.46681860 0.54999495 0.12 s 0.01368097 0.60675931 -0.79476786 0.12 s 0.08510011 0.87314856 -0.47996831 0.12 s 0.17646641 0.38139835 0.90741110 0.12 s -0.66815859 -0.60020614 -0.43967792 0.12 s 0.60125577 -0.45266765 -0.65847057 0.12 s 0.33982974 0.78248847 0.52175432 0.12 s -0.19574901 -0.52355456 0.82920021 0.12 s 0.72773105 -0.63400197 -0.26162770 0.12 s 0.39536977 -0.21942028 0.89192909 0.12 s -0.89228094 -0.11318263 0.43706343 0.12 s 0.68342847 -0.63415545 -0.36162457 0.12 s -0.17310144 -0.87723869 -0.44775909 0.12 s 0.51669902 -0.40782019 0.75279796 0.12 s 0.87616354 -0.48175800 -0.01570732 0.12 s 0.34483609 0.10980261 0.93221855 0.12 s 0.98133904 -0.03162602 0.18966669 0.12 s 0.41294411 0.50639474 0.75699508 0.12 s 0.16972136 0.96212864 -0.21331459 0.12 s -0.69727027 0.04346127 -0.71548957 0.12 s -0.12436771 0.77321297 0.62183148 0.12 s -0.86507446 0.44992965 -0.22183214 0.12 s 0.52463150 0.34593076 0.77787769 0.12 s 0.76802778 -0.50802535 0.38992769 0.12 s -0.49338260 0.86895198 0.03867848 0.12 s -0.39514118 0.80911386 0.43496919 0.12 s 0.68043578 0.57441938 0.45502692 0.12 s 0.30618510 -0.86784858 0.39126658 0.12 s 0.61865854 -0.74209839 -0.25797603 0.12 s 0.81137198 0.40298921 -0.42340899 0.12 s -0.40132535 -0.15653734 -0.90245998 0.12 s -0.17096432 -0.40252256 -0.89930350 0.12 s 0.48768535 -0.21475600 -0.84619313 0.12 s 0.04059909 0.68588698 -0.72657466 0.12 s 0.20164247 -0.91585290 -0.34720847 0.12 s -0.69689542 -0.04277671 -0.71589589 0.12 s -0.41486827 -0.28132710 -0.86529726 0.12 s 0.15647526 0.81097662 0.56376630 0.12 s -0.23581967 0.72291517 -0.64944804 0.12 s -0.67228776 0.73786360 -0.05988712 0.12 s -0.98827618 0.05215388 0.14349262 0.12 s -0.43936566 0.87866938 0.18680981 0.12 s 0.23999211 0.68642980 0.68645316 0.12 s -0.19276839 0.94748688 -0.25516450 0.12 s -0.35481757 0.91280478 0.20221758 0.12 s 0.47021189 0.38554966 -0.79388428 0.12 s 0.71349931 0.59244621 0.37406713 0.12 s 0.62700742 -0.49266815 0.60343993 0.12 s -0.06457009 0.95844507 0.27787358 0.12 s 0.63389051 -0.05787457 0.77125442 0.12 s -0.49196005 0.78908724 0.36785409 0.12 s -0.90071142 0.02076765 -0.43392119 0.12 s 0.75960398 0.13775814 0.63562918 0.12 s 0.21035087 0.60052776 -0.77143955 0.12 s 0.44367886 -0.55819750 -0.70111668 0.12 s 0.07923593 0.31038323 -0.94730347 0.12 s 0.84425318 -0.07151236 -0.53115213 0.12 s 0.19854689 -0.33745852 -0.92016351 0.12 s -0.96804547 -0.08866699 -0.23457661 0.12 s -0.65831667 -0.62663257 -0.41707408 0.12 s -0.39358923 0.03016986 0.91879123 0.12 s 0.95156217 0.23739809 -0.19537561 0.12 s 0.82251406 0.30391726 0.48073372 0.12 s -0.25710237 -0.53144729 -0.80713207 0.12 s 0.12531266 -0.71831906 -0.68433505 0.12 s 0.63986415 0.52302372 0.56304532 0.12 s -0.46454167 0.49023810 -0.73747385 0.12 s -0.43523529 0.30273116 -0.84789389 0.12 s 0.69240284 0.70901567 -0.13369791 0.12 s -0.12877317 -0.99149930 -0.01861577 0.12 s 0.40844709 -0.86865056 -0.28038749 0.12 s 0.43769461 -0.67916942 -0.58919632 0.12 s 0.35975710 -0.67779309 -0.64122647 0.12 s -0.54964846 -0.45646217 0.69966334 0.12 s -0.07469697 0.93691850 -0.34147340 0.12 s 0.48356748 0.87013900 0.09497707 0.12 s 0.35335296 0.93532729 0.01745241 0.12 s 0.06363620 0.82000959 -0.56880116 0.12 s -0.81080991 -0.08378897 -0.57928121 0.12 s 0.41662914 0.55506605 0.71994573 0.12 s 0.58230770 -0.80763733 0.09294987 0.12 s -0.44805068 -0.65579295 -0.60760689 0.12 s 0.08440643 -0.95834959 -0.27283999 0.12 s -0.65383089 -0.05662785 0.75451869 0.12 s -0.58528584 0.50453705 -0.63473052 0.12 s -0.03172927 0.94403446 -0.32831717 0.12 s -0.28009185 -0.69064748 -0.66674930 0.11 s -0.40569898 0.53319919 -0.74236578 0.11 s -0.08303154 0.63425076 -0.76865578 0.11 s 0.67191207 -0.15620425 0.72397125 0.11 s 0.05704989 0.27052611 0.96102077 0.11 s -0.51951802 -0.06828057 0.85172695 0.11 s -0.09453978 0.15612932 0.98320186 0.11 s -0.54539442 0.48337340 0.68475914 0.11 s 0.55587947 0.38658622 0.73590016 0.11 s -0.71918267 0.32208264 -0.61566150 0.11 s 0.41397470 0.77044439 0.48480961 0.11 s 0.35012645 -0.79713798 0.49191713 0.11 s -0.41537294 0.80620837 -0.42129964 0.11 s -0.20100126 0.30711341 0.93020421 0.11 s -0.73254043 -0.53613847 -0.41945207 0.11 s 0.51073921 -0.75164759 0.41733843 0.11 s 0.11035598 -0.35062692 -0.92999053 0.11 s -0.65628725 -0.74956101 0.08628637 0.11 s 0.27815020 0.95094264 0.13542737 0.11 s -0.38365278 -0.10264999 0.91775459 0.11 s -0.02304614 0.41060296 0.91152292 0.11 s -0.95519060 0.18624714 0.23004974 0.11 s 0.28631783 0.95712799 0.04391000 0.11 s 0.83803469 -0.14055188 0.52720302 0.11 s 0.30466449 0.64805651 -0.69799876 0.11 s -0.34585559 0.78462297 0.51453930 0.11 s -0.30705619 0.79232156 -0.52720302 0.11 s -0.20241657 -0.96192235 0.18366541 0.11 s -0.55298036 -0.80296403 0.22239940 0.11 s -0.65979242 -0.02376109 -0.75107211 0.11 s -0.77209282 0.48292586 0.41310441 0.11 s 0.11520226 0.99313337 -0.02036077 0.11 s -0.34674484 0.89550656 -0.27899113 0.11 s 0.09718548 -0.69077909 -0.71650487 0.11 s 0.34548995 0.57480252 0.74178082 0.11 s 0.47053879 -0.83379537 0.28875330 0.11 s -0.06702755 0.97380269 0.21729152 0.11 s -0.36776796 0.74099892 -0.56184280 0.11 s 0.06297745 0.14664277 0.98718274 0.11 s 0.05109436 0.43169409 -0.90057182 0.11 s -0.82425487 0.06830928 0.56208336 0.11 s -0.89067721 -0.33752146 -0.30458724 0.11 s 0.73457247 -0.37105906 0.56808311 0.11 s -0.91698539 -0.32142320 0.23627289 0.11 s -0.57916695 0.73654079 0.34938985 0.11 s 0.89048982 0.44390103 -0.09989863 0.11 s 0.64917815 -0.65907240 0.37972528 0.11 s 0.22297069 0.96355408 0.14780942 0.11 s 0.41060585 -0.71226656 -0.56927955 0.11 s -0.59808165 -0.57621735 -0.55702055 0.11 s 0.11335858 -0.83113408 -0.54439503 0.11 s 0.11879084 0.99252665 -0.02792164 0.11 s 0.55000818 0.82848215 0.10539631 0.11 s 0.70524782 0.64228886 0.30015090 0.11 s 0.89267135 0.26308021 0.36595988 0.11 s 0.01331636 -0.98972809 -0.14234102 0.11 s 0.20679352 -0.81375545 0.54317445 0.11 s -0.60655761 0.45576113 -0.65143657 0.11 s -0.63933307 -0.76882815 -0.01250787 0.11 s -0.36940044 -0.00749600 -0.92924011 0.11 s 0.25149021 -0.49348897 -0.83259910 0.11 s 0.03733748 0.99070352 -0.13081460 0.11 s 0.04170690 -0.55739355 -0.82920021 0.11 s 0.30879807 -0.94106007 -0.13802078 0.11 s -0.27763349 0.81379700 -0.51054293 0.11 s 0.16378446 -0.05134004 -0.98515928 0.11 s -0.40817338 0.13604501 -0.90271050 0.11 s -0.78963786 0.37607408 -0.48480961 0.11 s 0.39948392 0.29264578 -0.86877561 0.11 s -0.26706287 0.28996271 -0.91902071 0.11 s 0.17697400 0.98316956 0.04536299 0.11 s 0.78747541 0.61607361 -0.01832493 0.11 s 0.74762714 0.43709683 -0.50000000 0.11 s -0.31821215 0.94645917 0.05436927 0.11 s -0.10998926 0.53092378 0.84025133 0.11 s 0.52791226 -0.55792660 -0.64033312 0.11 s 0.82071316 -0.56274337 0.09874083 0.11 s -0.98556840 0.09294692 0.14147718 0.11 s 0.91769487 -0.10672196 0.38268343 0.11 s -0.34229776 -0.30098066 -0.89008027 0.11 s 0.09015575 -0.60414648 0.79175687 0.11 s -0.89884365 -0.43387327 0.06191955 0.11 s -0.02248782 0.78264719 0.62205923 0.11 s 0.25258571 -0.45056310 -0.85626709 0.11 s -0.78409916 0.38137248 0.48963612 0.11 s -0.99795300 0.00021767 0.06395174 0.11 s 0.05053657 -0.24637669 0.96785563 0.11 s 0.29644650 -0.67612576 0.67451715 0.11 s 0.11173295 0.99156451 0.06569339 0.11 s -0.64075804 0.13459098 -0.75585347 0.11 s -0.44506562 -0.08416315 -0.89153415 0.11 s 0.89825159 -0.41790789 -0.13600376 0.11 s -0.81540012 0.27335677 0.51029277 0.11 s 0.39623907 0.84428084 0.36081082 0.11 s -0.45471194 0.82314330 0.34010601 0.11 s 0.55946529 -0.54516554 -0.62433416 0.11 s 0.01133531 -0.91145247 -0.41124922 0.11 s 0.48358843 0.87391502 0.04914031 0.11 s 0.66387743 0.18665963 -0.72417188 0.11 s 0.17862169 -0.71287709 -0.67815965 0.11 s -0.53801024 0.83203506 -0.13513915 0.11 s -0.02250913 0.51554394 0.85656744 0.11 s -0.08098520 0.98329026 -0.16303897 0.11 s -0.42195505 0.22114013 -0.87923318 0.11 s -0.14033660 -0.87047565 -0.47178149 0.11 s -0.58388776 0.75003684 0.31067643 0.11 s -0.37947649 -0.62310809 0.68391073 0.11 s 0.24430254 -0.51180786 0.82363158 0.11 s -0.51446205 -0.39601046 -0.76059484 0.11 s 0.20356199 0.55915546 0.80368382 0.11 s 0.24987087 -0.94239217 -0.22239940 0.11 s 0.90254885 -0.41863069 0.10076689 0.11 s -0.18163238 0.25984013 -0.94841594 0.11 s 0.53546655 -0.25468782 -0.80523890 0.11 s -0.78301841 0.61295408 -0.10568557 0.11 s 0.91674876 0.16137259 0.36541837 0.11 s -0.26401421 -0.91121536 0.31620100 0.11 s 0.09764633 0.90807372 0.40726805 0.11 s -0.29885694 -0.60780376 -0.73570317 0.11 s 0.76772618 -0.54879427 0.33078894 0.11 s -0.12454013 0.10071570 -0.98708969 0.11 s -0.05651807 0.59283608 0.80333745 0.11 s -0.24747016 0.59781480 0.76248014 0.11 s -0.14699948 -0.58022618 -0.80107975 0.11 s -0.73697346 0.42114368 0.52868527 0.11 s 0.45255783 0.13688669 -0.88116592 0.11 s 0.42390293 -0.68926877 0.58754992 0.11 s -0.06730826 -0.65787762 0.75011104 0.11 s -0.72709566 0.63633734 0.25769496 0.11 s 0.98582190 0.08884948 0.14234102 0.11 s -0.46154752 -0.88505226 -0.06046784 0.11 s 0.94389760 0.19439825 0.26695806 0.11 s -0.22128427 -0.71873832 -0.65912712 0.11 s -0.42435834 -0.71257460 -0.55871052 0.11 s -0.49377087 0.79559541 -0.35102463 0.11 s 0.49220243 -0.48721680 0.72135746 0.11 s -0.02886161 0.99689674 -0.07323819 0.11 s 0.31057680 0.92866534 0.20278729 0.11 s 0.14795466 0.81819993 0.55557024 0.11 s 0.62757397 -0.31352395 0.71263856 0.11 s 0.73508173 -0.38299927 -0.55943406 0.11 s 0.44565877 0.84960526 -0.28206238 0.11 s -0.47572201 -0.77542168 -0.41522256 0.11 s 0.36225629 0.84622669 0.39073113 0.11 s -0.46777189 -0.22315750 -0.85521352 0.11 s -0.53442764 -0.64716136 0.54366285 0.11 s -0.06860030 -0.96987891 -0.23372820 0.11 s 0.14771824 -0.54431856 0.82577032 0.11 s -0.45026284 0.53171515 0.71731609 0.11 s -0.65239948 0.49370426 0.57500523 0.11 s -0.71685773 -0.65295762 -0.24446128 0.10 s -0.48223948 -0.59951711 -0.63876784 0.10 s -0.75443381 0.08723526 -0.65055329 0.10 s -0.28132805 0.93945271 -0.19566089 0.10 s 0.41486886 -0.48482013 0.76995665 0.10 s -0.20466626 0.94329715 -0.26134694 0.10 s 0.16145687 0.63361323 -0.75661480 0.10 s -0.27568483 0.23695204 -0.93158555 0.10 s -0.11668020 0.49471661 0.86118591 0.10 s 0.50146252 -0.82287240 0.26723838 0.10 s 0.39395472 0.84100330 0.37082759 0.10 s 0.16663277 -0.57246625 0.80281746 0.10 s -0.25514433 -0.02101402 0.96667463 0.10 s 0.65163988 0.59659517 -0.46844387 0.10 s 0.39305910 0.84919763 -0.35265836 0.10 s -0.43439257 -0.42052728 -0.79652989 0.10 s 0.60631192 -0.76257950 0.22551788 0.10 s -0.15604267 -0.88873988 0.43103611 0.10 s 0.34245428 0.92951179 0.13686827 0.10 s 0.06205661 -0.93328029 -0.35374695 0.10 s -0.26554710 -0.63872188 -0.72216278 0.10 s -0.30163938 0.79060519 -0.53287631 0.10 s 0.12381939 -0.82931978 -0.54488295 0.10 s 0.16513813 -0.61380279 0.77199453 0.10 s 0.33409560 0.91854340 0.21132480 0.10 s -0.53219563 -0.05315924 -0.84495085 0.10 s 0.96196854 -0.21318965 0.17078274 0.10 s 0.15643649 -0.97484952 0.15873249 0.10 s 0.05220578 0.95114136 0.30431017 0.10 s 0.40811470 0.07649947 -0.90971988 0.10 s -0.31514683 -0.70796990 -0.63202929 0.10 s -0.03852731 0.34506425 -0.93778801 0.10 s -0.98741621 0.15624419 0.02443218 0.10 s -0.54504633 -0.77050936 -0.33051437 0.10 s 0.12907887 -0.99103022 -0.03460879 0.10 s -0.31504622 0.82628638 -0.46690121 0.10 s -0.38842770 -0.92140573 -0.01163527 0.10 s 0.63808537 0.00371227 -0.76995665 0.10 s -0.71873373 0.27871829 -0.63697559 0.10 s -0.18202823 -0.78897429 0.58684355 0.10 s 0.37179014 0.82135278 0.43261033 0.10 s -0.19035706 -0.94976711 0.24840812 0.10 s 0.47699505 -0.82576317 0.30098322 0.10 s 0.08001501 -0.79812229 -0.59715861 0.10 s -0.31456828 0.91034549 -0.26891983 0.10 s -0.13551098 -0.92936671 0.34338653 0.10 s -0.07265909 0.31820303 -0.94523406 0.10 s 0.49007457 0.87166810 -0.00465419 0.10 s 0.42385104 0.09535703 0.90069824 0.10 s 0.97436064 -0.22189091 0.03722509 0.10 s -0.91960371 -0.15849869 0.35945401 0.10 s 0.43515462 -0.22168265 0.87263811 0.10 s -0.12710609 0.61265022 -0.78006655 0.10 s 0.88077348 0.39206889 -0.26555610 0.10 s 0.24461636 -0.40100822 0.88281101 0.10 s -0.34340861 -0.75777185 0.55484444 0.10 s 0.19405630 -0.32010967 0.92729282 0.10 s -0.42029348 -0.79156739 -0.44359267 0.10 s 0.62259835 -0.42351428 0.65803260 0.10 s 0.94448769 -0.09115200 0.31564903 0.10 s 0.56169426 -0.28877467 0.77531207 0.10 s -0.07349384 0.98221320 0.17278869 0.10 s 0.22058907 0.54609144 0.80816126 0.10 s 0.13581064 0.94149119 0.30846366 0.10 s -0.05601164 -0.33546203 -0.94038713 0.10 s 0.88221288 0.03601168 -0.46947157 0.10 s 0.56966215 0.53925228 0.62023550 0.10 s 0.23997402 -0.92375261 0.29848558 0.10 s -0.77935737 0.60644007 0.15758358 0.10 s -0.14415088 -0.83129823 0.53680885 0.10 s 0.08021309 0.85788733 0.50753838 0.10 s -0.53600234 -0.43923372 -0.72095442 0.10 s 0.83566368 -0.41528195 -0.35945401 0.10 s 0.92842621 0.13289243 0.34693563 0.10 s 0.17688474 0.27561444 0.94485366 0.10 s 0.13819058 -0.26707178 -0.95371693 0.10 s 0.30835944 -0.66557038 0.67965472 0.10 s -0.80737489 -0.45981854 0.36974677 0.10 s -0.46392322 -0.18849763 0.86558872 0.10 s -0.54682589 -0.25353816 0.79793471 0.10 s 0.27331641 0.58104628 0.76660508 0.10 s -0.53812814 -0.79843366 -0.27004033 0.10 s 0.31766817 0.92827356 0.19337822 0.10 s -0.35917330 0.56533021 -0.74256063 0.10 s 0.31018341 -0.24285068 0.91913533 0.10 s 0.46928072 0.05094567 0.88157821 0.10 s -0.55136138 -0.83367497 -0.03141076 0.10 s 0.73716342 0.35180634 0.57690763 0.10 s -0.32609954 0.90227485 -0.28206238 0.10 s 0.41040513 0.79542905 0.44593748 0.10 s 0.59931201 -0.64559555 0.47331968 0.10 s -0.79994142 -0.55631894 0.22495106 0.10 s 0.46464521 -0.83795476 0.28624585 0.10 s 0.08817018 -0.94225144 -0.32309169 0.10 s 0.47961241 0.41162238 -0.77494448 0.10 s 0.07818063 -0.66302258 -0.74450576 0.10 s 0.94374007 0.32779878 -0.04361939 0.10 s 0.69842672 0.27043450 -0.66262007 0.10 s -0.26159105 -0.89650762 0.35755312 0.10 s -0.49510613 -0.32543012 -0.80558372 0.10 s 0.24384020 -0.26778123 -0.93211329 0.10 s 0.66705531 0.35948521 0.65253937 0.10 s 0.66172898 -0.58906168 -0.46381152 0.10 s 0.01713502 0.93863761 0.34447908 0.10 s -0.57854146 0.74372673 -0.33490345 0.10 s 0.76306343 -0.43678960 -0.47639167 0.10 s -0.35099441 -0.79455876 -0.49545869 0.10 s -0.28263360 0.91919053 0.27423897 0.10 s 0.27899671 -0.95771265 -0.07033682 0.10 s 0.64814466 0.76134300 -0.01628902 0.10 s -0.78773624 0.19312207 -0.58495766 0.10 s 0.27052525 -0.96054757 -0.06453231 0.10 s -0.97970563 0.20043653 -0.00145444 0.10 s 0.69754356 -0.54661661 0.46329606 0.10 s 0.81346947 0.58140326 -0.01541646 0.10 s -0.47761473 -0.77888739 -0.40647089 0.10 s 0.37296444 -0.66438872 0.64767671 0.10 s 0.25569111 0.05407680 0.96524495 0.10 s 0.19465664 -0.77092534 -0.60645109 0.10 s -0.05264551 0.05419961 -0.99714136 0.10 s 0.36928770 0.89855456 0.23712075 0.10 s -0.41463608 -0.72570717 0.54902279 0.10 s 0.95899338 0.27061471 -0.08425757 0.10 s -0.53377974 0.02957025 -0.84510636 0.10 s 0.72655916 -0.58756894 -0.35619444 0.10 s -0.13872690 0.23979856 0.96085978 0.10 s -0.79106635 -0.59981763 -0.12013684 0.10 s -0.11858726 0.79785174 -0.59107506 0.10 s 0.80987906 0.46648517 -0.35565078 0.10 s -0.80366302 0.54343915 0.24248636 0.10 s 0.55937517 0.11198571 0.82131517 0.10 s 0.46557611 -0.02270276 0.88471663 0.10 s -0.32816204 -0.31893799 -0.88915032 0.10 s 0.11554691 0.94904113 0.29320613 0.10 s -0.32071143 -0.72486514 -0.60968411 0.10 s 0.13271487 -0.82358223 0.55145174 0.10 s 0.70229059 -0.70793086 0.07497873 0.10 s -0.65533274 0.47758508 0.58519357 0.10 s 0.96516448 -0.26109940 -0.01687071 0.10 s -0.53062803 -0.13213652 -0.83724183 0.10 s -0.65137267 0.63592547 0.41389900 0.10 s -0.44849661 -0.88133270 -0.14867243 0.10 s 0.13007830 0.74244571 0.65715599 0.10 s -0.13556901 -0.99075085 -0.00581773 0.10 s -0.29540998 0.72118002 -0.62660378 0.10 s -0.33450472 0.70711750 -0.62296981 0.10 s -0.35434121 0.63293785 -0.68835455 0.10 s -0.48294449 0.16940090 -0.85910881 0.10 s -0.30067408 0.79361570 -0.52893215 0.10 s -0.55458623 0.00423480 -0.83211547 0.10 s 0.56664604 -0.69302541 0.44567710 0.10 s -0.63559288 0.59269994 0.49470046 0.10 s -0.38134170 0.70921665 -0.59295046 0.10 s -0.29889321 -0.02050746 0.95406616 0.10 s -0.03657598 -0.87115937 0.48963612 0.10 s -0.14165075 0.95925689 0.24446128 0.10 s 0.33308962 -0.85103738 -0.40593928 0.10 s 0.76107657 0.09496572 -0.64167279 0.10 s 0.74064732 -0.22985902 -0.63135284 0.10 s 0.40061375 -0.51592571 0.75718510 0.10 s -0.84628421 0.29539764 0.44333196 0.10 s 0.96275467 -0.23484282 -0.13398618 0.10 s -0.38179219 -0.42130432 -0.82264048 0.10 s -0.31846723 -0.37557900 -0.87035573 0.10 s 0.21605709 0.96132857 0.17078274 0.10 s 0.03965804 0.64379293 0.76417142 0.10 s -0.86028212 0.19571446 -0.47075528 0.10 s -0.90656137 0.29952410 -0.29737487 0.10 s 0.85895759 0.51204145 -0.00232710 0.10 s 0.52878898 -0.74099249 0.41389900 0.10 s 0.70764011 0.65690881 0.26022366 0.10 s 0.72312248 -0.61787808 -0.30874035 0.10 s 0.79242933 -0.39372462 -0.46587193 0.10 s -0.35267398 -0.49817607 -0.79211217 0.10 s 0.53996944 0.46973303 0.69841528 0.10 s -0.55259287 0.42915025 0.71447265 0.10 s -0.47158211 -0.69903916 0.53754491 0.10 s -0.82729697 -0.12228742 0.54829323 0.10 s -0.13705464 0.98036659 -0.14176513 0.10 s -0.66914833 0.06570888 -0.74021810 0.10 s -0.48114485 0.34573761 -0.80558372 0.09 s -0.31270516 -0.66528553 -0.67794585 0.09 s -0.32528648 -0.69704980 0.63899159 0.09 s 0.12490932 0.99049687 0.05756403 0.09 s 0.15815310 -0.98053193 0.11638183 0.09 s -0.87793404 -0.14573468 -0.45606273 0.09 s 0.20664251 0.41810927 -0.88458097 0.09 s 0.08279327 -0.98854393 0.12619896 0.09 s -0.23516674 0.97175378 -0.01977911 0.09 s -0.17980681 -0.33231482 0.92587060 0.09 s -0.04480330 0.17782207 -0.98304218 0.09 s 0.62296033 -0.75694430 0.19737218 0.09 s 0.65393585 0.63926440 -0.40460962 0.09 s -0.30652186 0.95184922 -0.00523596 0.09 s -0.58757079 -0.60307056 -0.53950578 0.09 s -0.45861626 -0.78312695 -0.41998014 0.09 s 0.04199196 0.09918749 0.99418235 0.09 s -0.49383113 0.37864479 -0.78278923 0.09 s -0.49511972 -0.62975007 -0.59855765 0.09 s 0.49860615 0.77035922 0.39741483 0.09 s -0.77083731 -0.09589891 -0.62977242 0.09 s -0.50394195 -0.07007719 -0.86089009 0.09 s -0.01796590 -0.89823151 0.43915531 0.09 s 0.11190712 0.62455928 -0.77291816 0.09 s 0.45691472 0.88132095 -0.12042561 0.09 s 0.33964181 0.08310982 -0.93687576 0.09 s 0.17849632 0.95570809 -0.23401104 0.09 s 0.07400727 0.83888060 -0.53926086 0.09 s 0.65058321 -0.11617942 0.75049567 0.09 s -0.19084719 0.12590031 -0.97351241 0.09 s -0.51325464 -0.64688975 0.56400657 0.09 s -0.48806673 -0.80089110 0.34693563 0.09 s -0.41945189 -0.57838678 -0.69966334 0.09 s 0.40975088 -0.26758066 0.87206930 0.09 s -0.84913313 -0.42993590 -0.30680296 0.09 s 0.13633108 0.16295378 0.97716933 0.09 s -0.07557794 -0.95852691 0.27479839 0.09 s -0.08240750 -0.02015864 -0.99639481 0.09 s 0.34054503 -0.82350290 -0.45373130 0.09 s -0.90116191 -0.12270973 0.41575176 0.09 s 0.68284047 -0.40873918 -0.60552549 0.09 s -0.91529459 -0.04423155 -0.40034905 0.09 s -0.58559352 0.60147846 0.54341871 0.09 s 0.01341477 -0.01248395 -0.99983209 0.09 s -0.83981395 -0.51817364 -0.16189088 0.09 s 0.65868866 0.30948740 0.68581831 0.09 s 0.50707620 0.75746143 0.41124922 0.09 s -0.47913653 0.45707342 0.74934107 0.09 s 0.41247064 -0.90735650 -0.08106875 0.09 s -0.40677094 -0.67553306 0.61497360 0.09 s 0.48004183 0.86557311 0.14262892 0.09 s -0.72741604 0.66899109 -0.15269837 0.09 s 0.33399579 0.90940636 -0.24784455 0.09 s 0.53453130 -0.16909282 0.82806033 0.09 s -0.03418900 0.49882975 0.86602539 0.09 s -0.89780712 0.29866058 0.32364219 0.09 s -0.37424722 -0.34726518 0.85985225 0.09 s -0.56940991 -0.28898236 -0.76958531 0.09 s 0.63954353 0.51689178 0.56904036 0.09 s -0.02621468 0.91933364 -0.39260468 0.09 s -0.22592956 0.88046890 -0.41680968 0.09 s 0.08843786 0.67516649 -0.73234487 0.09 s 0.17731854 -0.72647101 0.66392618 0.09 s -0.15689370 0.05305473 -0.98618942 0.09 s 0.71489513 -0.30100393 -0.63112724 0.09 s -0.28920507 0.35297287 -0.88981491 0.09 s 0.89002019 0.21764936 0.40061557 0.09 s 0.88952982 0.20809142 -0.40673664 0.09 s 0.12634943 0.13329975 0.98298883 0.09 s -0.26246828 0.32820040 0.90741110 0.09 s 0.02654687 -0.25688902 -0.96607625 0.09 s 0.18679737 0.96248418 0.19680183 0.09 s -0.07671280 -0.51457781 0.85400516 0.09 s 0.38641948 -0.16585241 0.90728879 0.09 s -0.44053313 0.59607130 -0.67128950 0.09 s 0.04326715 -0.74943995 -0.66065699 0.09 s 0.87029594 -0.44999519 -0.20022301 0.09 s 0.41426069 0.13346995 0.90031874 0.09 s -0.74785578 0.64619672 -0.15212339 0.09 s -0.12386753 0.14588746 -0.98151600 0.09 s 0.00782088 0.18435732 -0.98282820 0.09 s -0.00649401 -0.30894876 0.95105654 0.09 s -0.47811902 -0.83091539 -0.28457311 0.09 s -0.26789796 0.84558791 -0.46174860 0.09 s 0.04442682 0.10725582 0.99323839 0.09 s -0.01392653 -0.99736434 -0.07120730 0.09 s 0.08977612 -0.11886694 0.98884320 0.09 s -0.59570307 0.59813398 0.53607237 0.09 s -0.80865395 -0.00582208 0.58825582 0.09 s 0.04969680 -0.71518600 -0.69716513 0.09 s -0.24796982 0.19530821 -0.94887602 0.09 s -0.23208132 0.17552176 -0.95672899 0.09 s -0.70286620 -0.68330860 -0.19765733 0.09 s -0.38574913 -0.08123147 0.91902071 0.09 s 0.54905814 -0.83559579 -0.01774325 0.09 s 0.07253989 0.24961612 -0.96562403 0.09 s 0.52507657 0.84590006 -0.09352911 0.09 s -0.59338039 0.62392801 0.50854057 0.09 s -0.72054350 0.06826991 0.69004077 0.09 s 0.41998416 0.70232183 0.57476723 0.09 s -0.46212298 0.52004445 -0.71832871 0.09 s -0.75165612 -0.02920426 -0.65890831 0.09 s 0.40225187 0.53445292 0.74333942 0.09 s 0.46755937 0.54639482 0.69486761 0.09 s 0.13484041 0.95240259 0.27339965 0.09 s -0.97573155 -0.14488137 -0.16418685 0.09 s 0.77849281 -0.32239574 0.53852570 0.09 s -0.03628446 0.17741904 0.98346627 0.09 s 0.48063576 0.47993720 0.73392749 0.09 s 0.02133065 -0.46898672 -0.88294756 0.09 s -0.91999555 0.30589339 0.24502538 0.09 s -0.95780361 0.28500280 -0.03722509 0.09 s 0.39372465 -0.80994475 0.43470722 0.09 s -0.69836724 -0.35200608 0.62319732 0.09 s 0.10969372 -0.12216624 0.98642927 0.09 s 0.09247295 0.77694327 -0.62274224 0.09 s 0.05773379 -0.92733711 -0.36974677 0.09 s -0.16974871 0.85827631 0.48430070 0.09 s -0.44732746 -0.89005655 0.08773529 0.09 s -0.22631472 -0.80491579 -0.54853648 0.09 s 0.59738183 0.55060500 -0.58306867 0.09 s -0.71111619 -0.17505072 -0.68093395 0.09 s -0.17241234 -0.22779775 -0.95832258 0.09 s 0.12293304 -0.85221708 0.50854057 0.09 s -0.13959472 0.49290681 -0.85881090 0.09 s -0.36409658 -0.77682215 -0.51379085 0.09 s -0.96936411 0.09049394 -0.22835086 0.09 s -0.48002225 0.05819539 0.87532389 0.09 s 0.04385103 0.96722692 -0.25009838 0.09 s -0.70924586 0.54471552 -0.44749898 0.09 s -0.48570248 0.18296675 -0.85476094 0.09 s -0.45296001 -0.37422201 0.80918795 0.09 s -0.02549697 0.74095190 -0.67107385 0.09 s -0.51426506 0.56294531 -0.64701158 0.09 s 0.15301996 -0.70699894 -0.69046170 0.09 s -0.07652953 -0.17541252 0.98151600 0.09 s -0.31874904 -0.72785598 0.60714477 0.09 s 0.36591211 0.89052522 0.27032039 0.09 s 0.75816786 -0.61285710 -0.22268298 0.09 s -0.34082684 0.85446972 -0.39206955 0.09 s 0.63548446 -0.17902565 0.75107211 0.09 s -0.56821603 -0.20859383 -0.79600203 0.09 s -0.11184764 -0.21673931 0.96980113 0.09 s 0.21047315 -0.90684521 0.36514759 0.09 s 0.34443697 -0.93867803 -0.01570732 0.09 s -0.90519023 -0.11696135 0.40859598 0.09 s -0.81238765 -0.53821743 0.22438414 0.09 s -0.10713869 0.85509092 0.50728768 0.09 s 0.90044153 -0.25197253 0.35456303 0.09 s 0.97254241 0.02419303 0.23146492 0.09 s 0.90506220 0.18495962 -0.38295215 0.09 s 0.99745029 -0.05256503 -0.04826868 0.09 s 0.94923425 0.03743379 0.31233492 0.09 s -0.58557004 -0.53893095 0.60552549 0.09 s 0.25783256 0.92009324 0.29487428 0.09 s 0.04348406 -0.00610160 -0.99903548 0.09 s 0.14997381 -0.75483072 -0.63854402 0.09 s -0.86401737 -0.16801316 -0.47460037 0.09 s 0.77915972 -0.62375969 -0.06191955 0.09 s 0.57418633 -0.60559565 0.55096638 0.09 s 0.56529993 0.28215620 -0.77512830 0.09 s -0.55762744 -0.42839810 -0.71100402 0.09 s 0.92108047 -0.38168094 0.07700905 0.09 s -0.34127584 0.74412405 0.57429105 0.09 s 0.73891622 0.28241101 0.61175716 0.09 s -0.51985723 -0.26089269 0.81343931 0.09 s -0.03615450 0.92361683 -0.38160819 0.09 s -0.38716933 0.71171880 -0.58613670 0.09 s -0.38174960 0.45737782 -0.80316424 0.09 s -0.26775235 -0.59071350 -0.76116109 0.09 s 0.79314762 0.58058488 0.18395136 0.09 s 0.42422339 -0.74500138 0.51478875 0.09 s 0.16138738 -0.83317757 0.52893215 0.09 s -0.51387858 -0.38946649 0.76435900 0.09 s 0.80432713 0.13225421 0.57928121 0.09 s -0.59365755 0.42338669 -0.68433505 0.09 s -0.11900288 -0.30333501 -0.94542378 0.09 s 0.43798387 0.83394152 0.33572561 0.09 s 0.02820735 -0.80439937 0.59341890 0.09 s 0.19543920 0.97659922 0.08976348 0.09 s -0.44326821 0.88857305 -0.11811512 0.09 s -0.40427706 -0.69299370 0.59692526 0.09 s 0.08857200 -0.91428119 0.39527830 0.09 s 0.15587515 -0.66917276 -0.72657466 0.09 s -0.29473826 -0.95534211 0.02123324 0.08 s 0.71849757 0.42731968 0.54877967 0.08 s 0.20462273 0.88838148 0.41098404 0.08 s 0.98024040 0.04294106 0.19309282 0.08 s 0.21730447 0.22164591 -0.95060605 0.08 s 0.30187896 -0.15606160 0.94048595 0.08 s -0.43519223 -0.88850170 -0.14550747 0.08 s -0.95070475 0.24034461 -0.19594614 0.08 s -0.56468332 -0.75357050 -0.33654746 0.08 s -0.29699394 -0.94650328 0.12619896 0.08 s 0.23764004 -0.82309908 -0.51578587 0.08 s 0.56682986 0.64834028 0.50829005 0.08 s 0.33258176 -0.04780234 0.94186217 0.08 s -0.96275675 0.01813561 0.26976022 0.08 s 0.84058100 -0.22680627 -0.49191713 0.08 s 0.19503111 -0.09319919 -0.97635895 0.08 s -0.57291561 -0.76664513 -0.28986710 0.08 s 0.40186301 0.12995960 0.90643072 0.08 s -0.21177137 0.57687193 -0.78890532 0.08 s 0.27276930 0.95782828 -0.09034289 0.08 s 0.34661496 0.03131571 -0.93748462 0.08 s 0.81816798 0.23004085 0.52695578 0.08 s 0.89840287 0.28247541 0.33627352 0.08 s 0.68281788 0.66188914 0.30929363 0.08 s 0.42079437 -0.86707270 -0.26667771 0.08 s -0.37386918 0.57570809 -0.72717398 0.08 s 0.29720682 0.90930545 -0.29125878 0.08 s 0.58457881 0.70538014 -0.40088210 0.08 s 0.13436456 -0.58686209 0.79846042 0.08 s 0.82145220 0.55921948 -0.11175800 0.08 s -0.59831345 -0.80099595 -0.02065159 0.08 s 0.73515588 0.31559461 -0.59995484 0.08 s 0.67765450 -0.39400887 -0.62091982 0.08 s -0.55837214 -0.66632730 0.49419478 0.08 s -0.65039647 0.07137356 -0.75623429 0.08 s 0.87742519 0.34872651 0.32941601 0.08 s -0.37272358 0.88021636 0.29376230 0.08 s 0.04651998 -0.99724054 0.05785443 0.08 s 0.65188026 -0.21911806 -0.72597480 0.08 s -0.67680967 0.18061225 0.71365809 0.08 s 0.29416028 -0.18599015 -0.93748462 0.08 s -0.58289081 0.78248292 0.21899480 0.08 s -0.51158679 -0.06164459 -0.85701746 0.08 s -0.50140369 -0.08027452 0.86148149 0.08 s -0.19505596 -0.11873191 -0.97357893 0.08 s 0.85550302 0.49616712 -0.14809710 0.08 s 0.28260598 -0.94848627 0.14320475 0.08 s 0.15927559 0.54704219 0.82181269 0.08 s -0.43431327 0.50731874 -0.74431151 0.08 s -0.12204034 -0.67573255 -0.72697431 0.08 s -0.34398240 -0.50449562 0.79193455 0.08 s -0.39576980 0.14365740 -0.90704399 0.08 s -0.11749960 0.06733805 -0.99078727 0.08 s -0.35140061 0.48455018 0.80107975 0.08 s 0.82075828 0.22928852 -0.52324241 0.08 s 0.12173992 0.74443924 0.65649796 0.08 s 0.48096582 -0.75098246 0.45243469 0.08 s -0.07428565 0.82422996 -0.56136143 0.08 s -0.80885345 0.45390713 0.37379736 0.08 s 0.18557452 -0.77695584 0.60158271 0.08 s 0.23693608 -0.86460930 0.44307119 0.08 s -0.15828945 0.98319763 -0.09092227 0.08 s 0.74416155 -0.46274939 0.48175368 0.08 s 0.35068423 -0.08602810 -0.93253404 0.08 s 0.95119220 0.29247350 0.09845136 0.08 s 0.14332508 0.16482823 -0.97585326 0.08 s 0.14566477 0.66691387 0.73075825 0.08 s 0.74423236 -0.13737530 -0.65364075 0.08 s -0.15663525 -0.86190915 0.48226342 0.08 s -0.14903499 -0.38698715 -0.90996128 0.08 s 0.51137733 -0.84995359 0.12677607 0.08 s -0.55595082 0.20482560 0.80558372 0.08 s -0.36588281 -0.71653885 0.59388709 0.08 s 0.53717226 -0.03046353 0.84292227 0.08 s 0.48541242 -0.74889922 0.45113719 0.08 s 0.35867617 -0.36050645 0.86103803 0.08 s 0.20312132 0.44468024 0.87235385 0.08 s -0.70216155 -0.71037972 -0.04826868 0.08 s -0.87436432 0.42323369 0.23740333 0.08 s -0.21836713 -0.45398679 0.86383551 0.08 s 0.13090999 -0.37382051 -0.91821611 0.08 s -0.25210464 0.61725026 0.74528211 0.08 s -0.44354758 0.87098068 -0.21132480 0.08 s 0.36782414 0.69628978 0.61634892 0.08 s -0.19945699 0.69616222 -0.68961954 0.08 s -0.97271550 0.22949226 0.03402735 0.08 s -0.14977038 0.93548340 -0.32006186 0.08 s 0.03786787 -0.85872054 -0.51104307 0.08 s -0.20399451 0.27247843 -0.94028813 0.08 s -0.52127343 -0.22701675 0.82264048 0.08 s 0.30792099 0.89596039 -0.32006186 0.08 s 0.17888409 -0.07420284 0.98106802 0.08 s -0.28645924 0.41745090 0.86236644 0.08 s 0.50456220 0.26823342 0.82065088 0.08 s 0.56894422 0.81733447 -0.09092227 0.08 s 0.59911299 -0.08789056 -0.79582590 0.08 s -0.10938648 -0.93763399 0.32996526 0.08 s 0.66103649 0.10376182 -0.74314481 0.08 s -0.33518597 0.90896833 -0.24784455 0.08 s 0.03480341 0.88253456 0.46895781 0.08 s -0.56982356 -0.58545095 0.57666999 0.08 s -0.24274386 -0.73381054 -0.63450575 0.08 s 0.95769566 0.19927365 0.20762715 0.08 s -0.71457148 -0.69955641 -0.00290888 0.08 s 0.03251405 -0.95498270 -0.29487428 0.08 s -0.31163123 0.51321578 -0.79968464 0.08 s 0.30185190 -0.13122295 0.94428068 0.08 s -0.06902215 0.17604840 -0.98195869 0.08 s 0.53555149 -0.57927215 -0.61451471 0.08 s 0.76989418 0.62344801 -0.13629195 0.08 s -0.19626713 0.59172434 0.78188330 0.08 s -0.67534977 0.72686905 -0.12475602 0.08 s -0.39057219 0.45602393 -0.79968464 0.08 s -0.19331120 -0.43316659 0.88033944 0.08 s -0.63568264 -0.76523060 -0.10163508 0.08 s -0.11112763 -0.19948621 0.97357893 0.08 s 0.10632192 0.02595945 0.99399281 0.08 s -0.76167369 0.30188838 0.57333815 0.08 s -0.64730048 -0.59296846 0.47894722 0.08 s 0.25878492 -0.29984927 0.91821611 0.08 s 0.51433748 -0.57965153 -0.63202929 0.08 s 0.10760972 0.30843505 -0.94513911 0.08 s 0.33268172 -0.91839826 0.21416709 0.08 s -0.54836297 -0.54653180 0.63293058 0.08 s -0.52417046 0.81752503 -0.23853347 0.08 s 0.66320938 0.73937523 0.11609291 0.08 s 0.29956779 0.35002655 -0.88754749 0.08 s 0.48231849 0.22010179 0.84789389 0.08 s -0.37948865 0.33890507 -0.86089009 0.08 s 0.86742312 -0.48445502 -0.11349223 0.08 s 0.47108799 0.72495013 -0.50251704 0.08 s 0.50094920 -0.50828910 0.70049417 0.08 s -0.05866735 0.78868860 -0.61198723 0.08 s -0.49428463 -0.83288407 0.24897163 0.08 s -0.58304209 0.78292382 -0.21700758 0.08 s -0.01673263 -0.92395049 0.38214588 0.08 s -0.47404435 0.27405739 0.83676434 0.08 s 0.05879572 0.44912127 0.89153415 0.08 s -0.16145952 -0.81761408 -0.55266446 0.08 s 0.23792014 -0.45341140 -0.85895991 0.08 s 0.67689252 -0.70319086 0.21757543 0.08 s 0.24153018 0.87314832 0.42340899 0.08 s 0.77152640 0.46205392 0.43732503 0.08 s -0.25363395 0.49184549 -0.83292127 0.08 s -0.32710284 0.80977750 -0.48709771 0.08 s -0.54001868 -0.83901668 -0.06656414 0.08 s 0.03228542 0.96897894 0.24502538 0.08 s 0.43663144 -0.79986912 0.41177946 0.08 s 0.11738253 0.92700964 -0.35619444 0.08 s -0.49162126 -0.85841954 -0.14637080 0.08 s 0.97945178 -0.19230881 -0.06075819 0.08 -- 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 From guest Wed May 24 18:51:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA25353; Wed, 24 May 1995 18:45:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA25350; Wed, 24 May 1995 18:45:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA02504; Wed, 24 May 95 18:44:41 -0700 Received: from redgate.vislab.su.edu.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id SAA29597; Wed, 24 May 1995 18:44:47 -0700 From: horne@vislab.su.edu.au Received: from eaton.vislab.su.edu.au by redgate.vislab.su.edu.au via ESMTP (950215.SGI.8.6.10/940406.SGI) for id LAA29212; Thu, 25 May 1995 11:44:45 +1000 Received: by eaton.vislab.su.edu.au (950215.SGI.8.6.10/940406.SGI) for info-performer@sgi.com id LAA06062; Thu, 25 May 1995 11:44:44 +1000 Message-Id: <199505250144.LAA06062@eaton.vislab.su.edu.au> Subject: HCV colors to RGB colors (fwd) To: info-performer@sgi.sgi.com Date: Thu, 25 May 1995 11:44:43 +1000 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1286 Status: O Rejean Chartrand said: > I would like to know if anybody has ever converted HCV colors > to RGB colors. Presummably I need to have a "Base Color" to be able > to perform the conversion but I don't have any; I just have HCV values > which I would like to convert to RGB values. I would appreciate having > a piece of code that does that. If you mean converting HSV (Hue, Sat, Val) to RGB then there are tools to do this in /usr/people/4Dgifts the function is hsv_to_rgb(hh,ss,vv,&r,&g,&b); and it is part of /usr/include/libgutil.a other functions in the library are: irgb_to_rgb(ir,ig,ib,r,g,b); cmy_to_rgb(c,m,y,r,g,b); hls_to_rgb(h,l,s,r,g,b); hsv_to_rgb(h,s,v,r,g,b); hsb_to_rgb(h,s,v,r,g,b); yiq_to_rgb(y,i,q,r,g,b); rgb_to_cmy(r,g,b,c,m,y); rgb_to_irgb(r,g,b,ir,ig,ib); rgb_to_hls(r,g,b,h,l,s); rgb_to_hsv(r,g,b,lh,ls,lv); rgb_to_hsb(r,g,b,lh,ls,lv); rgb_to_yiq(r,g,b,y,i,q); ----------------------------------------------------------------------------- Geoff Horne http://www.usyd.edu.au/~ghorne Computational Scientist and VisLab conundrum rectifier ----------------------------------------------------------------------------- "Don't take life too seriously, you don't get out of it alive anyway" Burt Ward From guest Wed May 24 20:44:05 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id UAA25776; Wed, 24 May 1995 20:40:46 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id UAA25773; Wed, 24 May 1995 20:40:45 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06078; Wed, 24 May 95 20:40:07 -0700 Received: from sun.aitc.rest.tasc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id UAA12521; Wed, 24 May 1995 20:40:32 -0700 Received: by sun.aitc.rest.tasc.com (NX5.67d/NX3.0M-TASCnet-003) id AA22052; Wed, 24 May 95 23:37:41 -0400 Date: Wed, 24 May 95 23:37:41 -0400 From: "Thomas R. DeCarlo" Message-Id: <9505250337.AA22052@sun.aitc.rest.tasc.com> Subject: Re: Rqst Info on Yale Astron. Chart files To: stiles@aic.lockheed.com (Randy Stiles), info-performer@sgi.sgi.com X-Mailer: AIR Mail 3.X (SPRY, Inc.) Status: O If I'm right (you never know, it is possible) the Yale Astronomical Chart files are the same as Smithsonian Astronomical Observatory files. (SAO for short) These can be found at ftp://ftp.x.org/contrib/xephem. They can be used by the xephem program by Elwood Downey (ecdowney@noao.edu) which is also found there. There are about 10 files (~11Megs, 3Megs compressed) covering different sections of the sky. Thom <---- Begin Included Message ----> Date: Wed, 24 May 95 17:39:15 PDT From: stiles@aic.lockheed.com (Randy Stiles) Subject: Rqst Info on Yale Astron. Chart files To: info-performer@sgi.com Hi Everyone, A while ago Jim Helman listed some file formats that Performer 2.0 can handle. Lots of interesting formats, but one that caught my interest was: yale Astronomy chart translator Does anyone have a set of star chart files in this format that is publicly available? Thanks, // Randy Stiles Office: 415.354.5256 Orgn 9620 Bldg 255 // stiles@aic.lockheed.com Fax: 415.354.5235 3251 Hanover Street // Lockheed AI Center Lab: 415.424.2690 Palo Alto, CA 94304-1191 // http://hitchhiker.space.lockheed.com/~stiles/HOME.html <---- End Included Message ----> ,,, (o o) ++---------------------------------------++-----oOO--(_)--OOo-- -----++ || Thom DeCarlo || || || TASC || Any sufficiently || || 12100 Sunset Hills Rd. || advanced technology || || Reston, VA 22090 || is indistinguishable || || phone:703/834-5000 fax:703/318-7900 || from a rigged demo. || || email:trdecarlo@tasc.com || || ++---------------------------------------++-------------------- -----++ From guest Thu May 25 07:24:10 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA26564; Thu, 25 May 1995 07:21:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA26561; Thu, 25 May 1995 07:21:30 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19095; Thu, 25 May 95 07:19:55 -0700 Received: from luan.ridgefield.sdr.slb.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA22407; Thu, 25 May 1995 07:21:10 -0700 Received: (from reischer@localhost) by luan.ridgefield.sdr.slb.com (8.6.12/8.6.12) id KAA01026 for info-performer@sgi.com; Thu, 25 May 1995 10:22:19 -0400 Date: Thu, 25 May 1995 10:22:19 -0400 From: Andy Reischer Message-Id: <199505251422.KAA01026@luan.ridgefield.sdr.slb.com> To: info-performer@sgi.sgi.com Subject: Do I have to recompile Status: O Hi... I have a performer application I developed on a Indy. I want to try it on a power challenge (extreme graphics). Can I just bring the object libraries over, or do I have to get performer on it and recompile. Andy Reischer From guest Thu May 25 08:54:38 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA26705; Thu, 25 May 1995 08:48:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA26702; Thu, 25 May 1995 08:48:07 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21900; Thu, 25 May 95 08:46:23 -0700 Received: from blackhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA02731; Thu, 25 May 1995 08:48:04 -0700 Received: (from uucp@localhost) by blackhole.cae.ca (8.6.7/8.6.6) id LAA24925 for ; Thu, 25 May 1995 11:50:13 -0400 Received: from hell.cae.ca(142.39.201.1) by bhole via smap (V1.3mjr) id sma024910; Thu May 25 11:49:37 1995 Received: by cae.ca (4.1/SMI-4.1) id AA00207; Thu, 25 May 95 11:47:55 EDT Date: Thu, 25 May 95 11:47:55 EDT From: rejeanc@cae.ca (Rejean Chartrand) Message-Id: <9505251547.AA00207@cae.ca> To: info-performer@sgi.sgi.com Subject: Concerning HCV colors Status: O I got a few responses concerning the HCV colors I've submit but nothing of interest. To give you and idea HCV stands for Hue-Chroma-Value and is a color model developped by Tektronix Inc. and is something which is available as part of the SIF format (standard simulator data base interchange format). So, it is not HSV ! By, the way some people are calling HCV as HVC but it is the same. So if anybody has code to convert HCV (or HVC) to RGB I would really appreciate to have it. Thanks in advance ! Rejean Chartrand. CAE Electronics Ltd., Montreal CANADA. From guest Thu May 25 09:51:22 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA26849; Thu, 25 May 1995 09:48:11 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA26846; Thu, 25 May 1995 09:48:10 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24934; Thu, 25 May 95 09:46:14 -0700 Received: from ivan.engr.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id JAA13059; Thu, 25 May 1995 09:48:07 -0700 Received: by ivan.engr.sgi.com (940816.SGI.8.6.9/911001.SGI) id JAA12595; Thu, 25 May 1995 09:48:05 -0700 Date: Thu, 25 May 1995 09:48:05 -0700 From: ib@ivan.engr.sgi.com (Ivan Bach) Message-Id: <199505251648.JAA12595@ivan.engr.sgi.com> To: info-performer@sgi.sgi.com, rejeanc@cae.ca (Rejean Chartrand) Subject: Re: Concerning HCV colors Status: O >From the Color Space FAQ posted in the newsgroup sci.image.processing: ------------------------------------------------------------------------ HSL (Hue Saturation and Lightness) This represents a wealth of similar color spaces, alternatives include HSI (intensity), HSV (value), HCI (chroma/colorfulness/intensity), HVC, TSD (hue saturation and darkness) etc etc. All these color spaces are non- linear transforms from RGB and thus, device dependent, non-linear but very intuitive. In addition the seperation of the luminance component has advantages in image processing and other applications. (But take care, the complete isolation of the separate components will require a space optimised for your device. See later notes on CIE color spaces) ------------------------------------------------------------------------ It seems that you need to characterize a particular device (measure its properties), and then determine how HVC values can be converted to RGB values. For example, you could prepare a table of corresponding values. Check with the manufacturer of your device (e.g., Sony for a Sony video monitor). Color matching systems usually have conversion tables for the color models and devices they support. Ivan Bach, ib@sgi.com From guest Thu May 25 13:02:55 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA27759; Thu, 25 May 1995 12:58:53 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA27756; Thu, 25 May 1995 12:58:53 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06713; Thu, 25 May 95 12:56:06 -0700 Received: from vision.arc.nasa.gov by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA22834; Thu, 25 May 1995 12:58:45 -0700 Received: from descartes.arc.nasa.gov (descartes.arc.nasa.gov [128.102.121.143]) by vision.arc.nasa.gov (8.6.12/8.6.5) with ESMTP id MAA27631 for ; Thu, 25 May 1995 12:58:27 -0700 Received: (carlo@localhost) by descartes.arc.nasa.gov (8.6.12/8.6.5) id MAA09031 for info-performer@sgi.com; Thu, 25 May 1995 12:58:28 -0700 Date: Thu, 25 May 1995 12:58:28 -0700 From: "Carlo L. Tiana" Message-Id: <199505251958.MAA09031@descartes.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: Performer consulting job Status: O We are looking for an expert (Open)Performer/simulation programmer, to help us write (or modify an existing) rendering module so as to - render a visual scene (as perfly, for example) - change the visually rendered colors to specific grayscale values through some sort of lookup mechanism - add noise (having specific statistical characteristics) to the rendered grey image in real time The scope of this task will involve database handling issues (format translations or enhancements), so expertise with E&S systems and/or MultiGen would be great. This simulation will run in real time on an SGI platform 'slaved' to an E&S system, which provides aircraft coordinates to the SGI system over Ethernet, to 'position' the eyepoint in the SGI-based simulation. Expertise in interfacing to TCP/IP, or in interprocess communication, would also be great. The real time aspect of this simulation will require familiarity with SGI Onyx-level graphics hardware, and experience with multithreaded applications would be useful. This simulation needs to be completed in a very short timeframe (< 6 months), and the work can be carried out in the Bay Area or in Portland, OR. Interfacing to the E&S system as well as final debugging and installation of the SGI platform will involve some travel to the Minneapolis/St. Paul area. This simulation is intended to run in a fully certified civilian aircraft simulator operated by a major US airline, and is part of an exciting high-technology development program with possible far reaching future impact on civilian and military aviation. The successful applicant is likely to be an individual with detailed knowledge of Performer, and with the ability to incorporate enhancements into the rendering paradigm as required, in an imaginative, efficient and timely fashion. This individual will undoubtedly have a demonstrated track record for on-time delivery of code under consulting arrangements. If you are interested, please send your resume to me in one of the following ways (in order of preference): - by email to: carlo@vision.arc.nasa.gov - by FAX, marked attn. Carlo Tiana, to: (503) 684-7046 - by US mail to: Carlo TIana M/S 262-2 NASA Ames Research Center Moffett Field, CA 94035-1000 Thank you. From guest Thu May 25 15:22:59 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA28380; Thu, 25 May 1995 15:20:10 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA28377; Thu, 25 May 1995 15:20:09 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14710; Thu, 25 May 95 15:16:37 -0700 Received: from shadow.eecs.berkeley.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA23603; Thu, 25 May 1995 15:20:02 -0700 Received: (from delnaz@localhost) by shadow.eecs.berkeley.edu (8.6.11/8.6.9) id PAA23438 for info-performer@sgi.com; Thu, 25 May 1995 15:20:13 -0700 Date: Thu, 25 May 1995 15:20:13 -0700 From: Delnaz Khorramabadi Message-Id: <199505252220.PAA23438@shadow.eecs.berkeley.edu> To: info-performer@sgi.sgi.com Subject: ViewKit & Performer Status: O I am porting an application to Performer that is currently using FORMS library for its user interface. I would like to replace FORMS with Motif. My preferance is to use ViewKit. Has anyone tried ViewKit with Performer? Is there sample code? Would ViewKit affect the performance of my application? Also I noticed that the pfutil library provides a GUI with a limited widget set. Is this GUI more efficient than using Motif? Thanks Delnaz ------------------------------------------------------------------------ Delnaz Khorramabadi delnaz@eclair.eecs.berkeley.edu ------------------------------------------------------------------------ From guest Thu May 25 09:49:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA26840; Thu, 25 May 1995 09:45:18 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA26837; Thu, 25 May 1995 09:45:13 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24743; Thu, 25 May 95 09:43:17 -0700 Received: from faui45.informatik.uni-erlangen.de by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id JAA12463; Thu, 25 May 1995 09:44:54 -0700 Received: from faui90.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA17649 (5.65c-7/7.3w-FAU); Thu, 25 May 1995 18:41:05 +0200 Received: from faui90i.informatik.uni-erlangen.de by immd9.informatik.uni-erlangen.de with ESMTP; id SAA03933 (940816.SGI.8.6.9/7.3m-FAU); Thu, 25 May 1995 18:41:03 +0200 From: "Joerg Leisenberg" Message-Id: <9505251841.ZM3277@immd9.informatik.uni-erlangen.de> Date: Thu, 25 May 1995 18:41:01 -0600 Reply-To: Joerg Leisenberg X-Face: xDr}R<\Uo*94w4!\SzF(#?hd&jn-PrYjrXMF]0T>|knWu<3r_){_]AbAcu{Mih|Ae%2xwiq f8:SnyF(;>w*2K~ X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Performer and Spaceball Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O I want to use a spaceball from within a Performer 1.2 application using the X input model. I stepped through the code of GLUT so I know how to use X input extensions (and to open an XDevice etc) but I've problems to adapt the code to the Performer multi process environment. Has anybody solved this problem? Does a function exist that I can use as a pfuInputHandler? And who knows where I have to initialize the device? It seems that I've to do it from the X input process that is spawned by pfuInitInput() but how can I do this? Any help would be appreciated! Joerg -- =============================================================================== Joerg Leisenberg Email: jgleisen@immd9.informatik.uni-erlangen.de =============================================================================== From guest Thu May 25 19:59:10 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA29671; Thu, 25 May 1995 19:56:31 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA29668; Thu, 25 May 1995 19:56:31 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27803; Thu, 25 May 95 19:56:29 -0700 Received: from warrane.connect.com.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA11674; Thu, 25 May 1995 19:56:06 -0700 Received: (from root@localhost) by warrane.connect.com.au with UUCP id MAA20606 (8.6.11/IDA-1.6 for info-performer@sgi.com); Fri, 26 May 1995 12:55:38 +1000 Received: from aggro (aggro_e) by zebedee.wormald.com.au with SMTP id AA04353 (5.65c/IDA-1.5 for ); Fri, 26 May 1995 12:18:44 +1000 Received: from homer (homer [8.0.0.44]) by aggro with SMTP id MAA20829 (8.6.12/IDA-1.6 for ); Fri, 26 May 1995 12:21:11 +1000 Received: by homer (5.65) id AA11299; Fri, 26 May 1995 12:21:27 +1000 Date: Fri, 26 May 1995 12:21:26 +1000 (EST) From: Kathy Loynes Subject: rectzoom() & convolve() crashing graphics To: Performer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Hi, This is not strictly a Performer question but I was hoping someone reading this might be able to help ... I am trying to use convolve() and rectzoom() to affect a rectcopy() that I am doing in my Draw callback. I seem to be able to call either : convolve(CV_SEPARABLE, ..); . . rectcopy(0, 0, ...); . . convolve(CV_OFF, ..); or : rectzoom(..); . . rectcopy(0, 0, ...); successfully and get the expected result. However if I try to combine the two effects : convolve(CV_SEPARABLE, ..); rectzoom(..); . . rectcopy(0, 0, ...); . . convolve(CV_OFF, ..); then the graphics crash. The following information is written to SYSLOG : unix: WARNING: RE pipe 0: pickfeed operation timed out unix: pipe#0 unix: TP AP IA I0 I1 I2 I3 I4 I5 I6 I7 I8 I9 Ia Ib Ic Id Ie If O0 O1 O2 O3 unix: expd 00 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f unix: RM0: 00 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f unix: CP: HOST*: DATA=0x398 WE_L=1 TAG=0 GERDY_L=111111000010 RMRDY=1111 GPISRC WE_L=0 ACT_L=0 unix: GEF[0..5]: GERDY_L=111111 GRANTIN_L=111111 CPREQ_L=111111 unix: GE0 0 0 200 PB_HOLD unix: GE1 0 0 0 unix: GE2 0 0 200 PB_HOLD unix: GE3 0 0 200 PB_HOLD unix: GE4 0 0 200 PB_HOLD unix: GE5 0 0 300 GEOWN PB_HOLD Xsession: kathyl: fatal IO error 32 (Broken pipe) Does anyone know what I am doing (or not doing) that causes this to happen ?? I was using a RealityEngine with 1 RM. Thanks a lot. ---------------------------------------------------------------------- Kathy Loynes | Wormald Technology kathyl@wormald.com.au | Advanced Systems Engineering Ph: +61 2 981 0611 | Sydney, Australia From guest Thu May 25 21:24:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id VAA00072; Thu, 25 May 1995 21:20:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id VAA00069; Thu, 25 May 1995 21:20:22 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00593; Thu, 25 May 95 21:20:21 -0700 Received: from palladium.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id VAA19542; Thu, 25 May 1995 21:20:19 -0700 Received: from giraffe.asd.sgi.com by palladium.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id VAA02434; Thu, 25 May 1995 21:20:17 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:reischer@ridgefield.sdr.slb.com id AA00584; Thu, 25 May 95 21:20:15 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id VAA25411; Thu, 25 May 1995 21:20:15 -0700 Message-Id: <199505260420.VAA25411@surreal.asd.sgi.com> To: Andy Reischer Cc: info-performer@sgi.sgi.com Subject: Re: Do I have to recompile In-Reply-To: Your message of "Thu, 25 May 95 10:22:19 EDT." <199505251422.KAA01026@luan.ridgefield.sdr.slb.com> Date: Thu, 25 May 95 21:20:14 -0700 From: Jim Helman Status: O > I have a performer application I developed on a Indy. I > want to try it on a power challenge (extreme graphics). > Can I just bring the object libraries over, or do I have > to get performer on it and recompile. In principle, you should install performer_eoe on the target system from the CD-ROM, since Performer could have graphics or CPU dependent libraries (DSOs). But that's not the case in 1.2, so you can just copy the files over. performer_eoe will eventually be distributed with IRIX. A statically linked Performer binary will run on any machine with a compatible IRIX. A dynamically linked Performer binary will run on any machine with libpf.so and libpr.so installed. The only issue is making sure that your application's use of Performer is MP safe, i.e. no rendering calls from the APP process. You can test this on your Indy by forcing an MP model like pfMulitprocess(PFMP_APP_CULL_DRAW). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri May 26 00:50:54 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA10583; Fri, 26 May 1995 00:47:49 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA10580; Fri, 26 May 1995 00:47:48 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04347; Fri, 26 May 95 00:47:47 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id AAA02931; Fri, 26 May 1995 00:47:36 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) id AAA07592; Fri, 26 May 1995 00:47:32 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id IAA25663; Fri, 26 May 1995 08:42:55 +0100 From: "Rob Jenkins" Message-Id: <9505260842.ZM25661@barney.reading.sgi.com> Date: Fri, 26 May 1995 08:42:54 +0100 In-Reply-To: "Ben Simons" "Answer: cvd and performer" (May 26, 3:08pm) References: <9505261508.ZM21045@moffatt.vislab.su.edu.au> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Ben Simons" , info-performer@sgi.sgi.com Subject: Re: Answer: cvd and performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Ben I can't reproduce this behaviour for Irix 5.3 and Workshop 2.4 - please try the attached code to see if I'm doing the same as you. In follow.c there is an instance of type stucture SharedData call shared - set a break on the line: shared = (SharedData *) pfMalloc(sizeof(SharedData),arena); then step over and try and dereference shared in the structure browser. Also to be sure we are on the same page could you send me the output of: %versions -a | grep -i workshop and: %uname -a Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Fri May 26 00:53:56 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA10588; Fri, 26 May 1995 00:50:39 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA10585; Fri, 26 May 1995 00:50:39 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04391; Fri, 26 May 95 00:50:36 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id AAA03040; Fri, 26 May 1995 00:50:31 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) id AAA07655; Fri, 26 May 1995 00:50:05 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id IAA25671; Fri, 26 May 1995 08:45:29 +0100 From: "Rob Jenkins" Message-Id: <9505260845.ZM25669@barney.reading.sgi.com> Date: Fri, 26 May 1995 08:45:28 +0100 In-Reply-To: "Ben Simons" "Answer: cvd and performer" (May 26, 3:08pm) References: <9505261508.ZM21045@moffatt.vislab.su.edu.au> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Ben Simons" , info-performer@sgi.sgi.com Subject: Re: Answer: cvd and performer Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19505260845.ZM25669.reading.sgi.com" Status: O -- --PART-BOUNDARY=.19505260845.ZM25669.reading.sgi.com Content-Type: text/plain; charset=us-ascii Ben As is traditional - I forgot to attach the attachment :-) Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, --PART-BOUNDARY=.19505260845.ZM25669.reading.sgi.com X-Zm-Content-Name: follow.c Content-Description: Text Content-Type: text/plain ; name="follow.c" ; charset=us-ascii /* * follow.c - loads terrain and model_files specified and * puts each model under an SCS, then follows terrain in * a spiral * * Copyright 1994, Silicon Graphics, Inc. * Worldwide Education R & D * Developer: David Marsland, mars@sgi.com */ #include #include #include "pf.h" #include "pfsgi.h" #include "pfutil.h" #define MAX_MODELS 100 /* function prototypes */ void initialize( int argc, char *argv[] ); static void openPipeline (pfPipe *p); pfGroup *buildScene( int argc, char *argv[] ); pfSCS *loadTerrain( int argc, char *argv[] ); void followTerrain( void ); void fogScene( void ); void printHelp( char *programName ); typedef struct SharedData { pfCoord view; float eyeRadius; pfChannel *chan; pfScene *scene; void *texList; int modelCount; } SharedData; /* Global Variables */ SharedData *shared; pfSCS *terrainSCS; pfDCS *dcs[MAX_MODELS]; pfSegSet segset; pfMatrix terrainSCSmatrix; int main(int argc, char *argv[]) { pfCoord view; float time; int i; float maxTime = 120.0; initialize( argc, argv ); pfInitClock (0.0f); /* Simulate for maxTime seconds. */ /* main loop */ while (time < maxTime) { float s, c; float angle; /* Go to sleep until next frame time. */ pfSync(); /* Compute new view position. */ time = pfGetTime(); angle = 200.0f + 6.0f*time; pfSinCos(angle, &s, &c); #define SPIRAL #ifdef SPIRAL /* make eyepoint move in a circle that spirals in with time */ shared->view.xyz[PF_X] = c*4.0/(1.0f+time/maxTime); shared->view.xyz[PF_Y] = s*4.0/(1.0f+time/maxTime); #else /* make eyepoint move in a circle */ shared->view.xyz[PF_X] = c*4.0; shared->view.xyz[PF_Y] = s*4.0; #endif followTerrain(); pfSetVec3(view.xyz, shared->view.xyz[PF_X], shared->view.xyz[PF_Y], shared->view.xyz[PF_Z]); pfSetVec3(view.hpr, angle, 0.0f, 0.0f); pfChanView (shared->chan, view.xyz, view.hpr); /* spin each model */ for ( i = 0; i < shared->modelCount; i++ ) { pfDCSRot( dcs[i], time*10.0f, 0.0f, 0.0f ); } /* Initiate cull/draw for this frame. */ pfFrame(); } pfExit(); exit(0); } /* * intialize() initializes and configures Performer, * creates a graphics pipe and a channel, and calls * buildScene() to load a scene */ void initialize( int argc, char *argv[] ) { int i; pfPipe *pipe; pfGroup *root; pfEarthSky *eSky; pfSphere sceneBSphere; void *arena; /* check usage */ if (argc < 2) { fprintf(stderr, "Usage: %s terrain_file [model_file...]\n", argv[0]); exit (0); } printHelp( argv[0] ); pfInit(); /* Initialize Performer */ arena = pfGetSharedArena(); /* Malloc storage in shared memory region for shared data, * must be done between pfInit() and pfConfig(), since pfConfig() * may fork processes for cull and draw */ shared = (SharedData *) pfMalloc(sizeof(SharedData),arena); /* If debugging, force multiprocessing mode even if on single processor */ #ifdef DEBUG pfMultiprocess(PFMP_APP_CULL_DRAW); #endif /* Else use default multiprocessing mode based on number of processors. */ pfConfig(); /* Configure */ pipe = pfGetPipe(0); shared->chan = pfNewChan(pipe); /* Create a scene! */ shared->scene = pfNewScene(); root = buildScene( argc, argv ); pfAddChild( shared->scene, root ); /* initialize graphics pipeline and call openPipeline when ready */ pfInitPipe(pipe, openPipeline); /* specify scene to be viewed by channel */ pfChanScene(shared->chan, shared->scene); /* Get the scene's extents. */ pfGetNodeBSphere(shared->scene, &sceneBSphere); printf("Scene bounds - center: %f %f %f, radius: %f\n", sceneBSphere.center[0], sceneBSphere.center[1], sceneBSphere.center[2], sceneBSphere.radius); pfChanNearFar( shared->chan, 0.05f, 2.5f*sceneBSphere.radius ); /* Add an earth/sky effect */ eSky = pfNewESky(); pfESkyMode(eSky, PFES_BUFFER_CLEAR, PFES_SKY_GRND); pfESkyAttr(eSky, PFES_GRND_HT, -1.0f); pfESkyColor(eSky, PFES_GRND_NEAR, 0.0f, 0.3f, 0.8f, 1.0f); pfESkyColor(eSky, PFES_GRND_FAR, 0.0f, 0.0f, 0.4f, 1.0f); pfChanESky(shared->chan, eSky); /* set initial view position */ shared->view.xyz[PF_X] = 0.0f; shared->view.xyz[PF_Y] = -12.0f; shared->view.xyz[PF_Z] = 2.0f; /* set up intersection segment, pointing down for terrain following */ segset.activeMask = 0x1; segset.isectMask = 0xFFFF; segset.mode = PFTRAV_IS_PRIM|PFTRAV_IS_NORM|PFTRAV_IS_CULL_BACK; pfSetVec3(segset.segs[0].dir, 0.0f, 0.0f, -1.0f); segset.segs[0].length = 50000.0f; } void printHelp( char *programName ) { fprintf(stdout, "\n\ %s loads terrain and model_files specified and puts each model under an SCS\n\n\ Escape key - exit the program\n\ \n", programName ); } pfGroup *buildScene( int argc, char *argv[] ) { pfSCS *circleTrans; pfMatrix matrix; pfGeoState *gst1; pfMaterial *mt1, *mt2; pfNode *models[MAX_MODELS]; pfSCS *circleSCS[MAX_MODELS]; pfSCS *scaleSCS[MAX_MODELS]; pfSphere bounding_sphere; float unitScaler; pfGroup *root; int i; void *arena; root = pfNewGroup(); terrainSCS = loadTerrain( argc, argv ); pfAddChild( root, terrainSCS ); arena = pfGetSharedArena(); /* Create 1st geostate */ gst1 = pfNewGState(arena); mt1 = pfNewMtl(arena); pfMtlColor(mt1, PFMTL_DIFFUSE, 0.4f, 0.2f, 1.0f); pfGStateAttr(gst1, PFSTATE_FRONTMTL, mt1); shared->modelCount = argc - 2; if (shared->modelCount > MAX_MODELS) shared->modelCount = MAX_MODELS; /* read in all model files specifed as command line args */ for ( i = 0; i < shared->modelCount; i++ ) { if ( (models[i] = LoadFile( argv[i+2], gst1 ) ) == NULL ) { fprintf( stderr, "Model file %s not found, exiting %s\n", argv[i+1], argv[0] ); pfExit(); exit(-1); } else { fprintf( stdout, "Loading Model file %s\n", argv[i+1] ); /* Get the model's extents */ pfGetNodeBSphere(models[i], &bounding_sphere); /* create a matrix used to place all models on a circle of radius 10 */ /* rotate to a different, evenly spaced, angle for each model */ pfMakeRotMat( matrix, (float) i*( 360.0f/(float) shared->modelCount ), 0.0f, 0.0f, 1.0f ); /* translate out to radius 5 and up by 1.0 */ pfPreTransMat( matrix, 5.0f, 0.0f, 1.0f, matrix ); /* create an SCS using matrix to place all models * on a circle of radius 5 */ circleSCS[i] = pfNewSCS( matrix ); pfAddChild( root, circleSCS[i] ); dcs[i] = pfNewDCS(); pfAddChild( circleSCS[i], dcs[i] ); /* scale each model to unit size by scaling the SCS matrix */ unitScaler = 1.0f/bounding_sphere.radius; pfMakeScaleMat( matrix, unitScaler, unitScaler, unitScaler ); scaleSCS[i] = pfNewSCS( matrix ); pfAddChild( dcs[i], scaleSCS[i] ); pfAddChild( scaleSCS[i], models[i] ); } } return ( root ); } /* * OpenPipeline() -- create a GL window: set up the * window system, IRIS GL, and IRIS Performer. This * procedure is executed in the draw process (when * there is a separate draw process). */ static void openPipeline (pfPipe *p) { static int texture = 1; static int fog = 1; void *arena; /* Open graphics window. */ foreground(); prefposition(100, 500, 100, 500); winopen("IRIS Performer"); winconstraints(); /* Configure window with reasonable defaults. */ pfInitGfx(p); arena = pfGetSharedArena(); /* Create and apply a default material for those models * without one. */ pfApplyMtl(pfNewMtl( arena )); /* Create a default lighting model. */ pfApplyLModel(pfNewLModel( arena )); /* Turn on lighting */ pfEnable(PFEN_LIGHTING); pfLightOn(pfNewLight(arena)); if (texture) { /* Initialize IRIS Performer utility library. */ pfuInitUtil(); /* Prebind textures to be used in simulation */ shared->texList = pfuMakeTexList((pfNode *)shared->scene); pfuDownloadTexList(shared->texList, PFUTEX_SHOW); pfEnable(PFEN_TEXTURE); /* create a default texture environment */ pfApplyTEnv(pfNewTEnv( arena )); pfuExitUtil(); } if (fog) fogScene(); } pfSCS *loadTerrain( int argc, char *argv[] ) { pfNode *terrain; pfSCS *terrainSCS; pfMatrix matrix; pfSphere bounding_sphere; float unitScaler; int i; /* load terrain model */ if ( (terrain = LoadFile( argv[1], NULL ) ) == NULL ) { fprintf( stderr, "Model file %s not found, exiting %s\n", argv[1], argv[0] ); pfExit(); exit(-1); } else { fprintf( stdout, "Loading Model file %s\n", argv[1] ); /* Get the model's extents */ pfGetNodeBSphere(terrain, &bounding_sphere); printf("bounding_sphere.center = %f, %f, %f, radius = %f\n", bounding_sphere.center[0], bounding_sphere.center[1], bounding_sphere.center[2], bounding_sphere.radius ); /* scale model to 30*unit size by scaling the SCS matrix */ unitScaler = 30.0f/bounding_sphere.radius; pfMakeScaleMat( terrainSCSmatrix, unitScaler, unitScaler, unitScaler ); /* center terrain at the origin by translating * by the negative of the center of bounding sphere */ pfPreTransMat(terrainSCSmatrix, -bounding_sphere.center[0], -bounding_sphere.center[1], -bounding_sphere.center[2], terrainSCSmatrix); terrainSCS = pfNewSCS (terrainSCSmatrix); pfAddChild( terrainSCS, terrain ); /* set up terrain for intersections */ pfNodeTravMask (terrainSCS, PFTRAV_ISECT, 1, PFTRAV_DESCEND, PF_SET); return ( terrainSCS ); } } void followTerrain( void ) { pfHit **hits[100]; long isect; /* update location of intersection segment */ pfSetVec3(segset.segs[0].pos, shared->view.xyz[PF_X], shared->view.xyz[PF_Y], shared->view.xyz[PF_Z]); /* do an intersection test against the terrain scene graph */ isect = pfSegsIsectNode(terrainSCS, &segset, hits); /* if successful, set our height to that of the point of contact, plus a small offset */ if (isect) { pfVec3 pnt, xformed_pnt; pfQueryHit (*hits[0], PFQHIT_POINT, &pnt); pfXformPt3( xformed_pnt, pnt, terrainSCSmatrix ); shared->view.xyz[PF_Z] = xformed_pnt[PF_Z] + 0.5; #ifdef DEBUG printf("hit view.xyz[PF_Z] = %f\n", shared->view.xyz[PF_Z] - 0.5); #endif } } void fogScene( void ) { pfFog *fog; fog = pfNewFog(pfGetSharedArena()); pfFogType (fog, PFFOG_VTX_EXP); pfFogColor (fog, 0.8, 0.8, 0.8); pfFogRange (fog, 0.0f, 25.0f); pfApplyFog (fog); pfEnable (PFEN_FOG); pfOverride(PFSTATE_FOG | PFSTATE_ENFOG, PF_ON); } --PART-BOUNDARY=.19505260845.ZM25669.reading.sgi.com-- From guest Fri May 26 05:13:58 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA10820; Fri, 26 May 1995 05:06:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA10817; Fri, 26 May 1995 05:06:11 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA08532; Fri, 26 May 95 05:06:09 -0700 Received: from sangam.ncst.ernet.in by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id FAA16326; Fri, 26 May 1995 05:05:43 -0700 Received: from hamsadvani.serc.iisc.ernet.in ([144.16.79.131]) by sangam.ncst.ernet.in (8.6.12/8.6.6) with ESMTP id RAA04245; Fri, 26 May 1995 17:35:52 +0530 Received: (from sectra@localhost) by hamsadvani.serc.iisc.ernet.in (8.6.11/8.6.9) id RAA07132; Fri, 26 May 1995 17:48:33 +0500 Date: Fri, 26 May 1995 17:48:33 +0500 From: Serc Trainees Message-Id: <199505261248.RAA07132@hamsadvani.serc.iisc.ernet.in> To: horne@vislab.su.edu.au, info-performer@sgi.sgi.com Subject: Re: HCV colors to RGB colors (fwd) Status: O From guest Fri May 26 06:55:37 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA10926; Fri, 26 May 1995 06:53:08 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA10923; Fri, 26 May 1995 06:53:08 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10461; Fri, 26 May 95 06:53:06 -0700 Received: from ligsg10.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA23284; Fri, 26 May 1995 06:52:37 -0700 Received: by ligsg10.epfl.ch (Smail3.1.29.1 #28) id m0sEzoV-0000cQC; Fri, 26 May 95 15:52 MET DST From: "Fernando D. Mato Mira" Message-Id: <9505261552.ZM2958@lig.di.epfl.ch> Date: Fri, 26 May 1995 15:52:31 +0200 In-Reply-To: Delnaz Khorramabadi "ViewKit & Performer" (May 25, 3:20pm) References: <199505252220.PAA23438@shadow.eecs.berkeley.edu> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Delnaz Khorramabadi , info-performer@sgi.sgi.com Subject: Re: ViewKit & Performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 25, 3:20pm, Delnaz Khorramabadi wrote: > Has anyone tried ViewKit with Performer? Yes. No problem in single-processing mode. I still have to check how to do with multiprocessing (Performer not inited 'till a graphics window open). From guest Fri May 26 07:39:03 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id HAA11020; Fri, 26 May 1995 07:36:05 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id HAA11017; Fri, 26 May 1995 07:36:04 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11549; Fri, 26 May 95 07:36:03 -0700 Received: from vr3.engin.umich.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id HAA27140; Fri, 26 May 1995 07:35:49 -0700 Received: by vr3.engin.umich.edu (940816.SGI.8.6.9/930416.SGI.AUTO) id KAA01697; Fri, 26 May 1995 10:30:55 -0400 From: "Keith Fry" Message-Id: <9505261030.ZM1695@vr3.engin.umich.edu> Date: Fri, 26 May 1995 10:30:44 -0400 In-Reply-To: "Fernando D. Mato Mira" "Re: ViewKit & Performer" (May 26, 3:52pm) References: <199505252220.PAA23438@shadow.eecs.berkeley.edu> <9505261552.ZM2958@lig.di.epfl.ch> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Fernando D. Mato Mira" , Delnaz Khorramabadi , info-performer@sgi.sgi.com Subject: Re: ViewKit & Performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 26, 3:52pm, Fernando D. Mato Mira wrote: > Subject: Re: ViewKit & Performer > On May 25, 3:20pm, Delnaz Khorramabadi wrote: > > > Has anyone tried ViewKit with Performer? > Yes. No problem in single-processing mode. > I still have to check how to do with multiprocessing > (Performer not inited 'till a graphics window open). >-- End of excerpt from Fernando D. Mato Mira It also works in multiprocessing mode. Look at ftp://sgigate.sgi.com/pub/Performer/src/pfMotif.C /pub/Performer/selected-topics/pf-GLX I'm also using the VkGLX widget class in /usr/share/src/ViewKit/Applications/GLX --------------------------------------------------------------------- Keith Fry http: //www.engin.umich.edu/~keithfry University of Michigan email: keithfry@engin.umich.edu Virtual Reality Lab work phone: (313) 763-7798 From guest Fri May 26 08:19:24 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA11098; Fri, 26 May 1995 08:16:03 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA11095; Fri, 26 May 1995 08:16:02 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA12848; Fri, 26 May 95 08:16:01 -0700 Received: from dcscorp.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id IAA01375; Fri, 26 May 1995 08:15:42 -0700 Received: from DCS-Message_Server by dcscorp.com with Novell_GroupWise; Fri, 26 May 1995 11:13:55 -0400 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 26 May 1995 11:13:46 -0400 From: Tanner Lovelace To: info-performer@sgi.sgi.com Subject: Performer on older hardware Status: O Greetings, I'm trying to find out if Performer will run on 440 VGXT and Indigo2 Extreme machines. If you have any information about this, please e-mail me. Thanks you. Tanner Lovelace DCS Corporation Alexandria, VA From guest Fri May 26 08:49:41 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA11153; Fri, 26 May 1995 08:46:21 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA11150; Fri, 26 May 1995 08:46:20 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13879; Fri, 26 May 95 08:46:19 -0700 Received: from blackhole.cae.ca by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA04277; Fri, 26 May 1995 08:45:55 -0700 Received: (from uucp@localhost) by blackhole.cae.ca (8.6.7/8.6.6) id LAA19597 for ; Fri, 26 May 1995 11:47:59 -0400 Received: from hell.cae.ca(142.39.201.1) by bhole via smap (V1.3mjr) id sma019593; Fri May 26 11:47:51 1995 Received: by cae.ca (4.1/SMI-4.1) id AA25925; Fri, 26 May 95 11:46:08 EDT Date: Fri, 26 May 95 11:46:08 EDT From: rudy@cae.ca (Rudy Taraschi) Message-Id: <9505261546.AA25925@cae.ca> To: info-performer@sgi.sgi.com Subject: [Q] Overlay bitplanes Status: O Hi folks, I realize that this might not be the right place to post this question, but I'll give it a shot... I have a graphics application running in a window under IRIX 5.2. (Let's call it Process A). I would like a new, independent process (Let's call it Process B) to write into the overlay bitplanes of the window owned by Process A. Process B is a GL application written by myself. Ideally, Process A could be any application that does not already use the overlay bitplanes. Any help would be appreciated. Thanks. Rudy +--------------------------//------------------------------------------------+ | @@@@@@@ // Rudy Taraschi 'rudy@cae.ca' | | |~~~~~|_ // CAE Electronics Ltd | | |: , '| ) // Space Systems Engineering | | | . .|_) // P.O. Box 1800 St.Laurent | | [_____] // Quebec, Canada H4L 4X4 | +--------------------//------------------------------------------------------+ From guest Fri May 26 09:25:02 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA11262; Fri, 26 May 1995 09:18:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA11259; Fri, 26 May 1995 09:18:54 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15048; Fri, 26 May 95 09:18:46 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id JAA07328; Fri, 26 May 1995 09:17:48 -0700 Received: from barney.reading.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) id JAA11661; Fri, 26 May 1995 09:16:54 -0700 Received: by barney.reading.sgi.com (940816.SGI.8.6.9/930416.SGI) id RAA28143; Fri, 26 May 1995 17:11:38 +0100 From: "Rob Jenkins" Message-Id: <9505261711.ZM28141@barney.reading.sgi.com> Date: Fri, 26 May 1995 17:11:37 +0100 In-Reply-To: Tanner Lovelace "Performer on older hardware" (May 26, 11:13am) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Tanner Lovelace , info-performer@sgi.sgi.com Subject: Re: Performer on older hardware Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 26, 11:13am, Tanner Lovelace wrote: > Subject: Performer on older hardware > Greetings, > > I'm trying to find out if Performer will run on 440 VGXT and Indigo2 > Extreme machines. If you have any information about this, please e-mail > me. Thanks you. > > Tanner Lovelace > DCS Corporation > Alexandria, VA > > >-- End of excerpt from Tanner Lovelace I have Performer running on my Indigo2 Extreme, I haven't run on 440 VGXT myself but I'm sure it will go - I'm guess someone else out there can confirm this. Cheers Rob -- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj@reading.sgi.com, From guest Fri May 26 12:58:41 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA11828; Fri, 26 May 1995 12:55:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA11825; Fri, 26 May 1995 12:55:35 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA24881; Fri, 26 May 95 12:55:33 -0700 Received: from server1.ctc.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA04973; Fri, 26 May 1995 12:55:11 -0700 Received: by server1.ctc.com (5.65/DEC-Ultrix/4.3) id AA14453; Fri, 26 May 1995 13:23:44 -0400 Received: from server1.ctc.com by sgi10.ctc.com via SMTP (931110.SGI/930416.SGI.AUTO) for @server1.ctc.com:info-performer@sgi.com id AA15135; Fri, 26 May 95 13:23:43 -0400 Received: by server1.ctc.com (5.65/DEC-Ultrix/4.3) id AA14449; Fri, 26 May 1995 13:23:40 -0400 Received: by sgi115.ctc.com (931110.SGI/930416.SGI.AUTO) for @sgi10.ctc.com:info-performer@sgi.com id AA19570; Fri, 26 May 95 13:23:06 -0400 From: "Fran Dachille" Message-Id: <9505261323.ZM19568@sgi115.ctc.com> Date: Fri, 26 May 1995 13:22:59 -0400 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Hardware inventory, stereo Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi, I wonder if anyone has any experience with stereo mode on RE's? I have a stereo mode application which works fine on Indy's. The command to turn on stereo on the RE is different from the Indy's and so is the method to turn it off. I'm wondering if there direct way to test for the rendering hardware other than hinv -c graphics | {grep_for_graphics_hardware}. thanks, frank -- Frank Dachille fran@ctc.com Concurrent Technologies Corp. 1450 Scalp Avenue Phone: (814) 269-2650 Johnstown, PA 15904 Fax: (814) 269-2402 From guest Fri May 26 12:05:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA11500; Fri, 26 May 1995 11:52:46 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA11497; Fri, 26 May 1995 11:52:45 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22133; Fri, 26 May 95 11:52:43 -0700 Received: from mimbres.cs.unm.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA26682; Fri, 26 May 1995 11:52:14 -0700 Received: from coral.cs.unm.edu by mimbres.cs.unm.edu (5.65/033093) with SMTP id ; Fri, 26 May 95 11:54:18 -0600 Date: Fri, 26 May 1995 11:54:17 -0600 (MDT) From: Jim Pinkerton Subject: unsubscribe To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O please unsubscribe From guest Fri May 26 11:48:06 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA11465; Fri, 26 May 1995 11:40:52 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA11462; Fri, 26 May 1995 11:40:51 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21536; Fri, 26 May 95 11:40:50 -0700 Received: from ligsg10.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA24804; Fri, 26 May 1995 11:40:29 -0700 Received: by ligsg10.epfl.ch (Smail3.1.29.1 #28) id m0sF3ay-0001NKC; Fri, 26 May 95 19:54 MET DST From: "Fernando D. Mato Mira" Message-Id: <9505261954.ZM4592@lig.di.epfl.ch> Date: Fri, 26 May 1995 19:54:47 +0200 In-Reply-To: "Keith Fry" "Re: ViewKit & Performer" (May 26, 10:30am) References: <199505252220.PAA23438@shadow.eecs.berkeley.edu> <9505261552.ZM2958@lig.di.epfl.ch> <9505261030.ZM1695@vr3.engin.umich.edu> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Keith Fry" , Delnaz Khorramabadi , info-performer@sgi.sgi.com Subject: Re: ViewKit & Performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 26, 10:30am, Keith Fry wrote: > I'm also using the VkGLX widget class in > /usr/share/src/ViewKit/Applications/GLX OK. I've `upgraded' to VkGLX (but I'm not testing multiproc until 2.0 is there). Now, how do I get called when a window is iconified/deiconified? (tried StructureNotify some time ago without luck, and dunno how to discern when a ClientMessage event is indeed from the window manager indicating this). Thanks in advance, From guest Thu May 25 22:17:52 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA00692; Thu, 25 May 1995 22:14:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA00689; Thu, 25 May 1995 22:14:56 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01730; Thu, 25 May 95 22:14:55 -0700 Received: from redgate.vislab.su.edu.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id WAA23444; Thu, 25 May 1995 22:14:51 -0700 Received: from moffatt.vislab.su.edu.au by redgate.vislab.su.edu.au via ESMTP (950215.SGI.8.6.10/940406.SGI) for id PAA13110; Fri, 26 May 1995 15:08:08 +1000 Received: by moffatt.vislab.su.edu.au (950215.SGI.8.6.10/940406.SGI) for info-performer@sgi.com id PAA21047; Fri, 26 May 1995 15:08:07 +1000 From: "Ben Simons" Message-Id: <9505261508.ZM21045@moffatt.vislab.su.edu.au> Date: Fri, 26 May 1995 15:08:06 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Answer: cvd and performer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O ha! I have an answer ("work-around") to my question: [ Could someone at SGI please forward this to the CaseVision devel. people? ] On May 15, 1:55pm, Ben Simons wrote: > Subject: Anyone using cvd with performer? > Is there anyone using the CaseVision Workshop debugger "cvd" > with performer? > > I am having trouble using the Structure Browser on structures > that have been created via pfMalloc. In particular, I can't > dereference the pointer returned; I get the error: > > ``variable is used before it is set'' > ... Thanks to John A. Collier On May 25, 7:23am, John A. Collier wrote: > Subject: Re: Anyone using cvd with performer? > I have had to run as root to access pfMalloc'ed structures. When I first > installed cvd I didn't have to. Something has changed and now I do. > > I haven't had time to worry. I just su and get on with it. > > Good Luck, > John He's right; it works if you're root. likewise on the "time to worry" bit. keep'n truck'n! :-) regards, ben. -- _______________________________________________________ Ben Simons Physics Building, A28, VisLab Systems Manager Sydney University. NSW. Phone +61-2-351-3005 AUSTRALIA. 2006. From guest Fri May 26 16:15:08 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA12666; Fri, 26 May 1995 16:08:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA12663; Fri, 26 May 1995 16:08:05 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05437; Fri, 26 May 95 16:08:03 -0700 Received: from D15VS178A.SPACE.SwRI.EDU by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id QAA13623; Fri, 26 May 1995 16:08:01 -0700 Received: by D15VS178A.SPACE.SwRI.EDU; Fri, 26 May 95 16:56:28 CDT Date: Fri, 26 May 95 16:53:39 CDT Message-Id: X-Priority: 3 (Normal) From: (Richard P. Weyrauch, Sr. Research Engineer, b189, x5776) To: info-performer@sgi.sgi.com, TLOVELAC@dcscorp.com Subject: re: Re: Performer on older hardware X-Incognito-Sn: 1000 X-Incognito-Format: VERSION=2.00 EA-4 ENCRYPTED=NO Status: O We run Performer 1.2 on a Skywriter VGXT and a very old 240VGX without any problems. -rick Rick Weyrauch rweyrauch@swri.edu Southwest Research Institute (210)522-5776 San Antonio TX From guest Fri May 26 16:01:52 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA12623; Fri, 26 May 1995 15:55:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA12620; Fri, 26 May 1995 15:55:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04688; Fri, 26 May 95 15:55:04 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id PAA10361; Fri, 26 May 1995 15:54:54 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id OAA14652; Fri, 26 May 1995 14:56:39 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:TLOVELAC@dcscorp.com id AA01661; Fri, 26 May 95 14:56:35 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA11085; Fri, 26 May 1995 14:56:35 -0700 Message-Id: <199505262156.OAA11085@surreal.asd.sgi.com> To: Tanner Lovelace Cc: info-performer@sgi.sgi.com Subject: Re: Performer on older hardware In-Reply-To: Your message of "Fri, 26 May 95 11:13:46 EDT." Date: Fri, 26 May 95 14:56:34 -0700 From: Jim Helman Status: O Performer runs across the entire SGI product line, VGXT and Extreme included. Note that some older machines, e.g. Personal Iris, may lack some features, e.g. video sync clock or high res time, that important for fixed frame rate operation. Other than that, there shouldn't be any problems. However, Performer 2.0 will only run on 5.X (X >= 3) or 6.X (X >= 1). -jim From guest Sat May 27 11:53:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA14346; Sat, 27 May 1995 11:50:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA14343; Sat, 27 May 1995 11:50:43 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10919; Sat, 27 May 95 11:50:42 -0700 Received: from goya.eunet.es by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA02644; Sat, 27 May 1995 11:50:38 -0700 Received: (uucp@localhost) by goya.eunet.es (8.6.10/13.12) id UAA28439 for info-performer@sgi.com; Sat, 27 May 1995 20:40:24 +0200 Received: by INDY3.comarts.es (940816.SGI.8.6.9/5.3) id TAA04010 for info-performer@sgi.com; Sat, 27 May 1995 19:38:01 -0700 From: "Nacho Sanz-Pastor. Computer Arts + Developments" Message-Id: <9505271938.ZM4008@comarts.es> Date: Sat, 27 May 1995 19:38:00 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Open GL TexEnvs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hi there ! This is not strictly a Performer question, but we feel is closely related to it and uncovers a whole issue that seems worrying to us: Is there a way to use with Open GL the tevdef tokens for component selection ( I_GETS_A, R_GETS_B and all that ) ? Maybe I am wrong, but I have been unable to find a way to do that with glTexEnv[if], and even in the gl.h header there seems not be provision for that. We make extensive use of those calls in node callbacks. It seems many not very well known modes and tricks that were extremely useful in good'ol GL are not going to be present in the new API. Is this true ? Thanks in advance. -- ----------------------------------------------------- mb$$m Nacho Sanz-Pastor b$" $"$""$$b, Email: nacho@comarts.es |$P $P Pm `$Pb ------------------------------------------------------ $| $ P, `|P, Computer Arts & Developments Phone: ++ 34 1 3572751 "$ P P `b$ Anita Vindel,10 ++ 34 1 3572752 "PPPP | ,P Madrid 28023 SPAIN Fax : ++ 34 1 3070339 $bmm1" -------------------------------------------------------------------------------- Computer Arts & Developments Visual Simulation Group An asteroid has crashed on Earth, and the Dinosaurs are close to being extinct -------------------------------------------------------------------------------- From guest Sun May 28 16:08:12 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA16270; Sun, 28 May 1995 16:05:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA16267; Sun, 28 May 1995 16:05:51 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18849; Sun, 28 May 95 16:05:49 -0700 Received: from ix4.ix.netcom.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id QAA27390; Sun, 28 May 1995 16:05:48 -0700 Received: from by ix4.ix.netcom.com (8.6.12/SMI-4.1/Netcom) id QAA12783; Sun, 28 May 1995 16:04:54 -0700 Date: Sun, 28 May 1995 16:04:54 -0700 Message-Id: <199505282304.QAA12783@ix4.ix.netcom.com> From: blastarr@ix.netcom.com (Kent Miller) Subject: Switching between two performer apps To: info-performer@sgi.sgi.com Status: O We are hoping to run two Performer apps simultaneously, each with its processes locked to separate CPUs (we have 12), and switch control of the pipes (3) between them (in a sense, to be able to "pop" one forward and "push" the other back). Each app represents one of two "modes" that a task can be performed in, and only one needs to be active at a time, but we want the user to be able to switch freely between them. One of the apps is a straightforward 3D environment using only Performer; the other is a 2D ImageVision app, which uses Performer for stereo frame sync (for use with an HMD) and pfDataPools for interaction with the head tracker process. Right now we don't run them at the same time. What's the best method for switching between them? Should we try to integrate the two into a single app? Is there a way to tell one to give up the pipes and flag the other to take over? Thanks in advance for any advice. From guest Mon May 29 05:38:47 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id FAA17166; Mon, 29 May 1995 05:36:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id FAA17163; Mon, 29 May 1995 05:36:11 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11999; Mon, 29 May 95 05:36:10 -0700 Received: from relay.iunet.it by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id FAA00642; Mon, 29 May 1995 05:35:11 -0700 Received: from hpdtmt2 ([193.76.230.93]) by relay.iunet.it with SMTP id AA13539 (5.65c8/IDA-1.4.4 for ); Mon, 29 May 1995 14:39:50 +0200 Message-Id: <199505291239.AA13539@relay.iunet.it> Received: by hpdtmt2 (16.6/16.2) id AA21222; Mon, 29 May 95 14:22:55 +0200 From: Marco Crocetta Subject: NURBS To: info-performer@sgi.sgi.com Date: Mon, 29 May 95 14:22:54 METDST Mailer: Elm [revision: 66.25] Status: O Hi people!, In my application I'm rendering a NURBS surface to simulate the sea surface motion. The NURBS is rendered in the pre-draw callback using the GL calls nurbssurface(....). The waves motion is implemented just changing the control point coordinates (stored in the Shared arena) frame by frame by the APP process. Everthing works quite fine the only thing is that NURBS seems to be quite heavy because they badly increase the drawing time. Now I have a doubt that I can explain with the following question: QUESTION: are NURBS so heavy? Or something went wrong because the control points are not ring-buffered??. In other words: if the draw process uses some data arrays that are modified frame by frame by the APP process do I REALLY need to ring buffer this data, which problems may arise not buffering data between the DRAW and APP processes? Thanks in Advance --------------------------- Marco Crocetta DATAMAT SpA, Rome e-mail: onyx@datamat.it --------------------------- From guest Sun May 28 18:45:13 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA16450; Sun, 28 May 1995 18:42:36 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA16446; Sun, 28 May 1995 18:42:30 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22790; Sun, 28 May 95 18:42:29 -0700 Received: from munnari.oz.au by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id SAA03841; Sun, 28 May 1995 18:42:23 -0700 Received: from titanic.iconix.oz (via mtiame) by munnari.oz.au with SunIII (5.83--+1.3.1+0.50) id AA09345; Mon, 29 May 1995 11:42:06 +1000 (from glf%imta.com.au@titanic.iconix.oz.au) Message-Id: <9505290142.9345@munnari.oz.au> Received: from curtis.imta.com.au by titanic.imta.com.au with SMTP (920330.SGI) id AA10428; Mon, 29 May 95 11:35:24 +1000 To: info-performer@sgi.sgi.com Cc: sl@imta.com.au, anp@imta.com.au Subject: vega Date: Mon, 29 May 1995 11:35:20 EST From: Giuseppe Fiusco Status: O A simple question that will hopefully obtain a wide range of responses. We are currently investigating the possibility of using the 'Vega' product from Paradigm. We already have some basic knowledge of performer. The question is; What are the value added features we get by using vega that we dont get with performer? Joe ............................................................................... Giuseppe Fiusco Email: glf@imta.com.au, ...uunet!imta.com.au!glf Analyst Snail: In-Mar-Tech Australia Pty Ltd Phone: +61 3 9696-4009 10 Boundary Street Fax: +61 3 9696-7449 South Melbourne, Vic, 3205, Australia ............................................................................... And now for a word from our sponsors: The opinions expressed above are my own and do not necessarily reflect those of In-Mar-Tech. ------------------------------------------------------------------------------- And now for a word from our sponsors: The opinions expressed above are my own and do not necessarily reflect those of In-Mar-Tech. From guest Mon May 29 13:16:38 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA17751; Mon, 29 May 1995 13:14:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA17748; Mon, 29 May 1995 13:14:32 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA27068; Mon, 29 May 95 13:14:30 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id NAA25931; Mon, 29 May 1995 13:13:48 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id NAA15578; Mon, 29 May 1995 13:13:46 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:onyx@datamat.it id AA27046; Mon, 29 May 95 13:13:42 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id NAA01414; Mon, 29 May 1995 13:13:42 -0700 Message-Id: <199505292013.NAA01414@surreal.asd.sgi.com> To: Marco Crocetta Cc: info-performer@sgi.sgi.com Subject: Re: NURBS In-Reply-To: Your message of "Mon, 29 May 95 14:22:54 +0700." <199505291239.AA13539@relay.iunet.it> Date: Mon, 29 May 95 13:13:42 -0700 From: Jim Helman Status: O GL NURBS are heavy, man. Since the ocean probably doesn't need a whole lot of trimming, you might be able to do pretty well building a pfGeoSet of tristrips and setting the vertex positions based on a simpler surface primitive which you evaluate on the host, like Bezier patches. In order to avoid slowing down the DRAW with this processing, you probably want to put it in the APP, however this will require multibuffering the geometry yourself under a pfSwitch node so that you don't cause tearing by moving a vertex in the APP while it is being drawn in the DRAW. Note that OpenGL (which you'll be able to use with Performer 2.0) has a notion of maps and evaluators which might be useful here. Also, we may do some surface primitives in a future version of Performer, so let us know what's useful. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon May 29 06:40:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA17245; Mon, 29 May 1995 06:38:22 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA17242; Mon, 29 May 1995 06:38:21 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13443; Mon, 29 May 95 06:38:20 -0700 Received: from redgate.vislab.su.edu.au by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA03059; Mon, 29 May 1995 06:38:16 -0700 Received: from moffatt.vislab.su.edu.au by redgate.vislab.su.edu.au via ESMTP (950215.SGI.8.6.10/940406.SGI) id XAA00627; Mon, 29 May 1995 23:38:04 +1000 Received: by moffatt.vislab.su.edu.au (950215.SGI.8.6.10/940406.SGI) id XAA23330; Mon, 29 May 1995 23:38:03 +1000 From: "Ben Simons" Message-Id: <9505292338.ZM23328@moffatt.vislab.su.edu.au> Date: Mon, 29 May 1995 23:38:02 -0400 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Fixed: Memory Trashing! Cc: staff@moffatt.vislab.su.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Update: Yahoo! I found the memory trashing that was causing my innocent pfMalloc() call to die. Yep, I was over-running an array, pfMalloc'ed earlier. I found it by simplifying as much as possible, and then tracking the sequence of alloc's and free's. It began to die on a free(x) (ok, i mean pfDelete). So I thoroughly looked at all references to the var that was pfMalloc'ed before 'x', and viola! An off-by-one bug in a for-loop termination test. Now... where was I up to before this happened??! ;-) thanks to the few who provided assistance. ben. PS: I am running cvd (CaseVision Workshop) as root now, and getting along ok... -- _______________________________________________________ Ben Simons Physics Building, A28, VisLab Systems Manager Sydney University. NSW. Phone +61-2-351-3005 AUSTRALIA. 2006. From guest Tue May 30 02:27:42 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA19389; Tue, 30 May 1995 02:24:43 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA19386; Tue, 30 May 1995 02:24:42 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20973; Tue, 30 May 95 02:24:41 -0700 Received: from ligsg10.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id CAA16659; Tue, 30 May 1995 02:22:29 -0700 Received: by ligsg10.epfl.ch (Smail3.1.29.1 #28) id m0sGNVE-0001NIC; Tue, 30 May 95 11:22 MET DST From: "Fernando D. Mato Mira" Message-Id: <9505301122.ZM12294@lig.di.epfl.ch> Date: Tue, 30 May 1995 11:22:20 +0200 In-Reply-To: Marco Crocetta "NURBS again" (May 30, 9:27am) References: <199505300744.AA11713@relay.iunet.it> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: NURBS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O > Also, we may do some surface primitives in a > future version of Performer, so let us know what's useful. What about glsphere primtype for geosets? That should be easy enough to have it now.. From guest Tue May 30 00:44:44 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id AAA19283; Tue, 30 May 1995 00:40:41 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id AAA19280; Tue, 30 May 1995 00:40:40 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18301; Tue, 30 May 95 00:40:39 -0700 Received: from relay.iunet.it by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id AAA11621; Tue, 30 May 1995 00:40:25 -0700 Received: from hpdtmt2 ([193.76.230.93]) by relay.iunet.it with SMTP id AA11713 (5.65c8/IDA-1.4.4 for ); Tue, 30 May 1995 09:44:44 +0200 Message-Id: <199505300744.AA11713@relay.iunet.it> Received: by hpdtmt2 (16.6/16.2) id AA22125; Tue, 30 May 95 09:27:49 +0200 From: Marco Crocetta Subject: NURBS again To: info-performer@sgi.sgi.com Date: Tue, 30 May 95 9:27:48 METDST Mailer: Elm [revision: 66.25] Status: O > Since the ocean probably doesn't need a whole lot of > trimming, you might be able to do pretty well building a > pfGeoSet of tristrips and setting the vertex positions based > on a simpler surface primitive which you evaluate on the > host, like Bezier patches. In order to avoid slowing down > the DRAW with this processing, you probably want to put it in > the APP, however this will require multibuffering the > geometry yourself under a pfSwitch node so that you don't > cause tearing by moving a vertex in the APP while it is being > drawn in the DRAW. Thanks very much. > Also, we may do some surface primitives in a > future version of Performer, so let us know what's useful. It's the problem of how to build a good simulation of dynamic waves as seen from a very low height from the sea surface. Using triangles (remember the old lake demo) I have the problem that the waves are not "smooth" and the effect of light above the surface (i.e at sunset) when the waves are moving is quite bad. Yes, I know we have to find the right tradeoff between a realistic scene and good performance ... It could be nice to have in a future release of Performer some utilities or primitives the could help to buld up a good sea simulation (as ptu helps for terrain and pfESky helps for Sky modelling). Thank you very much -------------------------- Marco Crocetta DATAMAT SpA, Rome e-mail: onyx@datamat.it -------------------------- From guest Tue May 30 03:43:58 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA19486; Tue, 30 May 1995 03:38:40 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA19483; Tue, 30 May 1995 03:38:39 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22736; Tue, 30 May 95 03:38:37 -0700 Received: from pigeon.cf.ac.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA19667; Tue, 30 May 1995 03:38:31 -0700 Received: from thor.cf.ac.uk by pigeon.cf.ac.uk with SMTP (PP) id <06600-0@pigeon.cf.ac.uk>; Tue, 30 May 1995 11:37:05 +0100 Date: Tue, 30 May 1995 11:37:17 +0100 (BST) From: ROY RUDDLE Reply-To: Ruddle@cardiff.ac.uk To: info-performer@sgi.sgi.com Subject: FOV Bugs? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Following on from the pf...Frustrum problems I uncovered a few weeks back, would anyone like to comment about this problem. It's possible I'm being an idiot, but I don't think so (!). s/w below sets up 3 views on one monitor. Initial settings are 35 deg (left + right), 90 deg (centre). Vertical FOV is 60 deg for all. This should provide a continuous horiz FOV of 160 deg. I realise that the gradient of displayed polygons (in XY screen space) will be discontinuous across the viewport boundaries, but I believe the actual height (screen Y) of polygon's should be the same on both sides of viewport boundaries, because the vertical FOV is identical. ... but it isn't. Why? If the viewport horizontal FOV's are all the same (commented out line) then there is no problem. Is this another Performer bug? ---------------------------------- model file: tmp.sv ---------------------------------- material 1 1.0 1.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 1 0 0 0 texture 1 Texture/plain_wood.rgb texture 2 Texture/presentation.rgb material 1 texture 1 backface off tmeshn 4 0 -2 1 0 0 1 0 2 1 0 0 1 0 -2 1.5 0 0 1 0 2 1.5 0 0 1 backface off tmeshn 4 0 -2 1.6 0 0 1 0 2 1.6 0 0 1 0 -2 2.0 0 0 1 0 2 2.0 0 0 1 backface off tmeshn 4 0 -2 2.1 0 0 1 0 2 2.1 0 0 1 0 -2 2.5 0 0 1 0 2 2.5 0 0 1 ------------------------------------- C++ code: Just one file. move mouse to rotate view left + right ------------------------------------- #include #include #include #include #include #include #include #include #include #include #include static void OpenPipeline (pfPipe *p); static void DrawChannel (pfChannel *channel, void *data); static pfLightSource *ls1, *ls2, *ls3; int main() { pfInit(); pfConfig(); pfScene *scene; scene = pfNewScene(); pfNode *node = LoadFile( "tmp.sv", NULL ); pfAddChild( scene, node ); pfPipe *pipe; pipe = pfGetPipe(0); pfInitPipe(pipe, OpenPipeline); float near, far, v_fov; near = 0.1; far = 8000.0; v_fov =0.0; // // l/r/m channels // float hfov1 = 90.0f, hfov2 = 35.0f; // // Set both hfov1 and hfov2 to be equal and everything works OK // //hfov1 = hfov2 = 55.0; v_fov = 60.0f; pfChannel *left = pfNewChan(pfGetPipe(0)); float t = pfTan( v_fov*0.5f ); float vpl = 0.15, vpr = 0.85, vpb = 0.0f, vpt = 1.0f; const float GAP = 0.000f; pfChanViewport( left, 0.0f, vpl-GAP, vpb, vpt ); pfChanFOV( left, hfov2, v_fov ); float gh, gv; pfGetChanFOV( left, &gh, &gv ); cout << gh << " " << gv << endl; pfChannel *middle = pfNewChan(pfGetPipe(0)); pfChanViewport( middle, vpl, vpr, vpb, vpt ); pfChanFOV( middle, hfov1, v_fov ); pfGetChanFOV( middle, &gh, &gv ); cout << gh << " " << gv << endl; pfChannel *right = pfNewChan(pfGetPipe(0)); pfChanViewport( right, vpr+GAP, 1.0f, vpb, vpt ); pfChanFOV( right, hfov2, v_fov ); pfChanScene( middle, scene ); pfChanScene( left, scene ); pfChanScene( right, scene ); ls1 = pfNewLSource(); pfLightColor( ls1, 1.0f, 1.0f, 1.0f ); pfLightPos( ls1, 0.0f, 0.0f, -1.0f, 0.0f ); pfAddChild(scene, ls1 ); ls2 = pfNewLSource(); pfLightColor( ls2, 0.6f, 0.6f, 0.6f ); pfLightPos( ls2, -2.0f, -1.0f, 0.1f, 0.0f ); pfAddChild(scene, ls2 ); pfLightOn( ls2 ); ls3 = pfNewLSource(); pfLightColor( ls3, 0.3f, 0.3f, 0.3f ); //pfLightPos( ls3, 2.0f, 1.0f, 0.1f, 0.0f ); //pfLightPos( ls3, 1.0f, 2.0f, 0.1f, 0.0f ); pfLightPos( ls3, 1.0f, 1.5f, 0.1f, 0.0f ); pfAddChild(scene, ls3 ); pfLightOn( ls3 ); pfInitClock(0.0f); pfCullFace( PFCF_BACK ); int exit_flag = 0; pfVec3 xyz = {2.0f, 0.0f, 1.5f}; pfVec3 hpr = {90.0f, 0.0f, 0.0f}; while( exit_flag < 1000 ) { exit_flag++; pfSync(); float xx = (float( getvaluator(MOUSEX) ) - 1280.0*0.5) / (1280.0*0.5); pfSetVec3( hpr, 90.0 - xx*hfov1, 0.0f, 0.0f ); pfChanView( middle, xyz, hpr ); pfSetVec3( hpr, 90.0 - xx*hfov1 + 0.5*(hfov1 + hfov2), 0.0f, 0.0f ); pfChanView( left, xyz, hpr ); pfSetVec3( hpr, 90.0 - xx*hfov1 - 0.5*(hfov1 + hfov2), 0.0f, 0.0f ); pfChanView( right, xyz, hpr ); pfFrame(); } pfExit(); return 0; } static void OpenPipeline (pfPipe *p) { foreground(); prefposition(0, 1280, 0, 1024); noborder(); winopen("IRIS Performer"); pfInitGfx(p); pfApplyMtl(pfNewMtl( NULL )); pfEnable( PFEN_LIGHTING ); pfLightModel *lmodel = pfNewLModel( NULL ); pfLModelAmbient( lmodel, 0.4f, 0.4f, 0.4f ); pfApplyLModel( lmodel ); pfTexEnv *tev = pfNewTEnv( 0 ); pfTEnvMode( tev, PFTE_MODULATE ); pfApplyTEnv( tev ); } static void DrawChannel (pfChannel *channel, void *data) { pfClearChan(channel); pfDraw(); } ------------------------------------------------------------------------ Roy Ruddle, Principal Researcher | School of Psychology Tel: 01222 874523 (direct) | University of Wales College of Cardiff 01222 874007 (messages) | PO Box 901 Fax: 01222 874858 | Cardiff CF1 3YG Email: Ruddle@CARDIFF.AC.UK | UK From guest Tue May 30 03:47:07 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA19496; Tue, 30 May 1995 03:43:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA19493; Tue, 30 May 1995 03:43:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22815; Tue, 30 May 95 03:43:04 -0700 Received: from shallow.division.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA19776; Tue, 30 May 1995 03:42:48 -0700 Received: from caliban (caliban.division.co.uk) by shallow.division.co.uk with SMTP id AA11650 (5.65c/IDA-1.4.4 for info-performer@sgi.com); Tue, 30 May 1995 10:42:34 GMT Received: by caliban (931110.SGI/921111.SGI) for @shallow.division.co.uk:info-performer@sgi.com id AA09317; Tue, 30 May 95 11:42:30 +0100 From: "Angus Dorbie" Message-Id: <9505301142.ZM9315@caliban.division.co.uk> Date: Tue, 30 May 1995 11:42:29 +0100 In-Reply-To: "Fernando D. Mato Mira" "Re: NURBS" (May 30, 11:22am) References: <199505300744.AA11713@relay.iunet.it> <9505301122.ZM12294@lig.di.epfl.ch> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Fernando D. Mato Mira" Subject: Re: NURBS Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > What about glsphere primtype for geosets? > That should be easy enough to have it now.. Here's some code to generate geosets with a number of spheres with different origins & radii. Each sphere is generated as a set of nonindexed tristrips. The polygon mesh isn't ideal but it's what was required at the time. The dicing values can be changed and data is cached for the last dicing used. The structure g holds an array of sphere coordinates & radii in g->vertdata + possible colour information. The number of spheres is held in g->numvert and the size of information for an individual sphere is held in g->vertsize g->*_inc holds the relative offset of each piece of information in a vertex and depends upon how you build your array of spheres. g->vertype indicates what information is stored for each sphere. g->Long & g->Lat hold the longitudinal & latitudinal dicing values. g->Pgeoset is the performer geoset where the spheres are being created. g->transparent is TRUE when transparency is implied by colour information for the spheres. static void _MakeSpheres(_gset_holder *g) { int i, j, pos, post, x; float angleLat, angleLong, incLat, incLong, LatSin, LatCos, LongSin, LongCos; float _xp, _yp, _zp, _rad; /* triangle connections */ int first_sphere; static pfVec3 *Template = NULL; static int Last_Long = 0; static int Last_Lat = 0; /* dicing values rounded to two */ int LONG = g->Long; int LAT = g->Lat; if(LONG < 3) /* set a reasonable minimum */ LONG = 3; if(LAT < 2) /* set a reasonable minimum */ LAT = 2; if(LONG != Last_Long || LAT != Last_Lat) first_sphere = TRUE; else first_sphere = FALSE; Last_Long = LONG; Last_Lat = LAT; if(first_sphere) { if(Template) pfFree(Template); first_sphere = FALSE; Template = (pfVec3 *)pfMalloc(sizeof(pfVec3)*LONG*LAT*2, NULL); /* generate surface normals used by all spheres */ /* end points */ Template[0][0] = 0.0f; Template[0][1] = 1.0f; Template[0][2] = 0.0f; Template[LONG*(LAT-1)+1][0] = 0.0f; Template[LONG*(LAT-1)+1][1] = -1.0f; Template[LONG*(LAT-1)+1][2] = 0.0f; angleLat = 90.0f; incLat = 180.0f / LAT; incLong = 360.0f / LONG; for(i=0, angleLat = 90.0f - incLat; i < (LAT-1); i++, angleLat -= incLat) { pfSinCos(angleLat, &LatSin, &LatCos); for(j=0, angleLong = 0.0f; j < LONG; j++, angleLong += incLong) { pos = i*LONG+j+1; pfSinCos(angleLong, &LongSin, &LongCos); Template[pos][0] = LongSin * LatCos; Template[pos][1] = LatSin; Template[pos][2] = LongCos * LatCos; } } } /* allocate space for saved sphere coordinates */ g->sphvert = (float *)pfMalloc(sizeof(float)*g->numvert*4, NULL); /* allocate space for normals */ g->Pnorms = (pfVec3 *)pfMalloc(sizeof(pfVec3)*g->numvert*LONG*LAT*2, pfGetSharedArena()); /* space for the sphere surface coordinates */ g->Pcoords = (pfVec3 *)pfMalloc(sizeof(pfVec3)*g->numvert*LONG*LAT*2, pfGetSharedArena()); /* space for the tristrip lengths */ g->Plengths = (long *)pfMalloc(sizeof(long)*g->numvert*LONG, pfGetSharedArena()); /* do colours */ if(g->vertype & dpl_vertex_rgba || g->vertype & dpl_vertex_luminance) g->Pcolours = (pfVec4 *)pfMalloc(sizeof(pfVec4)*g->numvert*LONG, pfGetSharedArena()); /* copy coordinate and normal information for each sphere */ /* normals don't change, coordinate information is scaled & translated */ /* start position of sphere vertices & length position counters */ pos = post = 0; for(x=0; x < g->numvert; x++) /* for each sphere */ { /* read relevant sphere information */ _xp = *(g->vertdata + g->vertsize*x + g->coord_inc); _yp = *(g->vertdata + g->vertsize*x + 1 + g->coord_inc); _zp = *(g->vertdata + g->vertsize*x + 2 + g->coord_inc); if(g->vertype & dpl_vertex_radius) _rad = *(g->vertdata + g->vertsize*x + g->rad_inc); else _rad = 1.0f; /* store sphere sizes & positions */ *(g->sphvert + (x*4)) = _xp; *(g->sphvert + (x*4 + 1)) = _yp; *(g->sphvert + (x*4 + 2)) = _zp; *(g->sphvert + (x*4 + 3)) = _rad; /* tristrip in segments */ for(j=0; j < LONG; j++) { /* add one tristrip (nonindexed) */ g->Pcoords[pos][0] = _xp + _rad * Template[0][0]; g->Pcoords[pos][1] = _yp + _rad * Template[0][1]; g->Pcoords[pos][2] = _zp + _rad * Template[0][2]; g->Pnorms[pos][0] = Template[0][0]; g->Pnorms[pos][1] = Template[0][1]; g->Pnorms[pos][2] = Template[0][2]; pos ++; for(i=0; i < (LAT-1); i++) { g->Pcoords[pos][0] = _xp + _rad * Template[i*LONG+j+1][0]; g->Pcoords[pos][1] = _yp + _rad * Template[i*LONG+j+1][1]; g->Pcoords[pos][2] = _zp + _rad * Template[i*LONG+j+1][2]; g->Pnorms[pos][0] = Template[i*LONG+j+1][0]; g->Pnorms[pos][1] = Template[i*LONG+j+1][1]; g->Pnorms[pos][2] = Template[i*LONG+j+1][2]; pos ++; if(j == LONG-1) { g->Pcoords[pos][0] = _xp + _rad * Template[i*LONG+1][0]; g->Pcoords[pos][1] = _yp + _rad * Template[i*LONG+1][1]; g->Pcoords[pos][2] = _zp + _rad * Template[i*LONG+1][2]; g->Pnorms[pos][0] = Template[i*LONG+1][0]; g->Pnorms[pos][1] = Template[i*LONG+1][1]; g->Pnorms[pos][2] = Template[i*LONG+1][2]; } else { g->Pcoords[pos][0] = _xp + _rad * Template[i*LONG+j+2][0]; g->Pcoords[pos][1] = _yp + _rad * Template[i*LONG+j+2][1]; g->Pcoords[pos][2] = _zp + _rad * Template[i*LONG+j+2][2]; g->Pnorms[pos][0] = Template[i*LONG+j+2][0]; g->Pnorms[pos][1] = Template[i*LONG+j+2][1]; g->Pnorms[pos][2] = Template[i*LONG+j+2][2]; } pos ++; } g->Pcoords[pos][0] = _xp + _rad * Template[LONG*(LAT-1)+1][0]; g->Pcoords[pos][1] = _yp + _rad * Template[LONG*(LAT-1)+1][1]; g->Pcoords[pos][2] = _zp + _rad * Template[LONG*(LAT-1)+1][2]; g->Pnorms[pos][0] = Template[LONG*(LAT-1)+1][0]; g->Pnorms[pos][1] = Template[LONG*(LAT-1)+1][1]; g->Pnorms[pos][2] = Template[LONG*(LAT-1)+1][2]; pos ++; /* do colours */ if(g->vertype & dpl_vertex_rgba) { g->Pcolours[post][0] = *(g->vertdata+ g->vertsize*x + g->rgba_inc); g->Pcolours[post][1] = *(g->vertdata+ g->vertsize*x + 1 + g->rgba_inc); g->Pcolours[post][2] = *(g->vertdata+ g->vertsize*x + 2 + g->rgba_inc); g->Pcolours[post][3] = *(g->vertdata+ g->vertsize*x +3+ g->rgba_inc); if( .997 > g->Pcolours[post][3] ) g->transparent = TRUE; } else if(g->vertype & dpl_vertex_luminance) { g->Pcolours[post][0] = g->Pcolours[post][1] = g->Pcolours[post][2] = *(g->vertdata+ g->vertsize*x + g->lum_inc); g->Pcolours[post][3] = *(g->vertdata+ g->vertsize*x +1+ g->lum_inc); if( .997 > g->Pcolours[post][3] ) g->transparent = TRUE; } g->Plengths[post] = LAT*2; post++; } } /* compose sphere of triangular strips */ pfGSetPrimType(g->Pgeoset, PFGS_TRISTRIPS); /* do colours (requires appropriate use of materials) */ if(g->vertype & dpl_vertex_rgba || g->vertype & dpl_vertex_luminance) pfGSetAttr(g->Pgeoset, PFGS_COLOR4, PFGS_PER_PRIM, g->Pcolours, NULL); /* primitive lengths for each triangle strip */ pfGSetPrimLengths(g->Pgeoset, g->Plengths); pfGSetAttr(g->Pgeoset, PFGS_NORMAL3, PFGS_PER_VERTEX, g->Pnorms, NULL); pfGSetAttr(g->Pgeoset, PFGS_COORD3, PFGS_PER_VERTEX, g->Pcoords, NULL); /* tristrips per sphere * spheres */ pfGSetNumPrims(g->Pgeoset, g->numvert*LONG); } -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.co.uk UK From guest Tue May 30 04:00:54 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA19565; Tue, 30 May 1995 03:54:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA19562; Tue, 30 May 1995 03:54:56 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23043; Tue, 30 May 95 03:54:55 -0700 Received: from ligsg10.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id DAA20190; Tue, 30 May 1995 03:54:43 -0700 Received: by ligsg10.epfl.ch (Smail3.1.29.1 #28) id m0sGOwb-0000cQC; Tue, 30 May 95 12:54 MET DST From: "Fernando D. Mato Mira" Message-Id: <9505301254.ZM12386@lig.di.epfl.ch> Date: Tue, 30 May 1995 12:54:41 +0200 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: quaternions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Dear metaPerformers, Have you considered representing the rotation part of pfDCSs internally as the pair L(q), R(q*) so as to provide a very efficient quaternion interface to these structures? From guest Tue May 30 03:35:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA19476; Tue, 30 May 1995 03:31:53 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA19473; Tue, 30 May 1995 03:31:53 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA22536; Tue, 30 May 95 03:31:52 -0700 Received: from relay.iunet.it by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA19372; Tue, 30 May 1995 03:31:37 -0700 Received: from hpdtmt2 ([193.76.230.93]) by relay.iunet.it with SMTP id AA02922 (5.65c8/IDA-1.4.4 for ); Tue, 30 May 1995 12:36:26 +0200 Message-Id: <199505301036.AA02922@relay.iunet.it> Received: by hpdtmt2 (16.6/16.2) id AA22392; Tue, 30 May 95 12:19:31 +0200 From: Marco Crocetta Subject: db paging & Performer 2.0 To: info-performer@sgi.sgi.com Date: Tue, 30 May 95 12:19:30 METDST Mailer: Elm [revision: 66.25] Status: O Hi, I was reading some old mail and I found written somewhere that the new Performer 2.0 will support the database paging feature. Can I have more details about this new feature? Thanks in advance -------------------------- Marco Crocetta DATAMAT SpA, Rome e-mail: onyx@datamat.it -------------------------- From guest Tue May 30 10:35:09 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA20088; Tue, 30 May 1995 10:32:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA20085; Tue, 30 May 1995 10:32:38 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10197; Tue, 30 May 95 10:32:36 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id KAA18933; Tue, 30 May 1995 10:32:31 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id KAA06692; Tue, 30 May 1995 10:32:28 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:matomira@lig.di.epfl.ch id AA10181; Tue, 30 May 95 10:32:25 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA16416; Tue, 30 May 1995 10:32:25 -0700 Message-Id: <199505301732.KAA16416@surreal.asd.sgi.com> To: "Fernando D. Mato Mira" Cc: info-performer@sgi.sgi.com Subject: Re: quaternions In-Reply-To: Your message of "Tue, 30 May 95 12:54:41 +0200." <9505301254.ZM12386@lig.di.epfl.ch> Date: Tue, 30 May 95 10:32:25 -0700 From: Jim Helman Status: O Performer 2.0 does have a set of quaternion routines. However the interface to a DCS remains as before, so you have to create a matrix from your quaternion. This is reasonable, since GL uses a matrix. How useful would it be if we folded some quaternion functionality into pfDCS? It seems that would be mainly a convenience, albeit perhaps a significant one for quaternion users. -jim From guest Tue May 30 10:54:32 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA20172; Tue, 30 May 1995 10:50:20 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA20169; Tue, 30 May 1995 10:50:19 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA11780; Tue, 30 May 95 10:50:17 -0700 Received: from ligsg10.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id KAA22462; Tue, 30 May 1995 10:50:15 -0700 Received: by ligsg10.epfl.ch (Smail3.1.29.1 #28) id m0sGVQj-0000AtC; Tue, 30 May 95 19:50 MET DST From: "Fernando D. Mato Mira" Message-Id: <9505301950.ZM29257@lig.di.epfl.ch> Date: Tue, 30 May 1995 19:50:12 +0200 In-Reply-To: Jim Helman "Re: quaternions" (May 30, 10:32am) References: <199505301732.KAA16416@surreal.asd.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Jim Helman Subject: Re: quaternions Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 30, 10:32am, Jim Helman wrote: > pfDCS? It seems that would be mainly a convenience, albeit perhaps a > significant one for quaternion users. What would be significant would be an implementation which does not penalize quaternion users performance-wise. Given that Performer is The Thing for SGI's aerospace users, quaternions should be The Thing in Performer, probably. And if someone is smart enough to be using Performer, ditto for quaternions.. From guest Tue May 30 11:48:50 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA20430; Tue, 30 May 1995 11:44:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA20427; Tue, 30 May 1995 11:44:47 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16465; Tue, 30 May 95 11:44:44 -0700 Received: from shallow.division.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA04961; Tue, 30 May 1995 11:44:14 -0700 Received: from caliban (caliban.division.co.uk) by shallow.division.co.uk with SMTP id AA13037 (5.65c/IDA-1.4.4 for matomira@lig.di.epfl.ch); Tue, 30 May 1995 18:06:33 GMT Received: by caliban (931110.SGI/921111.SGI) for @shallow.division.co.uk:info-performer@sgi.com id AA10222; Tue, 30 May 95 19:06:30 +0100 From: "Angus Dorbie" Message-Id: <9505301906.ZM10220@caliban.division.co.uk> Date: Tue, 30 May 1995 19:06:29 +0100 In-Reply-To: "Fernando D. Mato Mira" "Re: quaternions" (May 30, 7:50pm) References: <199505301732.KAA16416@surreal.asd.sgi.com> <9505301950.ZM29257@lig.di.epfl.ch> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Fernando D. Mato Mira" Subject: Re: quaternions Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > Given that Performer is The Thing for SGI's aerospace users, > quaternions should be The Thing in Performer, probably. This assumes that aerospace users are The Thing for Performer. -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.co.uk UK From guest Tue May 30 11:17:49 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA20301; Tue, 30 May 1995 11:12:33 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA20298; Tue, 30 May 1995 11:12:32 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13668; Tue, 30 May 95 11:12:31 -0700 Received: from ligsg10.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id LAA27663; Tue, 30 May 1995 11:12:26 -0700 Received: by ligsg10.epfl.ch (Smail3.1.29.1 #28) id m0sGVlz-0000OzC; Tue, 30 May 95 20:12 MET DST From: "Fernando D. Mato Mira" Message-Id: <9505302012.ZM29299@lig.di.epfl.ch> Date: Tue, 30 May 1995 20:12:11 +0200 In-Reply-To: "Angus Dorbie" "Re: quaternions" (May 30, 7:06pm) References: <199505301732.KAA16416@surreal.asd.sgi.com> <9505301950.ZM29257@lig.di.epfl.ch> <9505301906.ZM10220@caliban.division.co.uk> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Angus Dorbie" Subject: Re: quaternions Cc: info-performer@sgi.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 30, 7:06pm, Angus Dorbie wrote: > Subject: Re: quaternions > > Given that Performer is The Thing for SGI's aerospace users, > > quaternions should be The Thing in Performer, probably. > > This assumes that aerospace users are The Thing for Performer. Well, just that there are quite a few of them, and that that's the classic vissim market (probably more than us, animation users, which are into quaternions, too!). Any robotics folks out there? From guest Tue May 30 11:33:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA20379; Tue, 30 May 1995 11:28:39 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA20376; Tue, 30 May 1995 11:28:38 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA14980; Tue, 30 May 95 11:28:32 -0700 Received: from chris.gcs.redstone.army.mil by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id LAA01333; Tue, 30 May 1995 11:28:29 -0700 Received: by chris.gcs.redstone.army.mil (931110.SGI/930416.SGI) for info-performer@sgi.com id AA04207; Tue, 30 May 95 13:29:20 -0500 From: "Kevin R. McClure" Message-Id: <9505301329.ZM4205@chris.gcs.redstone.army.mil> Date: Tue, 30 May 1995 13:29:19 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Subject: IRIX 5.3 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Does anyone know what great and wonderful things IRIX 5.3 does for Performer( i.e quicker and more efficient access to hardware, graphics, etc )? -- email: Kevin McClure phone: (205) 842-7290 From guest Tue May 30 11:36:09 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id LAA20390; Tue, 30 May 1995 11:32:05 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA20387; Tue, 30 May 1995 11:31:59 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA15257; Tue, 30 May 95 11:31:57 -0700 Received: from cs.utah.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id LAA02133; Tue, 30 May 1995 11:31:55 -0700 From: moore@ced.utah.edu Received: from canyonlands.ced.utah.edu by cs.utah.edu (8.6.12/utah-2.21-cs) id MAA10519; Tue, 30 May 1995 12:31:53 -0600 Received: from ruin.ced.utah.edu by canyonlands.ced.utah.edu (4.1/SMI-4.1) id AA28271; Tue, 30 May 95 12:31:22 MDT Received: by ruin.ced.utah.edu (940816.SGI.8.6.9//ident-1.0) id MAA18368; Tue, 30 May 1995 12:31:21 -0600 Date: Tue, 30 May 1995 12:31:21 -0600 Message-Id: <199505301831.MAA18368@ruin.ced.utah.edu> To: jimh@surreal Cc: info-performer@sgi.sgi.com In-Reply-To: <199505301732.KAA16416@surreal.asd.sgi.com> (message from Jim Helman on Tue, 30 May 95 10:32:25 -0700) Subject: Re: quaternions Status: O Cc: info-performer@sgi.com Date: Tue, 30 May 95 10:32:25 -0700 From: Jim Helman Performer 2.0 does have a set of quaternion routines. However the interface to a DCS remains as before, so you have to create a matrix from your quaternion. This is reasonable, since GL uses a matrix. How useful would it be if we folded some quaternion functionality into pfDCS? It seems that would be mainly a convenience, albeit perhaps a significant one for quaternion users. At one time someone (Mike Jones, I think) posted the 2.0 quaternion interface here. Could you post it again? From guest Tue May 30 12:31:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA20621; Tue, 30 May 1995 12:27:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA20618; Tue, 30 May 1995 12:27:17 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19411; Tue, 30 May 95 12:27:15 -0700 Received: from vr2.engin.umich.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA13904; Tue, 30 May 1995 12:27:14 -0700 Received: from localhost by vr2.engin.umich.edu via SMTP (940816.SGI.8.6.9/921111.SGI.AUTO) id PAA09644; Tue, 30 May 1995 15:13:34 -0400 Message-Id: <199505301913.PAA09644@vr2.engin.umich.edu> To: info-performer@sgi.sgi.com Cc: seguin@vr2.engin.umich.edu, keithfry@vr2.engin.umich.edu Subject: IV loader bugs/problems Date: Tue, 30 May 1995 15:13:21 -0400 From: Ralph Seguin Status: O Hi. I have a list of problems that I've found with the Performer IV loader. I realize that I may have to fix this myself, but I am hoping somebody has already solved it ;) Problem: 1. Blinker ==> pfSequence does not work properly. I have looked at the code, and it seems as though it should work, but it just doesn't seem to be adding children to the sequence node. 2. the Nurbs tesselator dumps core. (appears as though it may be running out of swap). 3. What is the best way of having Performer support Engines and NodeKits? I saw some mention of having node callback stuff. We were planning on developing a bunch of our own Engine subclasses also. Anybody fixed these already? What about Engines? Got any c++ code for it? Thanks, Ralph From guest Tue May 30 12:30:36 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA20591; Tue, 30 May 1995 12:25:12 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA20588; Tue, 30 May 1995 12:25:11 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19273; Tue, 30 May 95 12:25:09 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA13464; Tue, 30 May 1995 12:25:06 -0700 Received: from crusader.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA24260; Tue, 30 May 95 15:26:49 EDT Received: by crusader.vsl.ist.ucf.edu (940816.SGI.8.6.9) id PAA28508; Tue, 30 May 1995 15:25:15 -0400 Date: Tue, 30 May 1995 15:25:15 -0400 (EDT) From: "Lance R. Marrou" To: "Kevin R. McClure" Cc: info-performer@sgi.sgi.com Subject: Re: IRIX 5.3 In-Reply-To: <9505301329.ZM4205@chris.gcs.redstone.army.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Tue, 30 May 1995, Kevin R. McClure wrote: > > Does anyone know what great and wonderful things IRIX 5.3 does for > > Performer( i.e quicker and more efficient access to hardware, graphics, etc )? For one, as Jim Helman stated, you need IRIX5.3 to run Performer 2.0. If you have IRIX 4.x, then you should definitely upgrade. The release notes give a whole bunch of reasons. IRIX5.3 offers the advantage of DSOs over 5.2 and any earlier version of IRIX. I don't know what else there is, but I would suggest IRIX 5.3 as a general improvement. ______________________________________________________________________________ /\ ______ /\____ ______ ______ E-mail: marrou@vsl.ist.ucf.edu Visual / / / _ / / __ // ____// ____/ VSL: (407)658-5073 Systems / /__ / /_/ / / / / // /___ / __/_ R. Marrou Fax: (407)658-5059 Lab /____//____/\\/_/ /_//_____//_____/ http://www.vsl.ist.ucf.edu/~marrou "Reap the whirlwind." "We don't need no thought control." From guest Tue May 30 12:31:52 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA20600; Tue, 30 May 1995 12:26:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA20597; Tue, 30 May 1995 12:26:56 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA19371; Tue, 30 May 95 12:26:55 -0700 Received: from copernicus.hpc.org by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id MAA13798; Tue, 30 May 1995 12:26:52 -0700 Received: from galileo.hpc.org by copernicus.hpc.org (4.1/SMI-4.1) id AA00470; Tue, 30 May 95 15:33:11 EDT Received: by galileo.hpc.org (940816.SGI.8.6.9/930416.SGI) id PAA02306; Tue, 30 May 1995 15:33:15 -0400 Date: Tue, 30 May 1995 15:33:15 -0400 (EDT) From: Michael Kelley X-Sender: kelleym@galileo.hpc.org To: Performer Subject: Performer 2.0 In-Reply-To: <199505301831.MAA18368@ruin.ced.utah.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I don't mean to be impatient, but I was just wondering if any of the Performer gurus can give us an update on the release of 2.0. Last I saw they were going to release it in June (?). Is this still the target, or has that changed? Thanks, and keep up the good work Performer team!! ____________________________________________________________________ Michael Kelley Systems Programmer Information Sciences Institute kelleym@csto.snap.org (703) 243-9422 ____________________________________________________________________ From guest Tue May 30 13:31:30 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA21418; Tue, 30 May 1995 13:24:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA21414; Tue, 30 May 1995 13:24:32 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA23389; Tue, 30 May 95 13:24:31 -0700 Received: from electrogig.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA25624; Tue, 30 May 1995 13:24:25 -0700 Received: from lee.electrogig.com by electrogig.com via ESMTP (940816.SGI.8.6.9/940406.SGI) for <@electrogig.electrogig.com:info-performer@sgi.com> id NAA22507; Tue, 30 May 1995 13:21:54 -0700 Received: by lee.electrogig.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id NAA03550; Tue, 30 May 1995 13:21:45 -0700 From: "AnitaKishore" Message-Id: <9505301321.ZM3548@lee.electrogig.com> Date: Tue, 30 May 1995 13:21:43 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: IV loader bugs/problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O On May 30, 3:13pm, Ralph Seguin wrote: > Subject: IV loader bugs/problems > Hi. I have a list of problems that I've found with the > Performer IV loader. I realize that I may have to fix > this myself, but I am hoping somebody has already solved it ;) > > > Problem: > > 3. What is the best way of having Performer support Engines > and NodeKits? I saw some mention of having node callback > stuff. We were planning on developing a bunch of our > own Engine subclasses also. > > > Anybody fixed these already? What about Engines? Got any > c++ code for it? > > Thanks, Ralph > > >-- End of excerpt from Ralph Seguin I am facing the same problem regarding engine with performer 1.2. It seems that this version doesn't directly support engines. But Performer 2.0 will. In the meantime I am trying to modify loadIv routine to take care of engine subclasses. I think if I include one more "if..then..else" in callback function "preNode" of loadIv to take care of SoEngine types, which will attach a structure containing the engine data to the relevant Performer node, I should be able to import engine info into Performer. Well, thats my requirement - to get engine data into performer data base. Off course, since I may or may not have the engine subclass code to link with, so I will use the DSO concept. Anyone with experience/knowledge about this, please comment on the above method. Will this work? Thanks Anita Kishore From guest Tue May 30 14:48:17 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id OAA27248; Tue, 30 May 1995 14:44:49 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA27245; Tue, 30 May 1995 14:44:43 -0700 Received: from [192.26.51.188] by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA29302; Tue, 30 May 95 14:44:42 -0700 Received: from doodad.engr.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for id OAA19593; Tue, 30 May 1995 14:44:37 -0700 Received: by doodad.engr.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer@sgi.com id OAA22521; Tue, 30 May 1995 14:45:04 -0700 From: luebke@doodad.engr.sgi.com (David Luebke) Message-Id: <199505302145.OAA22521@doodad.engr.sgi.com> Subject: Performer allocating texture mem To: info-performer@sgihub.corp.sgi.com (Performer-help mailing list) Date: Tue, 30 May 1995 14:45:03 -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: 484 Status: O What mechanism does Performer use to allocate texture memory? We have RM5s and a flt database with a lot of textures, but after loading about 12 megs it freezes up. My theory is that the texture memory is getting fragmented (most of our textures are really small, 16x16 or smaller) and that the loader is going into a loop looking for a large enough chunk of memory to fit that next texture. Is this plausible? If so what do I do about it? Dave -- David Luebke luebke@engr.sgi.com From guest Tue May 30 15:38:29 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA27550; Tue, 30 May 1995 15:34:51 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA27547; Tue, 30 May 1995 15:34:49 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03073; Tue, 30 May 95 15:34:46 -0700 Received: from media.mit.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id PAA28252; Tue, 30 May 1995 15:34:44 -0700 From: robin@media.mit.edu Received: by media.mit.edu (5.57/DA1.0.4.amt) id AA06095; Tue, 30 May 95 18:34:43 -0400 Message-Id: <9505302234.AA06095@media.mit.edu> To: info-performer@sgi.sgi.com Subject: memory problems Date: Tue, 30 May 95 18:34:42 -0400 X-Mts: smtp Status: O hi all, i am not a programmer but i am using Performer to visualize a database of images and texts from the history of photography as part of my Master's thesis, and i was wondering if anyone out there has any advice for me... i am coding in C++ on an onyx, and i am running into what seems to me like limits in the number of polygons(?) or maybe DCSs that i can draw. whenever i try to run my code with the entire contents of my database, it seg faults. when i cut down the size of the database, it runs without problem. it seems to load all the texture maps and make all the graphical objects without complaint, but then when it goes to draw them for the first time it seg faults. when i tried switching compilers, it didn't seg fault but it didn't ever draw anything either. i know it is not the texture memory, cuz when i try drawing rectangles in place of the texture maps, it still seg faults. i guess i have just written some bad code, but i don't know where to begin to find the problem. why would it work when drawing 100 items, but not 200? am i reaching some memory limit that i don't know about, and if so why doesn't it give me an error message or something? any help/advice would be greatly appreciated. thanks! robin From guest Tue May 30 15:41:19 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA27555; Tue, 30 May 1995 15:36:38 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA27552; Tue, 30 May 1995 15:36:37 -0700 Received: from [192.26.51.188] by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03251; Tue, 30 May 95 15:36:35 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) for id PAA29124; Tue, 30 May 1995 15:36:33 -0700 Received: from rose.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@sgihub.corp.sgi.com id AA03244; Tue, 30 May 95 15:36:30 -0700 Received: by rose.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id PAA07902; Tue, 30 May 1995 15:36:30 -0700 From: "Sharon Clay (Fischler)" Message-Id: <9505301536.ZM7900@rose.asd.sgi.com> Date: Tue, 30 May 1995 15:36:30 -0700 In-Reply-To: luebke@doodad.engr.sgi.com (David Luebke) "Performer allocating texture mem" (May 30, 2:45pm) References: <199505302145.OAA22521@doodad.engr.sgi.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: luebke@doodad.engr.sgi.com (David Luebke), info-performer@sgihub.corp.sgi.com (Performer-help mailing list) Subject: Re: Performer allocating texture mem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O +>---- On May 30, 2:45pm, David Luebke wrote: > Subject: Performer allocating texture mem ->What mechanism does Performer use to allocate texture memory? We have RM5s ->and a flt database with a lot of textures, but after loading about 12 megs it ->freezes up. My theory is that the texture memory is getting fragmented (most of ->our textures are really small, 16x16 or smaller) and that the loader is ->going into a loop looking for a large enough chunk of memory to fit that next ->texture. Is this plausible? If so what do I do about it? HW texture memory is allocated by the OS upon a pfApplyTex(). This probably first happens when you do a pfuDownloadTexList() after reading in your database. When does the freeze happen? In the loader before pfuDownloadTexList() is called or after? If you think that textures have been downloaded, you can run osview and see if we are hung in the kernel or in user code. src. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Graphics Dev. src@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Tue May 30 16:21:32 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id QAA27808; Tue, 30 May 1995 16:18:19 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA27805; Tue, 30 May 1995 16:18:18 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06809; Tue, 30 May 95 16:18:17 -0700 Received: from gsaup.ucla.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id QAA07195; Tue, 30 May 1995 16:18:13 -0700 Received: from goff by gsaup.ucla.edu (5.x/SMI-SVR4) id AA25987; Tue, 30 May 1995 16:18:12 -0700 Received: by goff (940816.SGI.8.6.9) id QAA16475; Tue, 30 May 1995 16:15:13 -0700 From: "Scott A. Friedman" Message-Id: <9505301615.ZM16473@goff> Date: Tue, 30 May 1995 16:15:13 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfUserData woes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hello, This is either a Performer or MultiGen Loader question so this seemed to be the best place to post this. This question has to do with pfUserData and any potential gotchas it may present. I have an application that sets pfUserData of various Groups and Objects from within a loader callback. The pointers passed to pfUserData are not pfMalloc'ed and are not from any shared arena. Problem is when I run MP the application dies inside the loader. When I force run my application in single process mode everything works fine. The program quits - no core dump - no message - NOTHING. I figured things were going astray in my callback but no that's not the problem either (I think). The application quits outside of my callback and in the loader somewhere. Now, when I remove the pfUserData call in my callback and run in MP mode everything works fine. My feeling is there is something building up before it dies(?). Man pages on pfUserData are pretty straightforward - nothing special there. The data is only accessed from the APP process so it shouldn't have to come from an arena (right?) Question: Is there something not obvious I should watch for when using pfUserData in MP mode? Is there some loader weirdness I should take into consideration? Any thoughts, suggestions or experiences are welcome. Scott -- Scott A. Friedman UCLA Department of Architecture + Urban Design Lecturer Department of Computer Science From guest Tue May 30 17:09:33 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA01887; Tue, 30 May 1995 17:05:08 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA01884; Tue, 30 May 1995 17:05:07 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10512; Tue, 30 May 95 17:04:52 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id RAA17366; Tue, 30 May 1995 17:04:47 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id QAA12941; Tue, 30 May 1995 16:57:16 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:robin@media.mit.edu id AA09911; Tue, 30 May 95 16:57:14 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA23013; Tue, 30 May 1995 16:57:14 -0700 Message-Id: <199505302357.QAA23013@surreal.asd.sgi.com> To: robin@media.mit.edu Cc: info-performer@sgi.sgi.com Subject: Re: memory problems In-Reply-To: Your message of "Tue, 30 May 95 18:34:42 EDT." <9505302234.AA06095@media.mit.edu> Date: Tue, 30 May 95 16:57:13 -0700 From: Jim Helman Status: O There are no fixed limits on database size in Performer, except for our default arena size of 256MB which should be adequate for most scenes. > why would it work when drawing 100 items, but not 200? It could be that something moves in memory so that a read of an unitialized varialble or a write to an incorrect location causes no problem with one database, but drops core with another. Check your code for unitialized variables and try running dbx on the resulting core dump to see where the problem occurs. -jim From guest Tue May 30 17:54:19 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id RAA06374; Tue, 30 May 1995 17:51:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id RAA06371; Tue, 30 May 1995 17:51:22 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA13392; Tue, 30 May 95 17:51:17 -0700 Received: from ix5.ix.netcom.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id RAA24708; Tue, 30 May 1995 17:51:15 -0700 Received: from by ix5.ix.netcom.com (8.6.12/SMI-4.1/Netcom) id RAA10353; Tue, 30 May 1995 17:50:09 -0700 Date: Tue, 30 May 1995 17:50:09 -0700 Message-Id: <199505310050.RAA10353@ix5.ix.netcom.com> From: blastarr@ix.netcom.com (Kent Miller) Subject: Overloading the 'new' operator To: info-performer@sgi.sgi.com Status: O I realize that this discussion already took place here (maybe 2 mos back), but I need a refresher. I'm pretty sure I want to create new objects from the shared arena, but I seem to remember some objections to this approach. Would someone summarize for me the pros & cons of overloading new to use the shared arena, and perhaps a brief example? Many thanks. From guest Tue May 30 19:13:00 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA07038; Tue, 30 May 1995 19:09:44 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA07035; Tue, 30 May 1995 19:09:43 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA17879; Tue, 30 May 95 19:09:42 -0700 Received: from einstein.technet.sg by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id TAA05422; Tue, 30 May 1995 19:09:08 -0700 Received: (from mphilip@localhost) by einstein.technet.sg (8.6.11/8.6.9) id KAA13078; Wed, 31 May 1995 10:08:52 +0800 From: Michael Philip Message-Id: <199505310208.KAA13078@einstein.technet.sg> Subject: Re: IV loader bugs/problems To: seguin@vr2.engin.umich.edu (Ralph Seguin) Date: Wed, 31 May 1995 10:08:52 +0800 (SST) Cc: info-performer@sgi.sgi.com, seguin@vr2.engin.umich.edu, keithfry@vr2.engin.umich.edu In-Reply-To: <199505301913.PAA09644@vr2.engin.umich.edu> from "Ralph Seguin" at May 30, 95 03:13:21 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1581 Status: O > Problem: > > 1. Blinker ==> pfSequence does not work properly. > I have looked at the code, and it seems as though it should > work, but it just doesn't seem to be adding children to the > sequence node. I'm pretty sure I already reported this problem (any my fix) to the Performer team. It looks to me like the Inventor traversal doesn't descend all the SoBlinker children. My workaround was to make a PerfBlink wrapper class that does the same thing as the PerfLOD class does for SoLevelOfDetail nodes - I guess for the same reason. Here's some code: //////////////////////////////////////////////////////////////////////// #include #include class PerfBlink : public SoBlinker { SO_NODE_HEADER(PerfBlink); public: static void initClass(); PerfBlink(); protected: virtual void callback(SoCallbackAction *action); private: virtual ~PerfBlink(); }; SO_NODE_SOURCE( PerfBlink ); void PerfBlink::initClass() { classTypeId = SoType::overrideType(SoBlinker::getClassTypeId(), createInstance); parentFieldData = SoBlinker::getFieldDataPtr(); } PerfBlink::PerfBlink() { SO_NODE_CONSTRUCTOR( PerfBlink ); } PerfBlink::~PerfBlink() { } void PerfBlink::callback( SoCallbackAction *action ) { SoGroup::doAction( action ); } void InitConverter() { PerfBlink::initClass(); } //////////////////////////////////////////////////////////////////////// Michael Philip, Symbolic Research Pte Ltd, Singapore Fax:(65)295-5311 AppleLink:FEA0001 mphilip@technet.sg From guest Tue May 30 19:30:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id TAA07130; Tue, 30 May 1995 19:28:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id TAA07127; Tue, 30 May 1995 19:28:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA18795; Tue, 30 May 95 19:28:05 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id TAA08014; Tue, 30 May 1995 19:28:01 -0700 Received: from onyx.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA25797; Tue, 30 May 95 22:29:50 EDT Received: by onyx.vsl.ist.ucf.edu (940816.SGI.8.6.9) id WAA18332; Tue, 30 May 1995 22:29:49 -0400 Date: Tue, 30 May 1995 22:29:48 -0400 (EDT) From: "Michael J. Smith" Cc: info-performer@sgi.sgi.com Subject: Re: Overloading the 'new' operator In-Reply-To: <199505310050.RAA10353@ix5.ix.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Tue, 30 May 1995, Kent Miller wrote: > I realize that this discussion already took place here (maybe 2 mos > back), but I need a refresher. > > I'm pretty sure I want to create new objects from the shared arena, but > I seem to remember some objections to this approach. As I remember there were objections about the C++ virtual table not being correctly represented for calls from multiple execution threads. Does anyone have any hard evidence and can pinpoint where this becomes a problem? > Would someone summarize for me the pros & cons of overloading new to > use the shared arena, and perhaps a brief example? I was looking into this recently, and found that using the IRIX REACT system such as usinit, and usadd, along with usmalloc, and usfree would allow me to use my C++ data-structures in a shared memory space. This allows for me to use really nice data-structures among multiple processes -- so I would love to be able to do this. However, when I tried to integrate this exciting potential into my performer application I was firmly rejected in all attempts. I basically tried to overload the new and delete operators to provide a global use of the shared arena I had chosen. This works in test applications as long as I make sure that I initialize the arena before using the functions. So, the problem now is I can't use a separate arena in the performer app because it conflicts with performers arena that is attached to the user memory segment. When I try to use my overloaded new and delete operators (which just call usmalloc and usfree), this causes the perf library to seg fault down in a call to _grow or something like this. If this sounds like an interesting subject I can get more details on what the errors were exactly, but their exact nature seemed expected and easy to cause. If there is a way I can (without making a lot of ugly code additions) add the functionality of new'ing objects into the shared seg under performer I would love to hear about successes. I remember someone suggested possibilities about 2 months ago as to what could be done to overload the new and delete operators, but when I tried this method it didn't work for me. The best of all worlds would be to hear that I can overload the global new and delete functions in a specific way to support performers internal libraries and still allocate all of my objects into the shared segment. Thanks for any suggestions and information... ----------------------------------------------------------------------------- | Michael J. Smith University Of Central Florida | | Visual Systems Laboratory Institute for Simulation & Training | | Graduate Research Assistant 3280 Progress Drive | | smith@vsl.ist.ucf.edu Orlando, FL 32826-0544 | | @cs.ucf.edu | | Codesmith for hire | ----------------------------------------------------------------------------- From guest Tue May 30 22:42:46 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id WAA08071; Tue, 30 May 1995 22:38:32 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA08068; Tue, 30 May 1995 22:38:31 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA26135; Tue, 30 May 95 22:38:30 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id WAA01861; Tue, 30 May 1995 22:38:22 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id WAA10599; Tue, 30 May 1995 22:38:18 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:smith@vsl.ist.ucf.edu id AA26127; Tue, 30 May 95 22:38:16 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id WAA25399; Tue, 30 May 1995 22:38:12 -0700 Message-Id: <199505310538.WAA25399@surreal.asd.sgi.com> To: "Michael J. Smith" Cc: info-performer@sgi.sgi.com Subject: Re: Overloading the 'new' operator In-Reply-To: Your message of "Tue, 30 May 95 22:29:48 EDT." Date: Tue, 30 May 95 22:38:04 -0700 From: Jim Helman Status: O There shouldn't be any problem overloading the new operator to define a version that uses pfMalloc and the shared arena for creating your objects. The only issues I'm aware of have to do with pointers that might only be valid in one process. Most pointers are explicit, so making sure everything refers to shared memory is your problem. But if you use virtual functions you could run into problems with them. In particular, if you dynamically load in (e.g. via a DSO) the class, you need to do so in all processes, and the virtual function tables or functions could end up at different locations in different processes. However, this won't happen with statically linked objects or with DSOs loaded before pfConfig. Even those loaded after pfConfig will probably wind up at the same location unless a conflict arises. I'm not sure why you are having problems since the same should be possible using a usinit arena (although a usinit arena is only *required* between unrelated processes and takes some care in positioning with usconfig(CONF_ATTACHADDR,...) to avoid virtual memory conflicts). This latter could be causing your problems. Performer has always used an overloaded new() operator for allocating libpf objects. In 1.2, this operator is a global new() operator with a private second argument type to keep it internal and separate from any application's usage or overloading of new. In 2.0, this has been changed so that libpf objects are newed using an class-specific new() function overloaded as appropriate within the libpr/libpf class hierarchy. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed May 31 02:47:45 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id CAA08496; Wed, 31 May 1995 02:45:15 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id CAA08493; Wed, 31 May 1995 02:45:14 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03845; Wed, 31 May 95 02:45:13 -0700 Received: from shallow.division.co.uk by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id CAA18936; Wed, 31 May 1995 02:44:41 -0700 Received: from caliban (caliban.division.co.uk) by shallow.division.co.uk with SMTP id AA14585 (5.65c/IDA-1.4.4 for info-performer@sgi.com); Wed, 31 May 1995 09:44:26 GMT Received: by caliban (931110.SGI/921111.SGI) for @shallow.division.co.uk:info-performer@sgi.com id AA11413; Wed, 31 May 95 10:44:23 +0100 From: "Angus Dorbie" Message-Id: <9505311044.ZM11411@caliban.division.co.uk> Date: Wed, 31 May 1995 10:44:23 +0100 In-Reply-To: David Luebke "Performer allocating texture mem" (May 30, 2:45pm) References: <199505302145.OAA22521@doodad.engr.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: David Luebke Subject: Re: Performer allocating texture mem Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O > What mechanism does Performer use to allocate texture memory? We have RM5s > and a flt database with a lot of textures, but after loading about 12 megs it > freezes up. My theory is that the texture memory is getting fragmented (most of > our textures are really small, 16x16 or smaller) and that the loader is > going into a loop looking for a large enough chunk of memory to fit that next > texture. Is this plausible? If so what do I do about it? > > Dave > -- > David Luebke > luebke@engr.sgi.com Perhaps the deficit is due to the generation of mipmaps, the numbers seem right for this to be the case. How did you arrive at the 12 megs number? When applying mipmap minification filter you should add another 1/3 to account for the memory they use if you are simply totaling image size. Don't know about the loop, loading big textures can take a long time (when mipmapping). -- Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus@division.co.uk UK From guest Wed May 31 03:11:31 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA08529; Wed, 31 May 1995 03:08:34 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA08526; Wed, 31 May 1995 03:08:33 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA04514; Wed, 31 May 95 03:08:32 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) id DAA20247; Wed, 31 May 1995 03:08:29 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) id DAA22189; Wed, 31 May 1995 03:08:28 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:kishore@electrogig.com id AA04509; Wed, 31 May 95 03:08:27 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id DAA25076; Wed, 31 May 1995 03:08:26 -0700 Message-Id: <199505311008.DAA25076@surreal.asd.sgi.com> To: "AnitaKishore" Cc: info-performer@sgi.sgi.com Subject: Re: IV loader bugs/problems In-Reply-To: Your message of "Tue, 30 May 95 13:21:43 PDT." <9505301321.ZM3548@lee.electrogig.com> Date: Wed, 31 May 95 03:08:25 -0700 From: Jim Helman Status: O > It seems that this version doesn't directly support engines. But > Performer 2.0 will. To clarify, 2.0 may support an application traversal which would enable a loader to easily provide engine like functionality in automatically invoked callbacks. Currently, even in 1.2, this could be done in an explicitly invoked traversal (e.g. pfuTraverse). To improve Inventor compatibility, features very similar to Inventor's engines and fields are planned for the release after 2.0. -jim From guest Wed May 31 04:00:40 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id DAA08619; Wed, 31 May 1995 03:58:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id DAA08616; Wed, 31 May 1995 03:58:15 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA05729; Wed, 31 May 95 03:58:14 -0700 Received: from ben.britain.eu.net by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id DAA22677; Wed, 31 May 1995 03:58:04 -0700 Message-Id: <199505311058.DAA22677@sgi.sgi.com> Received: from msim.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Wed, 31 May 1995 11:57:48 +0100 Date: Wed, 31 May 95 11:59 GMT From: "ml@Strider" <"FIFE::"@MSIM.CO.UK> To: INFO-PERFORMER Subject: Subscription Status: O Received: by DniMail (v1.0); Wed May 31 11:56:52 1995 BST Return-Path: Received: from Strider by lothian.sim.mrcs (4.1/SMI-4.1-DNI) id AA08837; Wed, 31 May 95 11:56:43 BST Received: by Strider (920330.SGI/921111.SGI) for com.sgi.sgi::info-performer@uknet@lothian id AA28092; Wed, 31 May 95 11:56:41 GMT Date: Wed, 31 May 95 11:56:41 GMT From: ml@Strider (Michael Lees) Message-Id: <9505311156.AA28092@Strider> To: com.sgi.sgi::info-performer@uknet@lothian Subject: Subscription Can I subscribe, please ? +-----------------------------------------------------------------------------+ | !!! PLEASE TAKE NOTE !!! | | | | Using "REPLY" to this mail will NOT work as our system screws up the | | reply address. Please use the address below instead. | | | +-----------------------------------------------------------------------------+ | Mike Lees (Senior Software Engineer) | | | | | | Visuals Group, | Email: Lees_M@msim.co.uk | | Marconi Simulation, | | | The John Sutcliffe Building, | Telephone: +44 1383 821921 | | Fulmar Way, | Ext 2135/2263 | | Donibristle Industrial Park, | | | Dunfermline, | Fax: +44 1383 824227 Gp.3 | | Fife, | | | SCOTLAND. KY11 5JX | | +-----------------------------------------------------------------------------+ From guest Wed May 31 06:26:54 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA08842; Wed, 31 May 1995 06:24:08 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA08839; Wed, 31 May 1995 06:24:08 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10217; Wed, 31 May 95 06:24:06 -0700 Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id GAA01167; Wed, 31 May 1995 06:23:58 -0700 Received: from flash.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1) id AA28857; Wed, 31 May 95 09:25:46 EDT Received: by flash.vsl.ist.ucf.edu (940816.SGI.8.6.9) id JAA06336; Wed, 31 May 1995 09:25:44 -0400 Date: Wed, 31 May 1995 09:25:44 -0400 (EDT) From: "Michael J. Smith" To: Jim Helman Cc: info-performer@sgi.sgi.com Subject: Re: Overloading the 'new' operator In-Reply-To: <199505310538.WAA25399@surreal.asd.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Tue, 30 May 1995, Jim Helman wrote: > I'm not sure why you are having problems since the same should be > possible using a usinit arena (although a usinit arena is only > *required* between unrelated processes and takes some care in > positioning with usconfig(CONF_ATTACHADDR,...) to avoid virtual > memory conflicts). This latter could be causing your problems. Yes, if I add the following to my main program... static usptr_t *arena; void* operator new(unsigned int size) { return usmalloc(size, arena); } void operator delete(void *info) { usfree(info, arena); } .... int main(... { arena = usinit("/usr/tmp/loader"); usadd(arena); ....code that start's newing things like a class that interfaces with most of Performers primitives. } I get the following reset when I run it: When my code tries to do a pfNewScene...this makes recursive calls back to my delete operator which cause a segmentation violation. Is this because the libpr libraries use "new" and not "::new"? If so, how can I get around this? the call stack looks like this for reference...some of the PC's are deleted for clarity. 1 _afree(0x625690, 0x580a78, 0x4, 0x625d14) ["amalloc.c":89, 0xfb0da00] 2 _usfree(0x1, 0x62568c, 0x4, 0x625d14) ["usmalloc.c":42, 0xfb2efd4] 3 operator delete(void*)() ["main.C":46, 0x418000] 4 pfUpdatableList::_grow(void)() ["../../../lib/libpf/pfLists.C":25, 0x5ffa5b2c] 5 pfUpdatableList::set(long,const pfUpdatable*)() ["../../../lib/libpf/pfLists.C":25, 0x5ffa5c0c] 6 pfBuffer::newUpdatable(pfUpdatable*)() ["../../../lib/libpf/pfBuffer.C":172, 0x5ff8a20c] 7 pfUpdatable::pfUpdatable(pfBuffer*)() ["../../../lib/libpf/pfUpdatable.C":19, 0x5ffd961c] 8 pfNode::pfNode(pfBuffer*)() ["../../../lib/libpf/pfNode.C":37, 0x5ffac3a4] 9 pfGroup::pfGroup(pfBuffer*)() ["../../../lib/libpf/pfGroup.C":21, 0x5ff9aadc] 10 pfScene::pfScene(pfBuffer*)() ["../../../lib/libpf/pfScene.C":20, 0x5ffc4b4c] 11 pfNewScene() ["../../../lib/libpf/pfProcess.C":2778, 0x5ffc130c] 12 PerformerShell::PerformerShell(void)() ["PerfShell.C":195, 0x419704] 13 main(0x1, 0x7fffaf34, 0x4, 0x625d14) ["main.C":67, 0x41808c] 14 __start() ["crt1text.s":133, 0x417d2c] > > Performer has always used an overloaded new() operator for allocating > libpf objects. In 1.2, this operator is a global new() operator with > a private second argument type to keep it internal and separate from > any application's usage or overloading of new. In 2.0, this has been > changed so that libpf objects are newed using an class-specific new() > function overloaded as appropriate within the libpr/libpf class > hierarchy. > In 1.2 you may be using the correct new function, but this definitely isn't using the correct delete function. Is there any way I can tell in my delete that it needs to be pfFree'ed instead of usfree'ed? ----------------------------------------------------------------------------- | Michael J. Smith University Of Central Florida | | Visual Systems Laboratory Institute for Simulation & Training | | Graduate Research Assistant 3280 Progress Drive | | smith@vsl.ist.ucf.edu Orlando, FL 32826-0544 | | @cs.ucf.edu | | Codesmith for hire | ----------------------------------------------------------------------------- From guest Wed May 31 06:33:39 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id GAA08867; Wed, 31 May 1995 06:30:56 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id GAA08864; Wed, 31 May 1995 06:30:55 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA10462; Wed, 31 May 95 06:30:53 -0700 Received: from ns-mx.uiowa.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id GAA01644; Wed, 31 May 1995 06:30:46 -0700 Received: from blue.weeg.uiowa.edu by ns-mx.uiowa.edu (8.6.10/19950309.1) on Wed, 31 May 1995 08:29:22 -0500 id IAA20262 with ESMTP Received: from red.weeg.uiowa.edu by blue.weeg.uiowa.edu (8.6.12/940408) on Wed, 31 May 1995 08:30:43 -0500 id IAA49502 with ESMTP Received: by red.weeg.uiowa.edu (8.6.12/client-1.3) id IAA54786; Wed, 31 May 1995 08:26:25 -0500 Date: Wed, 31 May 1995 08:26:25 -0500 (CDT) From: "Wm. Frank Dea" X-Sender: wfdea@red.weeg.uiowa.edu To: info-performer@sgi.sgi.com Subject: pfHyperpipe() not working on IRIS Skywriter Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I am trying to use Performer 1.2 on IRIX 5.3 to set up a hyperpipe on a 2 processor 2 geometry engine IRIS Skywriter. I am new user of Performer and would appreciate any advice you may have to offer. The following code sets up 2 pipes each with their own channels and callback functions. I also set my own pfChanDrawFunc and pfChanCullFunc callbacks for each channel. However, the following code seems to hang after the first iteration of the while loop. Can you see the flaw in my code? Also, the sample program "perfly" seems to hang in the same way. Thanks, Frank (wfdea@blue.weeg.uiowa.edu) *********************** /* -- q.c -- -- This a test c file using performer and GL to create a hyperpipe. -- Doesn't seem to work correctly on the IRIS Skywriter. */ #include #include #include #include #include #include #include #include #include static void OpenPipeline1 (pfPipe *p); static void OpenPipeline2 (pfPipe *p); static void usage (void); void DrawFunc (pfChannel *chan, void *data); void CullFunc (pfChannel *chan, void *data); void main (int argc, char **argv) { float t = 0.0f; pfScene *scene; pfPipe *p1, *p2; pfChannel *chan1, *chan2; pfNode *root; float s,c; pfCoord view; /* Initialize Performer */ pfInit(); pfMultipipe(2); pfHyperpipe(2); pfMultiprocess (PFMP_APP_CULL_DRAW); /* Configure multiprocessing mode and start processes. */ pfConfig(); Set file path, read in .flt file, and attach file to the scene ... /* Initialize the graphics pipelines. */ p1 = pfGetPipe (0); pfInitPipe (p1, OpenPipeline1); p2 = pfGetPipe (1); pfInitPipe(p2, OpenPipeline2); /* Create and configure a pfChannel. */ chan1 = pfNewChan(p1); pfChanScene(chan1, scene); pfChanNearFar(chan1, 1.0f, 1000.00f); pfChanFOV(chan1, 45.0f, 0.0f); chan2 = pfNewChan(p2); pfChanScene(chan2, scene); pfChanNearFar(chan2, 1.0f, 1000.00f); pfChanFOV(chan2, 45.0f, 0.0f); /* Set the Callback routines for both Channels */ pfChanDrawFunc(chan1, DrawFunc); pfChanCullFunc(chan1, CullFunc); pfChanDrawFunc(chan2, DrawFunc); pfChanCullFunc(chan2, CullFunc); Zero Clock and set viewing vectors ... pfChanView (chan1, view.xyz, view.hpr); pfChanScene (chan1, scene); pfChanView (chan2, view.xyz, view.hpr); pfChanScene (chan2, scene); /* Simulate for ten seconds. */ while (t < 10.0f){ /* Compute new view position. */ t = pfGetTime(); /* Initiate cull/draw for this frame. */ pfFrame(); } /* Terminate parallel processes and exit. */ pfExit(); exit(0); } /* End of main */ static void OpenPipeline1 (pfPipe *p) { scrnselect(0); /* selects first screen */ foreground(); prefposition (100, 500, 100, 500); winopen("IRIS Performer -- Screen 1"); pfInitGfx(p); } /* End of OpenPipeline1 */ static void OpenPipeline2 (pfPipe *p) { scrnselect(1); /* selects second screen */ foreground(); prefposition (100, 500, 100, 500); winopen("IRIS Performer -- Screen 2"); pfInitGfx(p); } /* End of OpenPipeline2 */ static void usage (void) { fprintf(stderr, "Usage: oldtest file.flt ...\n"); pfExit(); exit(1); } /* End of usage */ void CullFunc (pfChannel *chan, void *data) { static long first = 1; pfCull(); } /* End of CullFunc */ void DrawFunc (pfChannel *chan, void *data) { pfClearChan(chan); pfDraw(); /* render the frame */ } /* End of DrawFunc */ -- William Frank Dea _________/|__________ /--------/-/---------/ / / / / / / "If you want to get results ... /- /---/-/---/ -/ try a prayer!" / / / / / / /--------/-/---------/ william-dea@uiowa.edu From guest Wed May 31 09:53:14 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id JAA09226; Wed, 31 May 1995 09:50:06 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA09223; Wed, 31 May 1995 09:50:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA20110; Wed, 31 May 95 09:50:03 -0700 Received: from relay3.UU.NET by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id JAA23317; Wed, 31 May 1995 09:49:56 -0700 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQyscx05500; Wed, 31 May 1995 12:49:54 -0400 Received: from multigen.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 31 May 1995 12:49:53 -0400 Received: from MAIL_CENTER (QM 3.0) by multigen.uucp (UMCP\QM 2.0.1) id AA01342; Wed, 31 May 1995 9:39:18 PST Message-Id: <00581.2884757958.1342@multigen.uucp> Organization: MultiGen, Inc. X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 31 May 1995 8:39:26 PST Subject: Re: Performer allocating tex Status: O Reply to: RE>Performer allocating texture mem >From: luebke@doodad.engr.sgi.com (David Luebke) >Message-Id: <199505302145.OAA22521@doodad.engr.sgi.com> >Subject: Performer allocating texture mem >To: info-performer@sgihub.corp.sgi.com (Performer-help mailing list) >Date: Tue, 30 May 1995 14:45:03 -0700 (PDT) > >What mechanism does Performer use to allocate texture memory? >We have RM5s and a flt database with a lot of textures, but after >loading about 12 megs it freezes up. My theory is that the texture >memory is getting fragmented (most of our textures are really >small, 16x16 or smaller) and that the loader is going into a loop >looking for a large enough chunk of memory to fit that next >texture. Is this plausible? If so what do I do about it? The Flight loader(s) rely upon the Performer application to download texture. They do not download texture directly. In perfly, for example, a call is made to pfuMakeTexList(3) after the scenegraph is loaded and then pfuDownloadTexList(3) is called to load (pfApplyTex(3)) texture memory (if any). If anything is stalling it's within pfApplyTex I would guess ... Why do you think that your problem is related to texture downloads? Can you load the same data base without texture (de-textured)? >Dave >-- >David Luebke >luebke@engr.sgi.com Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: 1-408-261-4118 FX: 1-408-247-4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Wed May 31 09:02:57 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id IAA09075; Wed, 31 May 1995 08:59:54 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id IAA09072; Wed, 31 May 1995 08:59:53 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16288; Wed, 31 May 95 08:59:52 -0700 Received: from vr1.engin.umich.edu by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id IAA16028; Wed, 31 May 1995 08:59:36 -0700 Received: by vr1.engin.umich.edu (940816.SGI.8.6.9/930416.SGI.AUTO) for info-performer@sgi.com id LAA28173; Wed, 31 May 1995 11:48:54 -0400 From: alf@vr1.engin.umich.edu (Alf Ritter) Message-Id: <199505311548.LAA28173@vr1.engin.umich.edu> Subject: Performer to Inventor Converter To: info-performer@sgi.sgi.com (Performer questions) Date: Wed, 31 May 1995 11:48:42 -0500 (EDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 826 Status: O Hi, I'm just starting to use Performer. I know that there are database import features in Performer to read Inventor files. Question: Are there any solutions already available to convert a Performer scenegraph into an Inventor structure (to save a Performer Scenegraph as an Inventor file) ? Any help would be appreciated Alf -- ============================================================================= Alf Ritter _/ _/ _/_/_/_/ alf@vr1.engin.umich.edu University of _/_/ _/ _/ Michigan _/ _/ _/ _/_/_/ "Life would be so much easier VR Lab _/_/_/_/ _/ _/ if we could just look at the (313) 763-7798 _/ _/ _/_/_/ _/ source code." ============================================================================= From guest Wed May 31 10:10:34 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id KAA09502; Wed, 31 May 1995 10:07:16 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id KAA09499; Wed, 31 May 1995 10:07:15 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA21562; Wed, 31 May 95 10:07:12 -0700 Received: from ben.britain.eu.net by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for id KAA26655; Wed, 31 May 1995 10:07:07 -0700 From: neil@mpread.co.uk Received: from mpread.mpread.co.uk by ben.britain.eu.net via UKIP with SMTP (PP) id ; Wed, 31 May 1995 18:06:46 +0100 Message-Id: <16715.9505311707@mpread.co.uk> To: info-performer@sgi.sgi.com Subject: Subscribe Date: Wed, 31 May 95 18:07:44 +0100 X-Mts: smtp Status: O Subscribe From guest Wed May 31 12:14:13 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA10034; Wed, 31 May 1995 12:10:42 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA10031; Wed, 31 May 1995 12:10:41 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00888; Wed, 31 May 95 12:10:40 -0700 Received: from relay3.UU.NET by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA17206; Wed, 31 May 1995 12:10:25 -0700 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQysdg11597; Wed, 31 May 1995 15:10:23 -0400 Received: from multigen.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 31 May 1995 15:10:22 -0400 Received: from MAIL_CENTER (QM 3.0) by multigen.uucp (UMCP\QM 2.0.1) id AA01350; Wed, 31 May 1995 11:09:41 PST Message-Id: <00581.2884763381.1350@multigen.uucp> Organization: MultiGen, Inc. X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 31 May 1995 10:19:36 PST Subject: Re: >memory problems Status: O Reply to: RE>>memory problems >Message-Id: <199505302357.QAA23013@surreal.asd.sgi.com> >To: robin@media.mit.edu >Cc: info-performer@sgi.com >Subject: Re: memory problems >In-Reply-To: Your message of "Tue, 30 May 95 18:34:42 EDT." > <9505302234.AA06095@media.mit.edu> >Date: Tue, 30 May 95 16:57:13 -0700 >From: Jim Helman > >There are no fixed limits on database size in Performer, >except for our default arena size of 256MB which should >be adequate for most scenes. > >> why would it work when drawing 100 items, but not 200? > >It could be that something moves in memory so that a read of >an unitialized varialble or a write to an incorrect location >causes no problem with one database, but drops core with >another. > >Check your code for unitialized variables and try running dbx >on the resulting core dump to see where the problem occurs. > >-jim This sounds very much like the Performer 1.2 pfHashTable internal memory corruption bug from last summer. A workaround Jim gave me was put into revision R14.1c, and later, of the OpenFlight loader. It was as follows: { extern void** _pfNameTable; _pfNameTable[ 2 ] = ( void* ) 0; /* clear "numResets" */ } This stub of code must be called fairly frequently while building a large scene graph with pfNodeName's. Regards, Marcus Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: 1-408-261-4118 FX: 1-408-247-4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Wed May 31 12:04:56 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA10001; Wed, 31 May 1995 12:01:13 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA09998; Wed, 31 May 1995 12:01:13 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA00197; Wed, 31 May 95 12:01:11 -0700 Received: from pike.cecer.army.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA16125; Wed, 31 May 1995 12:00:40 -0700 Received: from lincoln.assetplus (lincoln.cecer.army.mil [129.229.32.1]) by pike.cecer.army.mil (8.6.9/8.6.9) with SMTP id NAA08826 for ; Wed, 31 May 1995 13:31:13 -0500 Received: by lincoln.assetplus (5.0/SMI-SVR4) id AA00715; Wed, 31 May 1995 13:31:37 +0600 From: wallace@pike.cecer.army.mil (Jeff Wallace) Message-Id: <9505311831.AA00715@lincoln.assetplus> Subject: OOS96 CFP To: info-performer@sgi.sgi.com Date: Wed, 31 May 1995 13:31:31 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3322 Status: O Dear Performer Friends, I would love to have a session on object-oriented visual simulation, or anything your respective organizations do that involves state-of-the-art object-oriented simulation. Great hotel too! Regards, Jeff Wallace Program Chair OOS96 --------------------------------------------------------------- ANNOUNCEMENT AND CALL FOR PAPERS WMC 1996 - LaJolla, CA The Society for Computer Simulation [SCS] presents: Object-Oriented Simulation Conference part of the 1996 Western Multiconference on Computer Simulation January 14-17, 1996, The Hyatt Regency, LaJolla, CA The 1995 Object Oriented Simulation Conference of the 1995 WMC will be a the discussion and presentation of research papers in all aspects of the application of object-oriented technology to simulation modeling and analysis. Past OOS Conferences provided a mechanism by which researchers in the field have the ability to interact in a relaxed and productive atmosphere. Papers, and proposals for panel sessions or tutorials, related to Object-Oriented Simulation are invited. The following sessions have traditionally been held: - Manufacturing simulation - Languages and simulation frameworks - Military modeling and simulation All papers relating object-oriented technology, analysis, and design to simulation will be considered, and will be judged on content. Demonstration proposals are invited, and demonstration sessions will be scheduled based on interest. Deadlines: June 15, 1992 Submission of abstracts July 1, 1992 Notification of initial acceptance August 1, 1992 Draft copies due September 1, 1992 Notification of final, full paper acceptance September 30, 1992 Camera ready copies due at SCS (six 2 column pages) Abstracts and draft copies should be submitted electronically should be sent to either the general or program chair of the conference. Abstracts and drafts will be reviewed by the program committee members. Upon completion of review, suggestions for improvements will be communicated to the principal author. Submissions must clearly indicate the name, affiliation, address, phone number, and e-mail address of the primary author. Dr. Chell Roberts, OOS96 General Chairman Department of Industrial and Management Systems Engineering, ECG 303 Arizona State University Tempe, AZ 85287-5906 Phone: (602) 965-2567 FAX: (602) 965-8692 e-mail: atcqr@asuacad.bitnet Mr. Jeffrey Wallace, OOS96 Program Chair U.S. Army Construction Engineering Research Laboratories P.O. Box 9005 Champaign, IL 61826-9005 Phone : (217) 352-6511 Ext. 7233 FAX : (217) 373-6724 e-mail: wallace@pike.cecer.army.mil Program Committee: (These are the only ones you don't already have) Dr. David Bennett, Southern Illinois University - Carbondale Dr. Larry Peterson, Naval Research and Development Laboratory Mr. Bruce Fleming, Martin Marietta Manned Space Systems Mr. Curtis Lisle, The Institute for Simulation and Training, University of Central Florida Mr. Paul Wonnacott, Defense Research Agency, UK From guest Wed May 31 12:20:08 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA10062; Wed, 31 May 1995 12:16:23 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA10059; Wed, 31 May 1995 12:16:22 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA01145; Wed, 31 May 95 12:16:19 -0700 Received: from palladium.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id MAA17833; Wed, 31 May 1995 12:15:54 -0700 Received: from giraffe.asd.sgi.com by palladium.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id MAA06381; Wed, 31 May 1995 12:14:34 -0700 Received: from surreal.asd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for @sgihub.corp.sgi.com:alf@vr1.engin.umich.edu id AA01016; Wed, 31 May 95 12:13:17 -0700 Received: from localhost by surreal.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id MAA27874; Wed, 31 May 1995 12:13:17 -0700 Message-Id: <199505311913.MAA27874@surreal.asd.sgi.com> To: alf@vr1.engin.umich.edu (Alf Ritter) Cc: info-performer@sgi.sgi.com (Performer questions) Subject: Re: Performer to Inventor Converter In-Reply-To: Your message of "Wed, 31 May 95 11:48:42 CDT." <199505311548.LAA28173@vr1.engin.umich.edu> Date: Wed, 31 May 95 12:13:16 -0700 From: Jim Helman Status: O Gavin Bell has written some code that traverses a Performer scene graph and writes out an Inventor file, although not all Performer features are supported. We'll probably be distributing a finished version of this sometime after 2.0. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed May 31 12:58:16 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id MAA10222; Wed, 31 May 1995 12:51:39 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id MAA10219; Wed, 31 May 1995 12:51:38 -0700 Received: from clubted.csd.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA03046; Wed, 31 May 95 12:51:37 -0700 Received: by clubted.csd.sgi.com (940816.SGI.8.6.9/911001.SGI) for info-performer id MAA07430; Wed, 31 May 1995 12:51:35 -0700 From: "Cami Crofton" Message-Id: <9505311251.ZM7428@clubted.csd.sgi.com> Date: Wed, 31 May 1995 12:51:35 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@clubted.csd.sgi.com Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O unsubscribe From guest Wed May 31 13:48:51 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id NAA10419; Wed, 31 May 1995 13:43:07 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id NAA10416; Wed, 31 May 1995 13:43:06 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA06543; Wed, 31 May 95 13:43:04 -0700 Received: from pike.cecer.army.mil by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id NAA00329; Wed, 31 May 1995 13:42:48 -0700 Received: from lincoln.assetplus (lincoln.cecer.army.mil [129.229.32.1]) by pike.cecer.army.mil (8.6.9/8.6.9) with SMTP id PAA10385 for ; Wed, 31 May 1995 15:42:46 -0500 Received: by lincoln.assetplus (5.0/SMI-SVR4) id AA00754; Wed, 31 May 1995 15:43:08 +0600 From: wallace@pike.cecer.army.mil (Jeff Wallace) Message-Id: <9505312043.AA00754@lincoln.assetplus> Subject: OOS96 CFP typo To: info-performer@sgi.sgi.com Date: Wed, 31 May 1995 15:43:06 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 172 Status: O Performer Friends, Clearly(as math profs say), the 1992 in the CFP for OOS96 should have been 1995. No jokes, just abstracts, please... Jeff Wallace OOS96 Program Chair From guest Wed May 31 15:36:17 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id PAA11139; Wed, 31 May 1995 15:26:57 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id PAA11136; Wed, 31 May 1995 15:26:50 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA16744; Wed, 31 May 95 15:26:49 -0700 Received: from ligsg10.epfl.ch by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id PAA21756; Wed, 31 May 1995 15:26:33 -0700 Received: by ligsg10.epfl.ch (Smail3.1.29.1 #28) id m0sGwDa-0000MrC; Thu, 1 Jun 95 00:26 MET DST From: "Fernando D. Mato Mira" Message-Id: <9506010026.ZM2231@lig.di.epfl.ch> Date: Thu, 1 Jun 1995 00:26:26 +0200 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfDCS in 2.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O Hello, I hope there'll be something analogous to pfGetDCSMat, but returning a const* in 2.0.. From guest Wed May 31 18:18:55 1995 Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for info-performer-dist id SAA12045; Wed, 31 May 1995 18:15:47 -0700 Return-Path: Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id SAA12042; Wed, 31 May 1995 18:15:47 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP (931110.SGI/930416.SGI) for info-performer@holodeck.asd.sgi.com id AA25995; Wed, 31 May 95 18:15:46 -0700 Received: from sgihub.corp.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for id SAA25324; Wed, 31 May 1995 18:15:28 -0700 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (950413.SGI.8.6.12/911001.SGI) for id SAA23628; Wed, 31 May 1995 18:15:19 -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 AA25976; Wed, 31 May 95 18:15:18 -0700 Received: by tubes.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) id SAA20381; Wed, 31 May 1995 18:12:54 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <199506010112.SAA20381@tubes.asd.sgi.com> Subject: Re: pfDCS in 2.0 To: guest (Fernando D. Mato Mira) Date: Wed, 31 May 95 18:12:53 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9506010026.ZM2231@lig.di.epfl.ch>; from "Fernando D. Mato Mira" at Jun 1, 95 12:26 am X-Mailer: ELM [version 2.3 PL8] Status: O > > Hello, > > I hope there'll be something analogous to pfGetDCSMat, but > returning a const* in 2.0.. > > > Done.