From guest  Wed Apr  1 00:47:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA25177 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 00:24:31 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id AAA25150 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 00:24:30 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA6361416
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 00:24:29 -0800 (PST)
Received: from flaska.autosim.no (port01.nord.eunet.no [195.1.163.162]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id AAA07972
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 00:24:27 -0800 (PST)
	mail_from (inge_e_henriksen@hotmail.com)
Received: from david by flaska.autosim.no with smtp
	(Linux Smail3.2.0.92 #1) id m0yKJnW-000vurC; Wed, 1 Apr 1998 11:27:06 +0200 (MET DST)
Message-ID: <000301bd5d47$afd9a720$2902a8c0@david.autosim.no>
Reply-To: "Inge E.Henriksen" <inge_e_henriksen@hotmail.com>
From: "Inge E.Henriksen" <inge_e_henriksen@hotmail.com>
To: "info-perfomer mailing list" <info-performer@sgi.com>
Subject: Market test
Date: Wed, 1 Apr 1998 10:25:10 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Status: O

Hello Performers
------------------------
After some years in the visual simulation business I am planning to sell my
services as a freelance MultiGen modeller on a world-wide basis. If this
might be interesting for your company please then please e-mail me.

Thank you for your time.


Greetings from
---------------------------------------------------------------------------
Inge E.Henriksen, Database designer
P.B.2303, 9001 Tromsoe, Norway
Tlf.+47 77 65 64 32
Mailto:inge_e_henriksen@hotmail.com
---------------------------------------------------------------------------
*****************************************John.3.16-21
---------------------------------------------------------------------------


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 01:29:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA25248 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 01:06:16 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id BAA25221 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 01:06:15 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id BAA4330642
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 01:06:14 -0800 (PST)
Received: from mailgate.urz.uni-wuppertal.de (mailgate.urz.uni-wuppertal.de [132.195.20.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id BAA16759
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 01:06:11 -0800 (PST)
	mail_from (zeise@uni-wuppertal.de)
Received: from wetnt9 (wetnt9.elektro.uni-wuppertal.de [132.195.29.97])
	by mailgate.urz.uni-wuppertal.de (8.8.8/8.8.8) with SMTP id LAA20219
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 11:06:03 +0200 (MDT)
Message-ID: <004d01bd5d4c$decc23a0$611dc384@wetnt9.elektro.uni-wuppertal.de>
From: "Wilfried Zeise" <zeise@uni-wuppertal.de>
To: "info-performer" <info-performer@sgi.com>
Subject: Problems reading the z-buffer again; "pre-condition" for glReadPixels?
Date: Wed, 1 Apr 1998 11:02:03 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Status: O

Hi pfAll:

Thanks to Mario and Rob for their answers regarding my Z-buffer problem. I
am using IRIX 6.2, so multisampling shouldn't be the problem for
glReadPixels.

When I use glReadPixels(...,GL_DEPTH_COMPONENT,...)  in a simple Performer
program, like simple.c in the programming guide, it works fine. I want to
use glReadPixels in perfly, because we made some extensions to this program.
In perfly this command doesn't work. It gives me for every pixel the Z-value
1.0!

Is there a kind of "pre-condition" for the use of glReadPixels with
GL_DEPTH_COMPONENT? Which part of perfly prevents me from reading the
Z-buffer? Is there an OpenGL or Performer command, that forbids to read the
depth buffer?

Thanks

Wilfried


Wilfried Zeise
University of Wuppertal


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 05:43:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA25691 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 05:17:16 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA25664 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 05:17:13 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA6407673
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 05:17:12 -0800 (PST)
Received: from gatekeeper.bvr.co.il (gatekeeper.bvr.co.il [194.90.44.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id FAA02865
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 05:17:08 -0800 (PST)
	mail_from (avib@bvr.co.il)
Received: (from uucp@localhost) by gatekeeper.bvr.co.il (8.6.12/8.6.9) id OAA06512 for <@gatekeeper.bvr.co.il:info-performer@sgi.com>; Wed, 1 Apr 1998 14:05:24 GMT
Received: from unknown(192.114.85.195) by gatekeeper.bvr.co.il via smap (V1.3)
	id sma006507; Wed Apr  1 18:05:22 1998
Received: from bvr.co.il by michelle.bvr.co.il via ESMTP (950413.SGI.8.6.12/931108.SGI.AUTO.ANONFTP)
	for <info-performer@sgi.com> id QAA14082; Wed, 1 Apr 1998 16:16:58 +0200
Sender: avib@bvr.co.il
Message-ID: <35224C59.F93DA01E@bvr.co.il>
Date: Wed, 01 Apr 1998 16:16:58 +0200
From: Avi Bar-Zeev <avib@bvr.co.il>
Organization: Wolfchild/3D
X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX64 6.4 IP27)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Interesting News
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Found this yesterday on info-bytes. Scary stuff
for Performer enthusiasts...

----------------------------------

Mountainview, March 30, 1998 [AP] -- In a press
release, Silicon Graphics (SGI) today announced
that it will be selling off it's popular
Performer Real-Time development toolkit to
interested third parties.

The move comes amidst speculation and innuendo
regarding two recent developments at SGI. First,
rumors of a combined Microsoft/SGI rendering API,
code named, alternatively, "MicroGraphics" and
"SiliSoft" has made the Performer API essentially
obsolete in the eyes of many.

Second, and more importantly to users, the Performer
team has been caught red-handed, as it were,
manipulating polygonal performance numbers. The
scheme, according to industry experts, counted
next frame's rendered polygons in the current
frame's count. And, according to one industry
analysist, "this seems to be a wide-spread trend
at SGI, counting future results in today's
figures."

Details of the sale are not yet forthcoming. But,
according to sources, the buyer is none other
than Ron Popeil, founder of RonCo International,
makers of direct-marketed household devices.

Popeil was not available for immediate comment,
but secret footage of a forthcoming informercial
was obtained, containing key Performer team
members and Popeil in an audience-style setting,
espousing the benefits of using Performer and a
Onyx Rack for drying fruits and vegetables.

A smaller version was shown using an O2 which was
capable of cooking a slice of Canadian bacon in
it's convenient auto-open tray. The same device would
play household audio CDs.

The new unit, according to sources, will be named
Out-Performer and will attempt a more mainstream
consumer appeal, including such features as
tuning Onyx temperature for optimal cooking and
drying time, three-hundred low monthly payments,
and the all-important big-red-stop-switch. The
device is promised to be UL listed and approved
and may come with extra CPUs, but only for a
limited time.
----------------------------------


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 05:56:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA25726 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 05:30:49 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA25699 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 05:30:45 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA6117870
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 05:30:44 -0800 (PST)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA05295
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 05:30:42 -0800 (PST)
	mail_from (sbaker@link.com)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id HAA00989; Wed, 1 Apr 1998 07:29:43 -0600 (CST)
Date: Wed, 1 Apr 1998 07:30:08 -0600 (CST)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Wilfried Zeise <zeise@uni-wuppertal.de>
cc: info-performer <info-performer@sgi.com>
Subject: Re: Problems reading the z-buffer again; "pre-condition" for glReadPixels?
In-Reply-To: <004d01bd5d4c$decc23a0$611dc384@wetnt9.elektro.uni-wuppertal.de>
Message-ID: <Pine.SGI.3.96.980401072805.10518F-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Wed, 1 Apr 1998, Wilfried Zeise wrote:

> Hi pfAll:
> 
> Thanks to Mario and Rob for their answers regarding my Z-buffer problem. I
> am using IRIX 6.2, so multisampling shouldn't be the problem for
> glReadPixels.
 
I thought glReadPixels for a multisampled image was only possible on Inf.Reality
graphics - I don't think it's anything to do with the IRIX version. An RE2
(for example) can't glReadPixels a multisampled image even under IRIX 6.x.
IIRC, it's a hardware issue.

Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 06:29:47 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA25879 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 06:12:21 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA25852 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 06:12:20 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA5907880
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 06:12:20 -0800 (PST)
Received: from narnia.aero.swri.edu (narnia.aero.swri.edu [129.162.90.12]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA15755
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 06:12:18 -0800 (PST)
	mail_from (mcoleman@txdirect.net)
Received: from txdirect.net (pants.aero.swri.edu [129.162.90.59])
	by narnia.aero.swri.edu (8.8.7/8.8.7) with ESMTP id IAA23549;
	Wed, 1 Apr 1998 08:13:14 -0600
Message-ID: <35224B3C.83DEA18C@txdirect.net>
Date: Wed, 01 Apr 1998 08:12:12 -0600
From: "Michael A. Coleman" <mcoleman@txdirect.net>
Reply-To: mcoleman@txdirect.net
Organization: Drunk Works Home Brewery
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Avi Bar-Zeev <avib@bvr.co.il>
CC: info-performer@sgi.com
Subject: Re: Interesting News
References: <35224C59.F93DA01E@bvr.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Avi Bar-Zeev wrote:
> 
> Found this yesterday on info-bytes. Scary stuff
> for Performer enthusiasts...
> 

Nice try.

MAC
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 06:46:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA26023 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 06:35:31 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA25996 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 06:35:30 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA6338820
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 06:35:30 -0800 (PST)
Received: from ptah.cra.com (ptah.cra.com [205.181.6.81]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA22070
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 06:35:28 -0800 (PST)
	mail_from (kharper@cra.com)
Received: by ptah.opensesame.com with Internet Mail Service (5.0.1460.8)
	id <2AYY9TPY>; Wed, 1 Apr 1998 09:40:40 -0500
Message-ID: <D43D187FE8BDD11186DB00A0C986C1ED6CB1@ptah.opensesame.com>
From: Karen Harper <kharper@cra.com>
To: info-performer@sgi.com
Subject: Need help with X input handling in Performer 2.2
Date: Wed, 1 Apr 1998 09:40:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Status: O


Performers,

> I'm running Performer 2.2 on an Octane (Irix 6.4).  I'm having trouble
> using X event handling.  My code follows the following sequence:
> 
> pfInit();
> pfuInit();
> pfiInit();
> pfMultiprocess( PFMP_DEFAULT );
> pfConfig();
> pipe = pfGetPipe(0);
> pipeWindow = new pfPipeWindow( pipe);
> pipeWindow->setWinType(PFPWIN_TYPE_X);
> pipeWindow->open();
> pfuInitInput( pipeWindow, PFUINPUT_NOFORK_X);
> (I've also tried pfuInitInput(pipeWindow, PFUINPUT_X))
> 
> .
> .
> .
> 
> 
> What seems to happen is that sometimes I'll be able to process keyboard
> inputs just fine, and sometimes they're ignored completely.  The program
> works just fine otherwise, but it's quite annoying when it ignores
> keyboard
> inputs.  The Performer documentation says two different things in
> different
> places about the placement of the pfuInit command.  I tried both -- same
> thing happens either way.
> 
> I'm compiling the C++ code with the -n32 option, with debugging (-g)
> turned
> on.
> 
> Has anybody seen this behavior before, and is there a solution for it?
> 
> Thanks.
> 
Karen
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 07:26:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA26243 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 07:09:15 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA26216 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 07:09:10 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA6427109
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 07:09:09 -0800 (PST)
Received: from bhole2.cae.ca (postit.cae.ca [142.39.200.51]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA02762
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 07:09:08 -0800 (PST)
	mail_from (mayer@poster.cae.ca)
Received: 	id JAA01288; Wed, 1 Apr 1998 09:43:52 -0500
Received: by gateway id AA32846; Wed, 1 Apr 1998 09:30:58 -0500
Received: by gateway id JAA12749; Wed, 1 Apr 1998 09:35:47 -0500
Sender: mayer@poster.cae.ca
Message-Id: <352250C3.59E2@cae.ca>
Date: Wed, 01 Apr 1998 09:35:47 -0500
From: Sylvain Mayer <mayer@poster.cae.ca>
Organization: CAE Electronics Ltd
X-Mailer: Mozilla 3.01SC-SGI (X11; I; IRIX 6.2 IP22)
Mime-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Interesting News
References: <35224C59.F93DA01E@bvr.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Avi Bar-Zeev wrote:
> 
> Found this yesterday on info-bytes. Scary stuff
> for Performer enthusiasts...
> 
> ----------------------------------
> 
> Mountainview, March 30, 1998 [AP] -- In a press
> release, Silicon Graphics (SGI) today announced
> that it will be selling off it's popular
> Performer Real-Time development toolkit to
> interested third parties.

Damn I almost read it all.  I forgot we are april 1st :-)

-- 
Sylvain Mayer, 3D Graphics Developer
CAE Electronics Ltd. (http://www.cae.ca)
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 09:28:12 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA26691 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 09:08:44 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA26664 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 09:08:42 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA6418642
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 09:08:32 -0800 (PST)
Received: from artemis.rus.uni-stuttgart.de (artemis.rus.uni-stuttgart.de [129.69.18.28]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA16585
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 09:08:30 -0800 (PST)
	mail_from (weiskopf@tat.physik.uni-tuebingen.de)
Received: from visbl.rus.uni-stuttgart.de (visbl.rus.uni-stuttgart.de [129.69.3.121])
	by artemis.rus.uni-stuttgart.de (8.8.7/8.8.7) with ESMTP id TAA27659;
	Wed, 1 Apr 1998 19:08:21 +0200 (MET DST)
	env-from (weiskopf@tat.physik.uni-tuebingen.de)
Received: from tat.physik.uni-tuebingen.de (localhost [127.0.0.1]) by visbl.rus.uni-stuttgart.de (8.8.3/8.8.0) with ESMTP id TAA06323; Wed, 1 Apr 1998 19:08:20 +0200 (DST)
Sender: daniel@visbl.rus.uni-stuttgart.de
Message-ID: <35227483.AB0D1D0A@tat.physik.uni-tuebingen.de>
Date: Wed, 01 Apr 1998 19:08:19 +0200
From: Daniel Weiskopf <weiskopf@tat.physik.uni-tuebingen.de>
Organization: TAT, University of Tuebingen
X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 5.3 IP12)
MIME-Version: 1.0
To: Glenn Waldron <gwaldron@peril.com>
CC: info-performer@sgi.com
Subject: Re: Problem with pfFlux and geosets
References: <3512757C.F7DE5C3C@peril.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Glenn Waldron wrote:
> 
> I have a terrain model loaded, and I'm trying to convert the
> coordinate lists in the pfGeoSets into pfFluxes.  I'm following
> the example in /usr/share/Performer/src/pguide/libpf/C++/morph_engine.C.
> 
> After changing the original coordinate lists to pfFluxes, the
> terrain appears with all it's coordinates randomly scrambled!
> Here's the code for each pfGeoSet found in the tree:
> 
>     pfGeoSet*       gset;
>     pfVec3*         coords;
>     ushort*         icoords;
> 
>     ...
>     gset = geode->getGSet(i);
>     gset->getAttrLists(PFGS_COORD3, (void**)&coords, &icoords);
> 
>     pfFlux* flux = new pfFlux(pfGetSize(coords), PFFLUX_DEFAULT_NUM_BUFFERS);
>     flux->initData(coords);
>     gset->setAttr(PFGS_COORD3, PFGS_PER_VERTEX, flux, icoords);
> 
> Any help is appreciated!  thanks! -g.

I have the same problem; since no one has given an answer, I'd
like to repost the problem.

Interestingly, the scrambled behavior depends on the kind of
multiprocessor mode used, e.g. there is different output with
pfMultiprocess(PFMP_APP_CULL_DRAW) and pfMultiprocess(PFMP_APPCULLDRAW),
respectively. 

TIA

-- 
Daniel Weiskopf
weiskopf@tat.physik.uni-tuebingen.de
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 10:26:45 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA26899 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 10:15:27 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA26872 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 10:15:24 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA6483386
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 10:15:19 -0800 (PST)
Received: from aleve.media.mit.edu (aleve.media.mit.edu [18.85.2.171]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA15064
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 10:15:13 -0800 (PST)
	mail_from (kbrussel@media.mit.edu)
Received: from kangaroo.media.mit.edu (kangaroo.media.mit.edu [18.85.16.12])
	by aleve.media.mit.edu (8.8.7/ML970927) with ESMTP id NAA06906;
	Wed, 1 Apr 1998 13:14:58 -0500 (EST)
Received: (from kbrussel@localhost) by kangaroo.media.mit.edu (8.6.11/8.6.11) id NAA07885; Wed, 1 Apr 1998 13:14:50 -0500
Date: Wed, 1 Apr 1998 13:14:50 -0500
Message-Id: <199804011814.NAA07885@kangaroo.media.mit.edu>
From: Kenneth B Russell <kbrussel@media.mit.edu>
To: Performer Enthusiasts <info-performer@sgi.com>
CC: gwaldron@peril.com, Daniel Weiskopf <weiskopf@tat.physik.uni-tuebingen.de>
In-reply-to: <35227483.AB0D1D0A@tat.physik.uni-tuebingen.de> (message from
	Daniel Weiskopf on Wed, 01 Apr 1998 19:08:19 +0200)
Subject: Re: Problem with pfFlux and geosets
Reply-to: kbrussel@media.mit.edu
Status: O


> > I have a terrain model loaded, and I'm trying to convert the
> > coordinate lists in the pfGeoSets into pfFluxes.  I'm following
> > the example in /usr/share/Performer/src/pguide/libpf/C++/morph_engine.C.
> > 
> > After changing the original coordinate lists to pfFluxes, the
> > terrain appears with all it's coordinates randomly scrambled!
>
> I have the same problem; since no one has given an answer, I'd
> like to repost the problem.
> 
> Interestingly, the scrambled behavior depends on the kind of
> multiprocessor mode used, e.g. there is different output with
> pfMultiprocess(PFMP_APP_CULL_DRAW) and pfMultiprocess(PFMP_APPCULLDRAW),
> respectively. 

I found and reported a similar problem a couple of months ago but
got no responses. There seems to be a bug in pfGeoSet in
Performer 2.2 in which if ANY attribute is "fluxed", ALL
attributes must be (this includes colors). Therefore if you are
specifying your color using a pfMaterial, you must instead
specify a per-vertex PFGS_COLOR4 attribute, which MUST be
allocated using a pfFlux (not just pfMalloc'ed). This happens
both using pfFluxes and the (now-obsoleted) pfCycleBuffer/pfMorph
mechanism. I hope this explains your problem.

I've attached my example which illustrates this bug. It would be
nice if someone from SGI acknowledged receipt of this bug report.
I spent quite a while tracking it down.

Thanks,

-Ken


__________________________________________________________________________
Kenneth B. Russell               Synthetic Characters Group, MIT Media Lab
kbrussel@media.mit.edu                  http://www.media.mit.edu/~kbrussel


----
/*
 * Copyright 1995, Silicon Graphics, Inc.
 * ALL RIGHTS RESERVED
 *
 * UNPUBLISHED -- Rights reserved under the copyright laws of the United
 * States.   Use of a copyright notice is precautionary only and does not
 * imply publication or disclosure.
 *
 * U.S. GOVERNMENT RESTRICTED RIGHTS LEGEND:
 * Use, duplication or disclosure by the Government is subject to restrictions
 * as set forth in FAR 52.227.19(c)(2) or subparagraph (c)(1)(ii) of the Rights
 * in Technical Data and Computer Software clause at DFARS 252.227-7013 and/or
 * in similar or successor clauses in the FAR, or the DOD or NASA FAR
 * Supplement.  Contractor/manufacturer is Silicon Graphics, Inc.,
 * 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311.
 *
 * Permission to use, copy, modify, distribute, and sell this software
 * and its documentation for any purpose is hereby granted without
 * fee, provided that (i) the above copyright notices and this
 * permission notice appear in all copies of the software and related
 * documentation, and (ii) the name of Silicon Graphics may not be
 * used in any advertising or publicity relating to the software
 * without the specific, prior written permission of Silicon Graphics.
 *
 * THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY
 * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 *
 * IN NO EVENT SHALL SILICON GRAPHICS BE LIABLE FOR ANY SPECIAL,
 * INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY
 * DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
 * WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY
 * THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE
 * OR PERFORMANCE OF THIS SOFTWARE.
 *
 * morph.c++: Performer program to demonstrate use of pfMorph node.
 *        Based on simple.c
 *
 * $Revision: 1.5 $ $Date: 1995/11/22 14:36:00 $ 
 *
 */

#include <stdlib.h>
#include <math.h>
#include <Performer/pf.h>
#include <Performer/pfdu.h>
#include <Performer/pr/pfLinMath.h>
#include <Performer/pr/pfGeoSet.h>
#include <Performer/pr/pfGeoState.h>
#include <Performer/pr/pfMaterial.h>
#include <Performer/pr/pfLight.h>
#include <Performer/pf/pfGeode.h>
#include <Performer/pf/pfDCS.h>
#include <Performer/pf/pfScene.h>
#include <Performer/pf/pfMorph.h>
#include <Performer/pf/pfLightSource.h>
#include <Performer/pf/pfChannel.h>
#include <Performer/pf/pfPipeWindow.h>

// Bug in pfGeoSet, Performer 2.2.
// Demonstrated by Kenneth B. Russell (kbrussel@media.mit.edu)

// Switches for the two instances of the bug.
#define MORPH_NORMALS		// Turns on morphing of normals
#define MORPH_COORDS		// Turns on morphing of coordinates
#define COLORS_AS_CBUF		// Makes colors a CycleBuffer. Turning 
				// this off makes colors malloced using
				// pfMalloc. But see NOTE: below.
#define NO_COLORS		// Gives GeoSet no colors (inherits from
				// pfMaterial)

// Combinations						Bug?
//  N_C							No
//  (M_N || M_C) && (C_A_C && N_C)			YES

// Neither of these attempted workarounds work properly.  The only
// workaround, therefore, is to specify per-vertex colors in every
// GeoSet for which either the normals or the coordinates are morphing
// (either using the pfMorph node OR the pfFlux/pfEngine mechanism).
//#define OVERALL_COLORS
//#define PER_PRIM_COLORS

int		nSph;
pfCycleBuffer	*cbuf;

/*------------------------------------------------------------------*/

static void
breatheMorph(pfMorph *morph, double t)
{
    float	s = (sinf(t) + 1.0f) / 2.0f;
    float	weights[2];
    int		i;

    weights[0] = s;
    weights[1] = 1.0f - s;

    morph->setWeights(-1, weights);
}

static pfMorph*
initMorph(void)
{
    pfGeoSet	*gset;
    pfGeode	*geode;
    pfGeoState	*gstate;
    pfMaterial	*mtl;
    pfMorph	*morph;
    ushort	*icoords, *inorms;
    pfVec3	*coords, *ncoords, *norms, *nnorms;
    pfVec4	*colors;
    float	*srcs[2];
    int		i;
    void	*arena = pfGetSharedArena();

    morph = new pfMorph;
    geode = new pfGeode;
    gset = pfdNewSphere(400, arena);
    gstate = new(arena) pfGeoState;

    mtl = new(arena) pfMaterial;
    mtl->setColor(PFMTL_DIFFUSE, 0.0f, 1.0f, 1.0f); 
    mtl->setColor(PFMTL_SPECULAR, 1.0f, 1.0f, 1.0f); 
    mtl->setColorMode(PFMTL_BOTH, PFMTL_CMODE_AD);
    mtl->setShininess(32);

    gstate->setAttr(PFSTATE_FRONTMTL, mtl);
    gstate->setMode(PFSTATE_ENLIGHTING, 1);
    gset->setGState(gstate);

    geode->addGSet(gset);
    morph->addChild(geode);

    /*
     * NULL forces recomputation of bound. Force it to be static 
     * to avoid expensive recomputation. Static bound should encompass
     * the extent of all morph possibilities. 
    */
    gset->setBound(NULL, PFBOUND_STATIC);
    geode->setBound(NULL, PFBOUND_STATIC);

    gset->getAttrLists(PFGS_COORD3, (void**)&coords, &icoords);
    gset->getAttrLists(PFGS_NORMAL3, (void**)&norms, &inorms);
    nSph = pfGetSize(coords) / sizeof(pfVec3);

    cbuf = new(arena) pfCycleBuffer(nSph * sizeof(pfVec4));

    ncoords = (pfVec3 *)pfMalloc(pfGetSize(coords), arena);
    nnorms = (pfVec3 *)pfMalloc(pfGetSize(norms), arena);

#ifdef COLORS_AS_CBUF
    colors = (pfVec4*) cbuf->getCurData();
#else
    colors = (pfVec4*) pfMalloc(nSph * sizeof(pfVec4));
#endif
    for (i = 0; i < nSph; i++)
      {
	colors[i].set(0.0f, 1.0f, 1.0f, 1.0f);
	ncoords[i].scale(2.0f, coords[i]);
	nnorms[i] = norms[i];
      }
    /* Set all pfCycleMemories to the same colors */
    cbuf->init(cbuf->getCurData());

#ifndef NO_COLORS
# ifdef COLORS_AS_CBUF
    gset->setAttr(PFGS_COLOR4, PFGS_PER_VERTEX, 
		  (void*)cbuf, NULL);
# else
    // NOTE: this DOES work if
    //   colors = (pfVec4*) cbuf->getCurData();
    gset->setAttr(PFGS_COLOR4, PFGS_PER_VERTEX, 
		  (void*)colors, NULL);
# endif
#endif

#ifdef OVERALL_COLORS
    pfCycleBuffer *tmpBuf = new(arena) pfCycleBuffer(sizeof(pfVec4));
    pfVec4 *tmpColors = (pfVec4 *) cbuf->getCurData();
    tmpColors[0].set(0.0f, 1.0f, 0.0f, 1.0f);
    cbuf->init(cbuf->getCurData());
    gset->setAttr(PFGS_COLOR4, PFGS_OVERALL, tmpBuf, NULL);
#endif

#ifdef PER_PRIM_COLORS
    int numPrims = gset->getNumPrims();
    pfCycleBuffer *tmpBuf = new(arena) pfCycleBuffer(numPrims * sizeof(pfVec4));
      
    pfVec4 *tmpColors = (pfVec4 *) cbuf->getCurData();
    for (int q = 0; q < numPrims; q++)
      tmpColors[q].set(0.0f, 1.0f, 0.0f, 1.0f);
    cbuf->init(cbuf->getCurData());
    gset->setAttr(PFGS_COLOR4, PFGS_PER_PRIM, tmpBuf, NULL);
#endif

#ifdef MORPH_COORDS
    /* Morph attribute 0 is coordinates */
    srcs[0] = (float*)coords; 
    srcs[1] = (float*)ncoords;
    morph->setAttr(0, 3, nSph, NULL, 2, srcs, NULL, NULL);

    gset->setAttr(PFGS_COORD3, PFGS_PER_VERTEX, 
		  (void*)morph->getDst(0), icoords);
#endif

#ifdef MORPH_NORMALS
    /* Morph attribute 1 is normals */
    srcs[0] = (float*)norms;
    srcs[1] = (float*)nnorms;
    morph->setAttr(1, 3, nSph, NULL, 2, srcs, NULL, NULL);

    gset->setAttr(PFGS_NORMAL3, PFGS_PER_VERTEX, 
		  (void*)morph->getDst(1), inorms);
#endif

    return morph;
}

void 
OpenPipeWin (pfPipeWindow *pw)
{
    pw->open();
    (new pfLightModel)->apply();
}

void 
DrawChannel (pfChannel *chan, void *data)
{
    pfVec4	clr;

    clr.set(.2f, .2f, .2f, 1.0f); 
    pfClear(PFCL_COLOR|PFCL_DEPTH, &clr);
    pfDraw();
}

int
main (int argc, char *argv[])
{
    double     t = 0.;
    pfScene     *scene;
    pfDCS	*morphDCS;
    pfMorph	*morph;
    pfPipe      *p;
    pfPipeWindow *pw;
    pfChannel   *chan;
    pfSphere 	bsphere;
    pfCoord	view;
    pfLightSource	*ls;

    /* Initialize Performer */
    pfInit();	

    /* Use default multiprocessing mode based on number of
     * processors.
     */
    pfMultiprocess(PFMP_DEFAULT);

    /* Configure multiprocessing mode and start parallel
     * processes.
     */
    pfConfig();			

    /* Create and attach morph to a pfScene. */
    scene = new pfScene;
    morphDCS = new pfDCS;
    morph = initMorph();
    morphDCS->addChild(morph);
    scene->addChild(morphDCS);

    /* determine extent of scene's geometry */
    scene->getBound(&bsphere);

    /* Configure and open GL window */
    p = pfGetPipe(0);
    pw = new pfPipeWindow(p);
    pw->setName(argv[0]);
    pw->setConfigFunc(OpenPipeWin);
    pw->setOriginSize(0, 0, 500, 500);
    pw->config();

    /* Create and configure a pfChannel. */
    chan = new pfChannel(p);
    chan->setScene(scene);
    chan->setNearFar(1.0f, 10.0f * bsphere.radius);
    chan->setFOV(45.0f, 0.0f);
    view.xyz = bsphere.center;
    view.xyz[PF_Y] -= 3.0f * bsphere.radius;
    view.hpr.set(0.0f, 0.0f, 0.0f); 
    chan->setView(view.xyz, view.hpr);

    chan->setTravFunc(PFTRAV_DRAW, DrawChannel);

    /* Create a pfLightSource and attach it to scene. */
    ls = new pfLightSource;
    ls->setPos(view.xyz[0], view.xyz[1], view.xyz[2], 1.0f); 
    scene->addChild(ls);

    /* Simulate for twenty seconds. */
    while (1)
    {
	pfMatrix	mat;

	t = pfGetTime();

	/* Update morph */
	breatheMorph(morph, t);

	/* Initiate cull/draw for this frame. */
	pfFrame();		
    }

    /* Terminate parallel processes and exit. */
    pfExit();

    return 0;
}
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 15:18:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA28806 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 15:12:54 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA28779 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 15:12:52 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA6638982
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 15:12:51 -0800 (PST)
Received: from archimedes.vislab.navy.mil (archimedes.chinalake.navy.mil [129.131.31.8]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA16274
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 15:12:46 -0800 (PST)
	mail_from (jan@archimedes.vislab.navy.mil)
Received: (jan@localhost) by archimedes.vislab.navy.mil (8.7.5/8.x-CL-SOS5.3) id PAA28898 for info-performer@sgi.com; Wed, 1 Apr 1998 15:21:17 -0800 (PST)
From: Jan Barglowski <jan@archimedes.vislab.navy.mil>
Posted-Date: Wed, 1 Apr 1998 15:21:17 -0800 (PST)
Message-Id: <199804012321.PAA28898@archimedes.vislab.navy.mil>
Subject: C++ cliptexures...
To: info-performer@sgi.com
Date: Wed, 1 Apr 1998 15:21:17 -0800 (PST)
X-Mailer: ELM [version 2.4 PL24 ME8b]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

Performers:

I've created a virtual cliptexure callback that works when used in
conjunction with clipfly.  When I took this function and put it 
into perfly, my virtual cliptextures no longer work!  I've printed
out the values for VirtualLODOffset, NumEffectiveLevels, and LODRange
and they are identical for both programs.

My symptoms are a rapid sharpening/blurring of the virtual cliptexture
when zooming in or out towards it.  It doesn't seem to matter what
speed I zoom at.  Since the numbers calculated for the above parameters
work with clipfly, I'm assuming I'm doing the calculations correctly.
And when I comment out the tile-by-tile cliptexture updates, the 
cliptexture acts as if it's on Level=0.

I think this is one of two things:
1) Clipfly does something for virtual cliptextures that perfly
   doesn't.  And I can't find what this is!  I looked at the README
   file for clipfly, and the consideration for viewpoint update
   shouldn't cause this (am I right?).  The only thing I can figure
   is some of the parameters that control cliptextures are getting
   some (important) initialization in clipfly.  Yet I look at 
   virtcliptexture.c and don't see a lot of these values getting
   set at all.  Any ideas for what I'm missing?
2) the C++ cliptexture functions don't work, but I'd hate to think
   this is the case.  Still, anyone do virtual cliptextures with
   C++ bindings out there?

Any hints/help/insight will be appreciated!

jan

-- 
Jan Anthony Barglowski	              jan@chinalake.navy.mil
Real-time Computer Graphics           http://www1.ridgecrest.ca.us/~jan
Naval Air Warfare Center, China Lake  (760) 927-1057
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 16:37:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA29041 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 16:24:26 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA29014 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 16:24:24 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA6569326
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 16:24:23 -0800 (PST)
Received: from jeeves.icemt.iastate.edu (jeeves.icemt.iastate.edu [129.186.232.200]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA13417
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 16:24:21 -0800 (PST)
	mail_from (holly@icemt.iastate.edu)
Received: from snow.icemt.iastate.edu (snow.icemt.iastate.edu [129.186.232.46]) by jeeves.icemt.iastate.edu (951211.SGI.8.6.12.PATCH1042/8.6.12) with ESMTP id SAA06733 for <info-performer@sgi.com>; Wed, 1 Apr 1998 18:24:19 -0600
Received: from icemt.iastate.edu (localhost [127.0.0.1]) by snow.icemt.iastate.edu (950413.SGI.8.6.12/8.6.12) with ESMTP id SAA03778 for <info-performer@sgi.com>; Wed, 1 Apr 1998 18:24:19 -0600
Sender: holly@icemt.iastate.edu
Message-ID: <3522DAB2.27382F47@icemt.iastate.edu>
Date: Wed, 01 Apr 1998 18:24:18 -0600
From: Juergen Holland <holly@icemt.iastate.edu>
X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 6.2 IP22)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Problems with pfSwitch on 6.2 machines.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

description:
I am developing an application (Performer 2.2) for a CAVE-like environment.
Several geometry models are being loaded at the initialisation of my app. At
excecution I want to switch the different models (only one turned on at a time)
at run-time.
I am using the pfSwitch() function and place it in a shared memory arena. I am
changing the switch values via an OpenGL menu (postdraw function). The values I
get while switching are "good" .

problem:
On an OCTANE with IRIX 6.4 the pfSwitch works fine, while on the (2 HiPPI
networked) ONYX IR with IRIX 6.2 only the values change, but not the geometry.
(running a CAVE-simulator)

help: ?

--
Juergen Holland

SE-Lab, ICEMT



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 17:10:05 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA29193 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 17:01:47 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA29166 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 17:01:46 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA6687806
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 17:01:48 -0800 (PST)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id RAA26826
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 17:01:47 -0800 (PST)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA6694360;
	Wed, 1 Apr 1998 17:01:46 -0800 (PST)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA28840; Wed, 1 Apr 1998 17:01:45 -0800 (PST)
Sender: dorbie@sgi.com
Message-ID: <3522E379.635DBD27@sgi.com>
Date: Wed, 01 Apr 1998 17:01:45 -0800
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Jan Barglowski <jan@archimedes.vislab.navy.mil>
CC: info-performer@sgi.com
Subject: Re: C++ cliptexures...
References: <199804012321.PAA28898@archimedes.vislab.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Jan Barglowski wrote:
> 
> Performers:
> 
> I've created a virtual cliptexure callback that works when used in
> conjunction with clipfly.  When I took this function and put it
> into perfly, my virtual cliptextures no longer work!  I've printed
> out the values for VirtualLODOffset, NumEffectiveLevels, and LODRange
> and they are identical for both programs.
> 
> My symptoms are a rapid sharpening/blurring of the virtual cliptexture
> when zooming in or out towards it.  It doesn't seem to matter what
> speed I zoom at.  Since the numbers calculated for the above parameters
> work with clipfly, I'm assuming I'm doing the calculations correctly.
> And when I comment out the tile-by-tile cliptexture updates, the
> cliptexture acts as if it's on Level=0.
> 
> I think this is one of two things:
> 1) Clipfly does something for virtual cliptextures that perfly
>    doesn't.  And I can't find what this is!  I looked at the README
>    file for clipfly, and the consideration for viewpoint update
>    shouldn't cause this (am I right?).  The only thing I can figure
>    is some of the parameters that control cliptextures are getting
>    some (important) initialization in clipfly.  Yet I look at
>    virtcliptexture.c and don't see a lot of these values getting
>    set at all.  Any ideas for what I'm missing?
> 2) the C++ cliptexture functions don't work, but I'd hate to think
>    this is the case.  Still, anyone do virtual cliptextures with
>    C++ bindings out there?
> 
> Any hints/help/insight will be appreciated!
> 
> jan

Do you have a reasonably sized invalid border?

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 18:30:30 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA29568 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 18:11:42 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA29541 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 18:11:41 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA6614443
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 18:11:41 -0800 (PST)
Received: from challenge (challenge.silicon.cl [200.29.42.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id SAA20758
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 18:11:36 -0800 (PST)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Wed, 1 Apr 1998 22:11:27 -0800
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma000537; Wed, 1 Apr 98 22:11:18 -0800
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA04017 for <@ivory.silicon.cl:info-performer@sgi.com>; Wed, 1 Apr 1998 22:12:07 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA06477 for info-performer@sgi.com; Wed, 1 Apr 1998 21:25:42 -0500
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9804012125.ZM6475@krusty>
Date: Wed, 1 Apr 1998 21:25:41 -0500
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Modify buffers
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi,

	Does anyone know how to modify the buffers (frame, z, stencil, etc) of
a Performer channel/window. I want to do some post draw processing to the frame
buffer using OpenGL and I don't know how to access the buffers.

-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Andres Bello 2777, Of. 602
E-mail: asaez@silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 105       Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  1 23:43:39 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA00408 for info-performer-dist@holodeck.engr.sgi.com; Wed, 1 Apr 1998 23:20:28 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id XAA00381 for <info-performer@holodeck.engr.sgi.com>; Wed, 1 Apr 1998 23:20:21 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA6516730
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 1 Apr 1998 23:20:20 -0800 (PST)
Received: from mailgate.urz.uni-wuppertal.de (mailgate.urz.uni-wuppertal.de [132.195.20.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id XAA02264
	for <info-performer@sgi.com>; Wed, 1 Apr 1998 23:20:15 -0800 (PST)
	mail_from (zeise@uni-wuppertal.de)
Received: from wetnt9 (wetnt9.elektro.uni-wuppertal.de [132.195.29.97])
	by mailgate.urz.uni-wuppertal.de (8.8.8/8.8.8) with SMTP id JAA09514;
	Thu, 2 Apr 1998 09:20:02 +0200 (MDT)
Message-ID: <002f01bd5e07$378ad7b0$611dc384@wetnt9.elektro.uni-wuppertal.de>
From: "Wilfried Zeise" <zeise@uni-wuppertal.de>
To: "Alejandro Saez" <cano@silicon.cl>
Cc: "info-performer" <info-performer@sgi.com>
Subject: Re: Modify buffers
Date: Thu, 2 Apr 1998 09:16:09 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Status: O

Hi Alejandro:

First you have to select the color buffer source for the pixels with
glReadBuffer (GL_FRONT_LEFT, GL_FRONT_BACK, etc.).

With glReadPixels you can read the buffer values, with glDrawPixels you can
draw new values and with glCopyPixels you can copy a pixel rectangle to
another position.

The pixel formats you can use are e.g.:

- GL_RGB for the rgb values
- GL_RGBA for the rgba values
- GL_STENCIL_INDEX for the stencil buffer
- GL_DEPTH_COMPONENT for the depth buffer
etc.

Hope this helps.

Wilfried

Wilfried Zeise
University of Wuppertal




>Hi,
>
> Does anyone know how to modify the buffers (frame, z, stencil, etc) of
>a Performer channel/window. I want to do some post draw processing to the
frame
>buffer using OpenGL and I don't know how to access the buffers.
>
>--
>------------------------------------------------------------------------
>Alejandro Saez
>Software Engineer
>Silicon Chile S.A.
>                                        Avda. Andres Bello 2777, Of. 602
>E-mail: asaez@silicon.cl              Providencia
>Phone:  +56 (2) 203 3371 Ext. 105       Santiago
>Fax:    +56 (2) 203 3370                Chile
>------------------------------------------------------------------------
>=======================================================================
>List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>            Submissions:  info-performer@sgi.com
>        Admin. requests:  info-performer-request@sgi.com
>

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  2 04:23:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA00763 for info-performer-dist@holodeck.engr.sgi.com; Thu, 2 Apr 1998 04:06:53 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA00736 for <info-performer@holodeck.engr.sgi.com>; Thu, 2 Apr 1998 04:06:51 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA6820447
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 2 Apr 1998 04:06:50 -0800 (PST)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA27658
	for <info-performer@sgi.com>; Thu, 2 Apr 1998 04:06:48 -0800 (PST)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id OAA13944; Thu, 2 Apr 1998 14:14:49 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma013929; Thu, 2 Apr 98 14:14:38 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id OAA08396;
	Thu, 2 Apr 1998 14:06:39 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804021206.OAA08396@s00sn1.fel.tno.nl>
Subject: Re: Modify buffers
To: zeise@uni-wuppertal.de (Wilfried Zeise)
Date: Thu, 2 Apr 1998 14:06:38 +0200 (MET DST)
Cc: cano@silicon.cl, info-performer@sgi.com
In-Reply-To: <002f01bd5e07$378ad7b0$611dc384@wetnt9.elektro.uni-wuppertal.de> from "Wilfried Zeise" at Apr 2, 98 09:16:09 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Wilfried Zeise wrote:
> 
> Hi Alejandro:
> 
> First you have to select the color buffer source for the pixels with
> glReadBuffer (GL_FRONT_LEFT, GL_FRONT_BACK, etc.).
> 
> With glReadPixels you can read the buffer values, with glDrawPixels you can
> draw new values and with glCopyPixels you can copy a pixel rectangle to
> another position.
> 
> The pixel formats you can use are e.g.:
> 
> - GL_RGB for the rgb values
> - GL_RGBA for the rgba values
> - GL_STENCIL_INDEX for the stencil buffer
> - GL_DEPTH_COMPONENT for the depth buffer
> etc.
> 
> Hope this helps.
> 
> Wilfried
> 
> Wilfried Zeise
> University of Wuppertal
> 
> >Hi,
> >
> > Does anyone know how to modify the buffers (frame, z, stencil, etc) of
> >a Performer channel/window. I want to do some post draw processing to the
> frame
> >buffer using OpenGL and I don't know how to access the buffers.
> >
> >--
> >------------------------------------------------------------------------
> >Alejandro Saez
> >Software Engineer
> >Silicon Chile S.A.
> >                                        Avda. Andres Bello 2777, Of. 602
> >E-mail: asaez@silicon.cl              Providencia
> >Phone:  +56 (2) 203 3371 Ext. 105       Santiago
> >Fax:    +56 (2) 203 3370                Chile

If you only want to draw some extra things like a HUD, you don;t have
to read and write the buffer. After pfDraw() you just set up the
required OpenGL state and viewing settings and draw what you want.
Be sure to restore the state as found after pfDraw(), because
performer might be counting on certain settings.

Mario
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  2 04:23:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA00734 for info-performer-dist@holodeck.engr.sgi.com; Thu, 2 Apr 1998 04:02:24 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA00707 for <info-performer@holodeck.engr.sgi.com>; Thu, 2 Apr 1998 04:02:22 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA6166711
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 2 Apr 1998 04:02:22 -0800 (PST)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA26617
	for <info-performer@sgi.com>; Thu, 2 Apr 1998 04:02:20 -0800 (PST)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id OAA13521; Thu, 2 Apr 1998 14:10:18 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma013485; Thu, 2 Apr 98 14:09:52 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id OAA08204;
	Thu, 2 Apr 1998 14:01:52 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804021201.OAA08204@s00sn1.fel.tno.nl>
Subject: Re: Problems with pfSwitch on 6.2 machines.
To: holly@icemt.iastate.edu (Juergen Holland)
Date: Thu, 2 Apr 1998 14:01:52 +0200 (MET DST)
Cc: info-performer@sgi.com (Performer)
In-Reply-To: <3522DAB2.27382F47@icemt.iastate.edu> from "Juergen Holland" at Apr 1, 98 06:24:18 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Juergen Holland wrote:
> 
> description:
> I am developing an application (Performer 2.2) for a CAVE-like environment.
> Several geometry models are being loaded at the initialisation of my app. At
> excecution I want to switch the different models (only one turned on at a time)
> at run-time.
> I am using the pfSwitch() function and place it in a shared memory arena. I am
> changing the switch values via an OpenGL menu (postdraw function). The values I
> get while switching are "good" .
> 
> problem:
> On an OCTANE with IRIX 6.4 the pfSwitch works fine, while on the (2 HiPPI
> networked) ONYX IR with IRIX 6.2 only the values change, but not the geometry.
> (running a CAVE-simulator)
> 
> help: ?

I might be that you change the value of the pfSwitch in the DRAW
process. This will set the value for a copy used in the DRAW when you
have a separate draw process (PFMP_APP_CULLDRAW).
The next frame a new copy is made from the APP version and this will
not include the changes made by DRAW, only when you are in single
process mode (PFMP_APPCULLDRAW).
What might be the solution is to let the OpenGL menu function set a
value in shared memory and let the APP process copy this value in to
the switch node.

Mario
> 
> --
> Juergen Holland
> 
> SE-Lab, ICEMT
> 
> 
> 
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
> 

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  2 05:40:32 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA01016 for info-performer-dist@holodeck.engr.sgi.com; Thu, 2 Apr 1998 05:22:13 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA00989 for <info-performer@holodeck.engr.sgi.com>; Thu, 2 Apr 1998 05:22:11 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA6832906
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 2 Apr 1998 05:22:12 -0800 (PST)
Received: from curare.tcm.hut.fi ([130.233.45.40]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id FAA11154
	for <info-performer@sgi.com>; Thu, 2 Apr 1998 05:22:05 -0800 (PST)
	mail_from (napo@curare.tcm.hut.fi)
Received: (from napo@localhost) by curare.tcm.hut.fi (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA15982; Thu, 2 Apr 1998 16:22:04 +0300
From: Hannu Napari <Hannu.Napari@hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu,  2 Apr 1998 16:22:03 +0300 (EEST)
To: info-performer@sgi.com
Subject: .ls -> Open Inventor and stereo...
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13603.36344.78854.580838@curare.tcm.hut.fi>
Status: O


I recently asked about .ls loader for Performer. Well, it turned out
that LightScape can export OpenInventor. I had some problems
with the exporter, the most annoying one was that the exporter
used the decimal separator inherited from the locale settings. 8)
Great, the finnish locale uses comma instead of decimal poins (.).
Oh well, that was easy to fix. If someone at Lightscape is reading
this then maybe you could fix that in the converter...

The model I'm using for the testing purposes is about 200k polys,
and it runs like molasses in Performer. I got it to run faster by
running the exported file through ivfix (it takes about an hour to
do it), and it turned out that the .iv loader had problems with
VertexProperties, I lost all the colors. Everything was just white.
Maybe someone at SGI could take a look at the .iv loader and fix that...
Anyway, the second run with "ivfix -p" fixed that.

Let's get to the point, finally.

The framerate is reasonable when I'm not doing stereo. But with stereo
mode on the framerate drops more than I anticipated. I'm doing
the stereo rendering with modified perfly using pfChannels
for left & right on a single IR pipe. Can anyone suggest any
optimization ideas/techniques for that setup?

-- 
		      Hannu Napari  <Hannu.Napari@hut.fi>
		       Helsinki University of Technology
	     Telecommunications Software and Multimedia Laboratory
    PB 1100, FIN-02015 HUT, Finland, tel +358-9-4514736, fax +358-9-4515014
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  2 10:44:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA01446 for info-performer-dist@holodeck.engr.sgi.com; Thu, 2 Apr 1998 10:25:05 -0800
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA01419 for <info-performer@holodeck.engr.sgi.com>; Thu, 2 Apr 1998 10:25:05 -0800
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id KAA12048; Thu, 2 Apr 1998 10:24:58 -0800 (PST)
Date: Thu, 2 Apr 1998 10:24:58 -0800 (PST)
Message-Id: <199804021824.KAA12048@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: Sam Chu <c00chu00@nchc.gov.tw>
cc: info-performer@puget.engr.sgi.com
Subject: statistics Question
In-Reply-To: <199803300319.LAA00382@nchc.gov.tw>
References: <199803300319.LAA00382@nchc.gov.tw>
Status: O


Sam Chu writes:
 > Dear Performers:
 > 
 >   In Perfly statistics I got: (two channels one pipe)
 > 
 >   30/30 Hz
 > ...
 >   MSecs: frame=50.6 app=3.7 cull=8.0 draw=6.7 isect=3.2
 >   Frames=60 Misses: total=0 app+cull=0 draw=0
 > 
 > another channel
 >   MSecs: (almost the same as the above)
 >   Frames=61 Misses: total =61 app+cull=0 draw=0
 > 
 > Question:
 >   1. why app+cull+draw+isect much small than frame?
 >   2. why 50.6(frame)*30Hz > 1000 MSecs(1 Sec)?
 >   3. then what "frame:" means in "MSecs: frame=50.6"?
 >   4. What Misses means? Does it mean how many frames Performer drop?
 >   5. Why in one channel Misses=0 and another Misses=61?
 > 
 > Thank for any reply in advanced.
 > 

The key realization here is that two channels are being drawn
sequentially on one pipe

I've taken the liberty of rephrasing the questions slightly for the
sake of clarity.

Q Why are the app+cull+draw+isect times much smaller than the frame
  time?  What does "frame=50.6" mean anyway?

A. The app, cull, draw, isect times are measured times from beginning
  to end of phase for ONE channel.  The Frame time is a cycle time,
  namely the time from the finish of one frame to the finish of 
  the next frame of that ONE channel.  So it includes the time to 
  draw the other channel as well.  In your case, app+cull+draw+isect 
  add up to about 21.2, leaving 28.4 for the other frame and some
  possible overhead, which doesn't seem completely unreasonable.

Q.Why is 50.6 MSec * 30 Hz larger than 1000 MSec?

A. I'm not positive about this one, but I believe that "30Hz" is the
  target frame rate (which isn't being realized), rather.than the
  realized frame rate.  Remember that gathering, and drawing stats actually
  takes a fair amount of time.

Q. What do "Misses" mean, and why does one channel have "Misses=0" and
   the other have "Misses=61".

A. A "Miss" is counted every time a channel does not finish drawing in
   time to make the target refresh cycle.
   Your app was missing its target frame rate (see previous question),
   But one of the channels was done in plenty of time to hit the frame
   rate, so it doesn't have any misses.  The other one didn't finish
   in time, so it gets a "Miss" counted against it.


I hope that clarifies matters.

------------------------------------------------------------------------
Jay L Gischer        +  "I see great things in baseball.  It's our game.
Advanced Graphics    +  It will repair our losses and be a blessing to
Software             +  us."
Silicon Graphics     +    -Walt Whitman
(415) 390-4277       +    
gischer@sgi.com      +  "A life has no meaning except in the impact it
                     +  has on other lives"
                     +    -Jackie Robinson

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  2 13:57:09 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA01860 for info-performer-dist@holodeck.engr.sgi.com; Thu, 2 Apr 1998 13:46:20 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA01833 for <info-performer@holodeck.engr.sgi.com>; Thu, 2 Apr 1998 13:46:19 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA7054486
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 2 Apr 1998 13:46:18 -0800 (PST)
Received: from ait.nrl.navy.mil (ait.nrl.navy.mil [132.250.128.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id NAA15547
	for <info-performer@sgi.com>; Thu, 2 Apr 1998 13:46:12 -0800 (PST)
	mail_from (ekuo@ait.nrl.navy.mil)
Received: from fargo.ait.nrl.navy.mil (fargo [132.250.128.95])
	by ait.nrl.navy.mil (8.8.8/8.8.8) with SMTP id QAA21475
	for <info-performer@sgi.com>; Thu, 2 Apr 1998 16:46:11 -0500 (EST)
Date: Thu, 2 Apr 1998 16:46:11 -0500 (EST)
From: Eddy Kuo <ekuo@ait.nrl.navy.mil>
To: info-performer@sgi.com
Subject: Question about pfFluxed Geoset
Message-ID: <Pine.SGI.3.91.980402163139.5731C-100000@fargo.ait.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello performers:

I am trying to use fluxed geoset to visualization a simulation
in which the geoset is changing in every time step.  One of
my obstacle is that the not only the attribute lists (normal, coord, 
etc) of the geoset are changing, but also total number of elements
in the list is changing (not just the number of primitives, but somthing
like vertices).  So any suggestion on how to accomplish this?

thanks in advance

Ed.


-------------------------------------------------------------------
Eddy Kuo 		      		work phone: 202-767-6025 
Virtual Reality Lab 			home phone: 703-893-2553
Naval Research Lab		http://www.cis.ohio-state.edu/~ekuo
-------------------------------------------------------------------

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  2 16:14:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA03282 for info-performer-dist@holodeck.engr.sgi.com; Thu, 2 Apr 1998 15:59:03 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA03255 for <info-performer@holodeck.engr.sgi.com>; Thu, 2 Apr 1998 15:59:02 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA5932975
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 2 Apr 1998 15:59:01 -0800 (PST)
Received: from holodeck.engr.sgi.com ([150.166.37.78]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id PAA08701
	for <info-performer@sgi.com>; Thu, 2 Apr 1998 15:59:00 -0800 (PST)
	mail_from (allan@holodeck.engr.sgi.com)
Received: (from allan@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA03238; Thu, 2 Apr 1998 15:58:03 -0800
Date: Thu, 2 Apr 1998 15:58:03 -0800
From: allan@holodeck.engr.sgi.com (Allan Schaffer)
Message-Id: <199804022358.PAA03238@holodeck.engr.sgi.com>
To: info-performer@sgi.com
Subject: IMPORTANT: Performer 2.2 patch 3018
Status: O


Performers,

A security vulnerability was recently discovered in the
performer_tools subsystem shipped with Performer 2.2.  

Patch 3018 has been released to address this problem.  You can
download this patch for free, regardless of support status, from
Silicon Graphics Security Headquarters:

	http://www.sgi.com/Support/security/security.html

The direct path to the security advisory, patch bits, release notes,
and checksums are:

	ftp://sgigate.sgi.com/security/19980401-01-P3018
	ftp://sgigate.sgi.com/patches/6.2/patch3018.tar
	ftp://sgigate.sgi.com/patches/6.2/patch3018.relnotes
	ftp://sgigate.sgi.com/patches/6.2/patch3018.pgp.and.chksums

Patch 3018 should be loaded on any system which has the
performer_tools from IRIS Performer 2.2 installed.  It is only
necessary with performer_tools 2.2 and cannot be installed on prior
versions of IRIS Performer.  Patch 3018 has been tested with IRIS
Performer 2.2 on systems running IRIX 6.2, IRIX 6.3, IRIX 6.4, and
IRIX 6.5.

This patch also contains a few other minor bug fixes to the
performer_tools.  Here is the list of what's fixed:

	o SCR 581294 - Performer API tool security vulnerability
	o SCR 581950 - pfsearch.cgi fails with outbox webserver
	o SCR 584224 - pfresults.cgi fails with perl5
	o SCR 585820 - wrong title for patch 3004

Patch 3004 was a short-lived predecessor to patch 3018; if you were
one of the few to download patch 3004, be sure to read section 1.5 of
the patch 3018 relnotes.

Allan
----
Allan Schaffer                                                allan@sgi.com
Silicon Graphics                               http://reality.sgi.com/allan
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 00:44:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA05171 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 00:33:16 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id AAA05144 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 00:33:12 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA7281113
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 00:33:12 -0800 (PST)
Received: from www.exn.co.il (hul01.exn.co.il [194.90.244.17]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id AAA24514
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 00:33:08 -0800 (PST)
	mail_from (Zachik@elbit.co.il)
Received: from elbit2x.elbit.co.il (evs.elbit.co.il [199.203.215.2])
	by www.exn.co.il (8.8.0/8.8.5) with ESMTP id LAA16646
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 11:32:56 -0200 (GMT)
Received: from nt7.elbit (elbit.co.il [128.139.29.1]) by elbit.co.il (8.8.5/8.8.3) with ESMTP id KAA28683 for <info-performer@sgi.com>; Fri, 3 Apr 1998 10:55:45 -0200 (GMT)
Received: by NT7 with Internet Mail Service (5.0.1458.49)
	id <HB90N8ZD>; Fri, 3 Apr 1998 10:55:10 +0200
Message-ID: <95965576F40FD111862100805FFECE29167CF2@NT7>
From: Zachi Karni <Zachik@elbit.co.il>
To: "'Performer Mailing-List'" <info-performer@sgi.com>
Subject: Billboarding
Date: Fri, 3 Apr 1998 10:55:10 +0200
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Status: O

Hi All

I am looking for general information about using billboarding,
especially for drawing clouds and trees.

Thanks 
  
Zachi Karni	zachik@elbit.co.il
Software Engineer
Elbit Systems LTD	+972-4-8315660 Direct
Haifa			+972-4-8315739 Fax
Israel			+972-4-8377184 Home

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 01:31:21 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA05366 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 01:14:10 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id BAA05339 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 01:14:08 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id BAA7275549
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 01:14:07 -0800 (PST)
Received: from vacherin.geo.unizh.ch (mail.geo.unizh.ch [130.60.176.42]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id BAA03661
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 01:14:02 -0800 (PST)
	mail_from (hilko@geo.unizh.ch)
Received: from aquilla.geo.unizh.ch ([130.60.176.5])
          by vacherin.geo.unizh.ch (Post.Office MTA v3.1.2
          release (PO203-101c) ID# 0-42730U500L100S0) with SMTP
          id AAA22867; Fri, 3 Apr 1998 11:13:53 +0200
Received: from geo.unizh.ch by aquilla.geo.unizh.ch (950413.SGI.8.6.12) id KAA05362; Fri, 3 Apr 1998 10:14:19 +0100
Sender: hilko@geo.unizh.ch (Hilko Hoffmann)
Message-ID: <3524A86A.B644A63A@geo.unizh.ch>
Date: Fri, 03 Apr 1998 10:14:19 +0100
From: Hilko Hoffmann <hilko@geo.unizh.ch>
Organization: Uni Zuerich, Remote Sensing Lab
X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: Zachi Karni <Zachik@elbit.co.il>
CC: info-performer@sgi.com
Subject: Re: Billboarding
References: <95965576F40FD111862100805FFECE29167CF2@NT7>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Zachi Karni wrote:

> Hi All
>
> I am looking for general information about using billboarding,
> especially for drawing clouds and trees.
>
> Thanks
>
> Zachi Karni     zachik@elbit.co.il
> Software Engineer
> Elbit Systems LTD       +972-4-8315660 Direct
> Haifa                   +972-4-8315739 Fax
> Israel                  +972-4-8377184 Home
>
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com



Look at this fragment of our loader code:

 --------------------------------------


#include <Performer/pf/pfBillboard.h>


   pfBillboard *aBillboard;
   pfVec3     pos, axis;



   /* initialise
pfBuilder                                                    */
   pfdResetBldrGeometry();
   pfdResetBldrState();

   /* allocate
memory                                                         */
   void *arena = pfGetSharedArena();

   aGeode = new pfGeode();

   aGeoState = new pfGeoState();

   /* define texture and
geostate                                             */
   /* if texCode is set (>= 0) --> copy
filename                              */
   if (obj->texCode >= 0) {
       strcpy(geoStateInfo->texName,
rslObjTileInfo->textureList[obj->texCode]);
       geoStateInfo->loadTexture = 1;
   }
   aGeoState = getGeoState(geoStateInfo);
   pfdBldrGState(aGeoState);

   aGeom = pfdNewGeom(4);
   aGeom->nbind = PFGS_PER_PRIM;
   aGeom->cbind = PFGS_PER_PRIM;
   aGeom->tbind = PFGS_PER_VERTEX;
   aGeom->primtype = PFGS_POLYS;

   // Color
   aGeom->colors[0].set(obj->color[0], obj->color[1], obj->color[2],
obj->color[3]);

   // Geometry
   if (obj->numberOfPoly == 0) {
       // billboard structure
       if (obj->shape == 3) {
    // triangle shape
    aGeom->numVerts = 3;
       }
       else {
    // quad shape
    aGeom->numVerts = 4;
       }
       // vertices are always set for quads, tris only take first three
vertices
       v1.set(-0.5f, 0.0f, -0.5f);
       v2.set(0.5f, 0.0f, -0.5f);
       v3.set(0.5f, 0.0f, 0.5f);
       v4.set(-0.5f, 0.0f, 0.5f);
       n1.set(0.0f, -1.0f, 0.0f);
       // scale matrix
       scaleMat.makeScale(obj->scale[0], obj->scale[1], obj->scale[2]);
       // scale
       v1 = v1 * scaleMat;
       v2 = v2 * scaleMat;
       v3 = v3 * scaleMat;
       v4 = v4 * scaleMat;

       // set vertices coordinates
       aGeom->coords[0].set(v1[0], v1[1], v1[2]);
       aGeom->coords[1].set(v2[0], v2[1], v2[2]);
       aGeom->coords[2].set(v3[0], v3[1], v3[2]);
       aGeom->coords[3].set(v4[0], v4[1], v4[2]);
       // set Normals
       aGeom->norms[0].set(n1[0], n1[1], n1[2]);
       // set texture coordinates
       aGeom->texCoords[0].set(obj->texCoord[0], obj->texCoord[2]);
       aGeom->texCoords[1].set(obj->texCoord[1], obj->texCoord[2]);
       aGeom->texCoords[2].set(obj->texCoord[1], obj->texCoord[3]);
       aGeom->texCoords[3].set(obj->texCoord[0], obj->texCoord[3]);

       pfdAddBldrGeom(aGeom, 1);
       pfdDelGeom(aGeom);

       aTmpGeode = (pfGeode *)pfdBuild();

       aBillboard = new pfBillboard();
       aBillboard->addGSet(aTmpGeode->getGSet(0));
       // place billboard;
       pos.set(obj->xyzCoord[0] + obj->translate[0],
               obj->xyzCoord[1] + obj->translate[1],
        obj->xyzCoord[2] + obj->translate[2] + obj->scale[2] * 0.5);
       aBillboard->setPos(0, pos);
       aBillboard->setMode(PFBB_ROT, PFBB_AXIAL_ROT);
       axis.set(0.0f, 0.0f, 1.0f); // billboard spinns around z-axis
       aBillboard->setAxis(axis);
       aGeode = aBillboard;
   }

   return aGeode;


--------------------

For best results use semi transparent rgba textures of vegetation or
clouds

Hope this helps

Hilko


--
****************************************************************
Hilko Hoffmann
Remote Sensing Laboratories;    University of Zurich
Winterthurerstrasse 190; CH-8057 Zurich; Switzerland
Phone: +41 - 1 / 63 56519; FAX:   +41 - 1 / 63 56842
mailto:hilko@geo.unizh.ch
http://www.geo.unizh.ch/rsl1/lvg/research/
****************************************************************



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 05:29:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA05849 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 05:17:59 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA05822 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 05:17:57 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA7309988
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 05:17:57 -0800 (PST)
Received: from ptah.cra.com (ptah.cra.com [205.181.6.81]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA18765
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 05:17:56 -0800 (PST)
	mail_from (smulgund@cra.com)
Received: from 205.181.6.126 by ptah.cra.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8)
	id 2FSH35P0; Fri, 3 Apr 1998 08:23:02 -0500
X-Sender: smulgund@mail.cra.com
Message-Id: <v03102800b14a91816844@[205.181.6.126]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 3 Apr 1998 08:17:48 -0500
To: info-performer@sgi.com
From: Sandeep Mulgund <smulgund@cra.com>
Subject: Problems with XWarpPointer under Irix 6.4/Performer 2.2
Status: O

Is there any reason that XWarpPointer would not work properly on an Octane?
I have a simulation application in which I'm using it to center the mouse
on the screen at startup, and on a particular keypress.  It works just fine
when the program starts up, but it doesn't work if I press the appropriate
key in my program to force the mouse to center itself.  Interestingly, the
function call works just fine on an Indy running Irix 6.2.  Any suggestions?

Sandeep Mulgund


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 06:10:29 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA06013 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 06:01:04 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA05986 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 06:01:02 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA7156330
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 06:01:01 -0800 (PST)
Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA28452
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 06:01:00 -0800 (PST)
	mail_from (mheffron@maestro.mitre.org)
From: mheffron@maestro.mitre.org
Received: from maestro.mitre.org (maestro.mitre.org [128.29.45.1])
	by mwunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id JAA25912;
	Fri, 3 Apr 1998 09:00:46 -0500 (EST)
Received: from [128.29.113.88] (ilab-dx3.mitre.org) by maestro.mitre.org (4.1/SMI-4.1)
	id AA14488; Fri, 3 Apr 98 09:00:44 EST
Message-Id: <v03020902b14a9af6ab10@[128.29.113.88]>
In-Reply-To: <95965576F40FD111862100805FFECE29167CF2@NT7>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 3 Apr 1998 09:00:41 -0500
To: "'Performer Mailing-List'" <info-performer@sgi.com>,
        Zachi Karni <Zachik@elbit.co.il>
Subject: Re: Billboarding
Status: O

>Hi All
>
>I am looking for general information about using billboarding,
>especially for drawing clouds and trees.
>
>Thanks
>
>Zachi Karni	zachik@elbit.co.il

I've found that billboarding clouds don't look realistic. IMO

I created a cylinder and applied a cloud texture on one half and then
reversed the texture for the back.

This gives you that layered look as near clouds pass in front of the far.


Marty


Martin Heffron            |
The MITRE Corporation     |   MIT Research and Engineering
CAASD                     |   Center for Advanced Aviation System
Development
(703)883-5433             |        


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 09:48:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA06396 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 09:34:49 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA06369 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 09:34:48 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA7347741
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 09:34:43 -0800 (PST)
Received: from mail.xerxesinc.com ([205.152.148.197]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA12185
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 09:34:41 -0800 (PST)
	mail_from (crakrjak@mail.xerxesinc.com)
Received: from localhost (crakrjak@localhost)
	by mail.xerxesinc.com (8.8.8/8.8.7) with SMTP id MAA28872
	for <info-performer@sgi.com>; Thu, 2 Apr 1998 12:46:18 -0500
Date: Thu, 2 Apr 1998 12:46:18 -0500 (EST)
From: <crakrjak@xerxesinc.com>
To: info-performer@sgi.com
Subject: circular mask
Message-ID: <Pine.LNX.3.96.980402124316.28764A-100000@mail.xerxesinc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

hi, the output of my program has to give a circular output unlike
traditional quad viewport. i am wondering what would be best way  to mask
out in black the exterior of my circular viewport. I would really
appreciate any help on this thanks.

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 10:14:39 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA06470 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 10:02:37 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA06443 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 10:02:35 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA7424777
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 10:02:34 -0800 (PST)
Received: from mpik-tueb.mpg.de (bayleaf.mpik-tueb.mpg.de [192.124.28.136]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id KAA23929
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 10:02:32 -0800 (PST)
	mail_from (sib@mpik-tueb.mpg.de)
Received: (from sib@localhost) by mpik-tueb.mpg.de (950413.SGI.8.6.12/950213.SGI.AUTOCF) id UAA10846; Fri, 3 Apr 1998 20:02:21 +0200
From: "Sibylle Geiger" <sib@bayleaf.mpik-tueb.mpg.de>
Message-Id: <9804032002.ZM10844@bayleaf.mpik-tueb.mpg.de>
Date: Fri, 3 Apr 1998 20:02:21 +0200
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: pfFog
Cc: sib@mpik-tueb.mpg.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi pfAll,

I've tried to simulate ground fog with 8m height (like over a lake), between
75m and 100m. But also the mountain texture from the environment box is white
(which is really higher and far away) and only the sky from the earth-sky
modell is still blue.

Is there any possibility to do so?
Does anyone can tell me how to do?

If attached my earth-sky modell and my fog.

Thanks in advance

Gruss Sibylle

*****************************************************************************/*
/* CONFIGURE PIPE */
static void
OpenPipeWin(pfPipeWindow *pw)
{
    .
    .
    .
    /* create fog */
    fog = pfNewFog(pfGetSharedArena());
    pfFogType (fog, PFFOG_PIX_LIN);
    pfFogColor (fog, 1.0, 1.0, 1.0);
    pfFogRange (fog, 75.0f , 100.0f);
    pfEnable (PFEN_FOG);
    pfApplyFog (fog);
    pfOverride(PFSTATE_FOG | PFSTATE_ENFOG, PF_ON);
    .
    .
    .
}

/* EARTH SKY MODEL */
void attatchSkyModel(int ESky, pfChannel *threeChannel)
{
  pfEarthSky *eSky;

  /* Create an earth/sky model that draws sky/ground/horizon */
  eSky = pfNewESky();

  pfESkyFog(eSky,PFES_GRND, fog);
  pfESkyMode(eSky, PFES_GRND_FOG_TOP, 2.0f);
  pfESkyAttr(eSky, PFES_HORIZ_ANGLE, 30.0f);
  pfESkyColor(eSky, PFES_CLEAR, .3f, .3f, .7f, 1.0f);
  pfChanESky(threeChannel, eSky);
}

-- 

-----------------------------------------------------------

     _/     _/  _/_/_/  _/_/_/   Sibylle Geiger
    _/_/ _/_/  _/   _/   _/      Max-Planck Institut f"ur
   _/  _/ _/  _/_/_/    _/       biologische Kybernetik
  _/     _/  _/        _/        Spemannstrasse 38
 _/     _/  _/      _/_/_/       72076 T"ubingen, Germany

phone: +49-7071-601 630		
fax  : +49-7071-601 616		
web  : www.kyb.tuebingen.mpg.de
email: sibylle.geiger@tuebingen.mpg.de
-----------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 11:18:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA06855 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 11:04:52 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA06828 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 11:04:51 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA7420808
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 11:04:50 -0800 (PST)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA20930
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 11:04:48 -0800 (PST)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA7430925;
	Fri, 3 Apr 1998 11:04:48 -0800 (PST)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA31695; Fri, 3 Apr 1998 11:04:47 -0800 (PST)
Sender: dorbie@sgi.com
Message-ID: <352532CF.9320E1F0@sgi.com>
Date: Fri, 03 Apr 1998 11:04:47 -0800
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Zachi Karni <Zachik@elbit.co.il>
CC: "'Performer Mailing-List'" <info-performer@sgi.com>
Subject: Re: Billboarding
References: <95965576F40FD111862100805FFECE29167CF2@NT7>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Zachi Karni wrote:
> 
> Hi All
> 
> I am looking for general information about using billboarding,
> especially for drawing clouds and trees.
> 

www.dorbie.com

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 11:29:23 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA06964 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 11:19:33 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA06937 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 11:19:32 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA7421458
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 11:19:31 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA27261
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 11:19:30 -0800 (PST)
	mail_from (boccara@MIT.EDU)
Received: from MIT.MIT.EDU by MIT.EDU with SMTP
	id AA14149; Fri, 3 Apr 98 14:19:30 EST
Received: from VETREC2.MIT.EDU by MIT.MIT.EDU (5.61/4.7) id AA22192; Fri, 3 Apr 98 14:19:21 EST
Sender: boccara@MIT.EDU
Message-Id: <352560B2.A6F3679F@mit.edu>
Date: Fri, 03 Apr 1998 14:20:34 -0800
From: Michael Boccara <boccara@MIT.EDU>
Organization: MIT
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22)
Mime-Version: 1.0
To: Performer <info-performer@sgi.com>
Subject: ZB limits & Overlaid channels
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi Performers,

For my space application, I have to use a very large Near/Far range : 1m/1e6km.
I chose to superpose 2 channels, sharing all attributes except near/far and draw
callback.
ChanFG : N = 1m      F = 10km
ChanBG : N = 10km    F = 1e6km
Better than a long speech, my piece of code is at the end of the message.

If I used only 1 channel, it would draw all the scene.
While my 2 channels draw 2 complementary parts of the scene, using draw
traversal masks.
So we should have the same graphic load...

BUT using 2 superposed channels is almost twice longer than using only 1 channel
!!!

Question : 
1/ Why does it take longer than using only 1 channel ?
2/ What does happen in the pfDraw() function that is uselessly repeated between
the 2 channels ?
3/ How come can I call twice pfDraw() without any argument, into each draw
callback, letting Performer guess that it is for 2 separate channels ?

I am using Performer 2.1 on an Onyx RE2, IRIX 6.2, 2 CPUs, 1 Pipe.

Thanks for carrying me into the secrets of the depths of Performer...
Hope I was clear in my message...

Mike

Code :

static void
InitChannel(pfPipe* pipe)
{
  Shared->chanBG = new pfChannel(pipe);
  Shared->chanFG = new pfChannel(pipe);
  Shared->chanBG->attach(Shared->chanFG);
  Shared->chanFG->setShare(PFCHAN_FOV |
			   PFCHAN_VIEW |
			   PFCHAN_VIEW_OFFSETS |
			   PFCHAN_SCENE |
			   PFCHAN_SWAPBUFFERS |
			   PFCHAN_SWAPBUFFERS_HW |
			   PFCHAN_APPFUNC |
			   PFCHAN_CULLFUNC |
			   PFCHAN_VIEWPORT);
  
  // attaching the common pfScene
  Shared->chanFG->setScene(Shared->scene); 

  // Customize pfDraw()
  Shared->chanFG->setTravFunc(PFTRAV_DRAW, drawFGChannel);
  Shared->chanBG->setTravFunc(PFTRAV_DRAW, drawBGChannel);

  // complementary clipping planes
  Shared->chanFG->setNearFar(.1e-3f, 10.0f);
  Shared->chanBG->setNearFar(10.0f, 1e6f);
  
  // chanFG is for Foreground Scene Group
  // chanBG is for Background Scene Group
  Shared->chanFG->setTravMask(PFTRAV_DRAW, FG_MASK);
  Shared->chanBG->setTravMask(PFTRAV_DRAW, BG_MASK); 
}

// 2 draw callbacks
//
static void
drawBGChannel(pfChannel *bgchan, void *)
{
  // earthsky color/depth clear
  bgchan->clear();

  // 1st call to pfDraw
  pfDraw();

  if (Shared->drawStats == 1)
    bgchan->drawStats();  
}

static void
drawFGChannel(pfChannel *fgchan, void *)
{
  // ONLY depth clear
  pfClear(PFCL_DEPTH, NULL);

  // 2nd call to pfDraw
  pfDraw();

  if (Shared->drawStats == 1)
    fgchan->drawStats();  
}


-- 
Michael Boccara / +1 (617) 253 00 05 / boccara@mit.edu
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 11:29:20 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA06931 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 11:19:07 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA06904 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 11:19:06 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA7405179
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 11:19:05 -0800 (PST)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA27114
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 11:18:58 -0800 (PST)
	mail_from (sbaker@link.com)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id NAA28813; Fri, 3 Apr 1998 13:18:12 -0600 (CST)
Date: Fri, 3 Apr 1998 13:18:45 -0600 (CST)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: crakrjak@xerxesinc.com
cc: info-performer@sgi.com
Subject: Re: circular mask
In-Reply-To: <Pine.LNX.3.96.980402124316.28764A-100000@mail.xerxesinc.com>
Message-ID: <Pine.SGI.3.96.980403131637.7025B-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Thu, 2 Apr 1998 crakrjak@xerxesinc.com wrote:

> hi, the output of my program has to give a circular output unlike
> traditional quad viewport. i am wondering what would be best way  to mask
> out in black the exterior of my circular viewport. I would really
> appreciate any help on this thanks.

If the circular mask doesn't change shape, you can draw the mask into
the overlay planes to make it look black. Then you might want to consider
using some user defined clip planes to clip the scene to (say) an octagon
in an effort to reduce the polygon count and pixel fill rates.

Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 11:49:25 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA07034 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 11:31:34 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA07006 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 11:31:33 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA7476901
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 11:31:32 -0800 (PST)
Received: from grover.atc.missouri.edu (grover.atc.missouri.edu [128.206.237.21]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA02950
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 11:31:30 -0800 (PST)
	mail_from (cccraig@grover.atc.missouri.edu)
Received: from localhost (cccraig@localhost) by grover.atc.missouri.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA03834; Fri, 3 Apr 1998 13:37:23 -0600
Date: Fri, 3 Apr 1998 13:37:23 -0600 (CST)
From: "Craig J. Ferril" <cccraig@grover.atc.missouri.edu>
Reply-To: "Craig J. Ferril" <cccraig@grover.atc.missouri.edu>
To: Jeremy Townsend <paradoxgames@mindspring.com>
cc: info-performer@sgi.com
Subject: Re: Path-Finding
In-Reply-To: <3.0.1.32.19980323224118.006d3cb4@pop.mindspring.com>
Message-ID: <Pine.SGI.3.96.980403113509.3680A-100000@grover.atc.missouri.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Jeremy,

I haven't tried to do what you're doing, but in thinking about it I might have
come up with some suggestions. 

Perhaps if you try using a terrain following algorithm to keep you above the
terrain, and separate that from anything else that's going on, you could use
an A* algorithm. A* algorithms are pretty good for finding shortest paths from
point A to point B. All you would have to do then is think in 2-D, without
worrying about your height, since height above terrain would be taken care of
separately. 

This was just a thought. Hope this suggestion might lead to something useful
for you.

Cheers,
Craig


On Mon, 23 Mar 1998, Jeremy Townsend wrote:

> Hi, we are developing a 3D "game" of sorts using Performer that relies
> heavily on pathfinding (i.e. finding the shortest route between point A and
> point B on the surface of our terrain geometry). In 2D this is an easy
> problem, but the 3D terrain in question is extremely varied and intricate.
> 
> One approach we tried was to create a list of spheres over the entire
> terrain and link them in a logical order (i.e. to get to specific
> coordinate in sphere Z from coordinates in sphere X, proceed through
> spheres X->Y->Z then move to specified coordinates in Z.) While efficient,
> the set up is a hassle (100s of spheres, drawn and linked by hand), and it
> tends to crash when we use more than 20 spheres.
> 
> Another approach was to break down everything into a standard 2D array, but
> the arrays would be so large as to be completely unmanageable.
> 
> Anyway, my question is: Has anyone tried to do accurate 3D pathfinding?
> Could you send some ideas our way please?
> 
> Thank you!
> 
> Jeremy Townsend
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
> 

----------------------------------------------------------------------
Craig Ferril                     | cccraig@atc.missouri.edu 
Advanced Technology Center       | http://www.atc.missouri.edu
----------------------------------------------------------------------
"The universe is like a safe to which there is a combination.  But the
 combination is locked up in the safe."
               Peter DeVries


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 11:51:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA07242 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 11:47:20 -0800
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA07215 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 11:47:19 -0800
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id LAA14026; Fri, 3 Apr 1998 11:47:19 -0800 (PST)
Date: Fri, 3 Apr 1998 11:47:19 -0800 (PST)
Message-Id: <199804031947.LAA14026@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: info-performer@puget.engr.sgi.com
Subject: Stats Question correction
Status: O


Yesterday I posted a response to a question about stats for a
multi-channel, single pipe configuration. 

The stats for the channel were reporting something like this:

frame=50.7  app=3.5 cull=5.7 draw=9.2 isect=2.3

The question I got wrong was the interpretation of the "frame" stat.
This figure is in fact the channel latency, i.e., the length of time from when
the frame first enters the APP stage to the time when the DRAW stage
completes. I erroneously reported this as rather the period time of the draw
stage.  So the numbers are not supposed to add up at all. 

In more recent versions of Performer the term "frame" has been replaced with 
"latency".

------------------------------------------------------------------------
Jay L Gischer        +  "I see great things in baseball.  It's our game.
Advanced Graphics    +  It will repair our losses and be a blessing to
Software             +  us."
Silicon Graphics     +    -Walt Whitman
(415) 390-4277       +    
gischer@sgi.com      +  "A life has no meaning except in the impact it
                     +  has on other lives"
                     +    -Jackie Robinson

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 12:27:26 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA07525 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 12:08:33 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA07498 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 12:08:32 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA7477819
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 12:08:31 -0800 (PST)
Received: from quid.engr.sgi.com ([130.62.52.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA16958
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 12:08:30 -0800 (PST)
	mail_from (robj@quid.engr.sgi.com)
Received: (from robj@localhost) by quid.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA15940; Fri, 3 Apr 1998 12:08:27 -0800
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9804031208.ZM15938@quid.engr.sgi.com>
Date: Fri, 3 Apr 1998 12:08:26 -0800
In-Reply-To: Michael Boccara <boccara@MIT.EDU>
        "ZB limits & Overlaid channels" (Apr  3,  2:20pm)
References: <352560B2.A6F3679F@mit.edu>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Michael Boccara <boccara@mit.edu>, Performer <info-performer@sgi.com>
Subject: Re: ZB limits & Overlaid channels
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Michael

What pfMultiprocess and pfMultithread calls do you make ? You might want to
look at the note in man pfMultithread about having parallel CULL per channel (
end of page 2 of that man page in pf 2.2 ). So something like:

         /* operate all processing tasks in parallel */
          pfMultiprocess(PFMP_FORK_CULL | PFMP_FORK_DRAW | PFMP_FORK_ISECT);

          pfMultithread(0, PFPROC_CULL, 2);

Might help you.

Cheers
Rob

On Apr 3,  2:20pm, Michael Boccara wrote:
> Subject: ZB limits & Overlaid channels
> Hi Performers,
>
> For my space application, I have to use a very large Near/Far range :
1m/1e6km.
> I chose to superpose 2 channels, sharing all attributes except near/far and
draw
> callback.
> ChanFG : N = 1m      F = 10km
> ChanBG : N = 10km    F = 1e6km
> Better than a long speech, my piece of code is at the end of the message.
>
> If I used only 1 channel, it would draw all the scene.
> While my 2 channels draw 2 complementary parts of the scene, using draw
> traversal masks.
> So we should have the same graphic load...
>
> BUT using 2 superposed channels is almost twice longer than using only 1
channel
> !!!
>
> Question :
> 1/ Why does it take longer than using only 1 channel ?
> 2/ What does happen in the pfDraw() function that is uselessly repeated
between
> the 2 channels ?
> 3/ How come can I call twice pfDraw() without any argument, into each draw
> callback, letting Performer guess that it is for 2 separate channels ?
>
> I am using Performer 2.1 on an Onyx RE2, IRIX 6.2, 2 CPUs, 1 Pipe.
>
> Thanks for carrying me into the secrets of the depths of Performer...
> Hope I was clear in my message...
>
> Mike
>
> Code :
>
> static void
> InitChannel(pfPipe* pipe)
> {
>   Shared->chanBG = new pfChannel(pipe);
>   Shared->chanFG = new pfChannel(pipe);
>   Shared->chanBG->attach(Shared->chanFG);
>   Shared->chanFG->setShare(PFCHAN_FOV |
> 			   PFCHAN_VIEW |
> 			   PFCHAN_VIEW_OFFSETS |
> 			   PFCHAN_SCENE |
> 			   PFCHAN_SWAPBUFFERS |
> 			   PFCHAN_SWAPBUFFERS_HW |
> 			   PFCHAN_APPFUNC |
> 			   PFCHAN_CULLFUNC |
> 			   PFCHAN_VIEWPORT);
>
>   // attaching the common pfScene
>   Shared->chanFG->setScene(Shared->scene);
>
>   // Customize pfDraw()
>   Shared->chanFG->setTravFunc(PFTRAV_DRAW, drawFGChannel);
>   Shared->chanBG->setTravFunc(PFTRAV_DRAW, drawBGChannel);
>
>   // complementary clipping planes
>   Shared->chanFG->setNearFar(.1e-3f, 10.0f);
>   Shared->chanBG->setNearFar(10.0f, 1e6f);
>
>   // chanFG is for Foreground Scene Group
>   // chanBG is for Background Scene Group
>   Shared->chanFG->setTravMask(PFTRAV_DRAW, FG_MASK);
>   Shared->chanBG->setTravMask(PFTRAV_DRAW, BG_MASK);
> }
>
> // 2 draw callbacks
> //
> static void
> drawBGChannel(pfChannel *bgchan, void *)
> {
>   // earthsky color/depth clear
>   bgchan->clear();
>
>   // 1st call to pfDraw
>   pfDraw();
>
>   if (Shared->drawStats == 1)
>     bgchan->drawStats();
> }
>
> static void
> drawFGChannel(pfChannel *fgchan, void *)
> {
>   // ONLY depth clear
>   pfClear(PFCL_DEPTH, NULL);
>
>   // 2nd call to pfDraw
>   pfDraw();
>
>   if (Shared->drawStats == 1)
>     fgchan->drawStats();
> }
>
>
> --
> Michael Boccara / +1 (617) 253 00 05 / boccara@mit.edu
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from Michael Boccara



-- 
________________________________________________________________
Rob Jenkins mailto:robj@sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 12:47:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA07668 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 12:29:59 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA07641 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 12:29:58 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA7480108
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 12:29:57 -0800 (PST)
Received: from vista.taccsf.kirtland.af.mil (vista.taccsf.kirtland.af.mil [132.62.150.76]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA26677
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 12:29:53 -0800 (PST)
	mail_from (suzie@TACCSF.KIRTLAND.AF.MIL)
Received: by VISTA.TACCSF.KIRTLAND.AF.MIL with Internet Mail Service (5.5.1960.3)
	id <H8JMCZCV>; Fri, 3 Apr 1998 11:39:19 -0700
Message-ID: <214A87629D4FD111931F0060972989BA072E6A@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Frame Freeze
Date: Fri, 3 Apr 1998 11:39:09 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD5F2F.CA63EF70"
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD5F2F.CA63EF70
Content-Type: text/plain

We're running 2 separate 'perfly' executables on an 8 processor ONYX.
We've bound each perfly to it's own processor using the runon command on
the command line.  We also have several other processes running on all
of the other processors.  The display freezes for 1-3 seconds quite
frequently.  We've tried taking out the runon command and letting the
perfly run freely on whatever processor it chooses.  This does not stop
the freezing display.  We've cut the frame rate down to 20.0 HZ and that
helped the frequent freezes, but it makes the display more jumpy.  Does
anyone have any suggestions on how to avoid the freezing display?  

Should we try to bind the Draw processes to their own processors, and
put the APP and CULL somewhere else?

Thanks in advance for any help.

Suzie

------ =_NextPart_001_01BD5F2F.CA63EF70
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>Frame Freeze</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>We're running 2 separate 'perfly' executables on an 8 =
processor ONYX.&nbsp;&nbsp; We've bound each perfly to it's own =
processor using the runon command on the command line.&nbsp; We also =
have several other processes running on all of the other =
processors.&nbsp; The display freezes for 1-3 seconds quite =
frequently.&nbsp; We've tried taking out the runon command and letting =
the perfly run freely on whatever processor it chooses.&nbsp; This does =
not stop the freezing display.&nbsp; We've cut the frame rate down to =
20.0 HZ and that helped the frequent freezes, but it makes the display =
more jumpy.&nbsp; Does anyone have any suggestions on how to avoid the =
freezing display?&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Should we try to bind the Draw processes to their own =
processors, and put the APP and CULL somewhere else?</FONT>
</P>

<P><FONT SIZE=3D2>Thanks in advance for any help.</FONT>
</P>

<P><FONT SIZE=3D2>Suzie</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD5F2F.CA63EF70--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 13:39:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA07986 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 13:31:07 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA07959 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 13:31:04 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA7507057
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 13:31:03 -0800 (PST)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id NAA19177
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 13:30:55 -0800 (PST)
	mail_from (sbaker@link.com)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id PAA04526; Fri, 3 Apr 1998 15:30:46 -0600 (CST)
Date: Fri, 3 Apr 1998 15:31:19 -0600 (CST)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Michael Boccara <boccara@MIT.EDU>
cc: Performer <info-performer@sgi.com>
Subject: Re: ZB limits & Overlaid channels
In-Reply-To: <352560B2.A6F3679F@mit.edu>
Message-ID: <Pine.SGI.3.96.980403152143.15023A-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Fri, 3 Apr 1998, Michael Boccara wrote:

> Hi Performers,
> 
> For my space application, I have to use a very large Near/Far range : 1m/1e6km.
> I chose to superpose 2 channels, sharing all attributes except near/far and draw
> callback.
> ChanFG : N = 1m      F = 10km
> ChanBG : N = 10km    F = 1e6km
> Better than a long speech, my piece of code is at the end of the message.
> 
> If I used only 1 channel, it would draw all the scene.
> While my 2 channels draw 2 complementary parts of the scene, using draw
> traversal masks.
> So we should have the same graphic load...
> 
> BUT using 2 superposed channels is almost twice longer than using only 1 channel
> !!!
 
> 1/ Why does it take longer than using only 1 channel ?

There are quite a few reasons why it'll take longer:

* Much more CULL workload (the scene graph has to be traversed twice).
* Z buffer is cleared twice.
* (perhaps) Many more state changes since Performer will be
* (perhaps) Rendering the same material/texture properties once in the
  near channel and again in the far.
* There is (presumably) some per-channel overhead in Performer for setting
  up viewpoint and projection matrixes, clipping planes, etc.

...it's a bit suprising that it's *TWICE* as long unless your rendering is
severely CULL limited (possible - since you only have two CPU's) or has an
insane number of pfGeoState changes that are happening for pfGeoState that
appear on both far and near objects.

> 2/ What does happen in the pfDraw() function that is uselessly repeated between
> the 2 channels ?

It'll be drawing two different display lists - so that isn't (in itself) a
huge deal.

> 3/ How come can I call twice pfDraw() without any argument, into each draw
> callback, letting Performer guess that it is for 2 separate channels ?
 
It's not guessing, it knows which channel it is because it knows which
of your draw callbacks was being called.

Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 13:39:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA07935 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 13:27:03 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA07908 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 13:27:02 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA7488145
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 13:27:01 -0800 (PST)
Received: from quid.engr.sgi.com ([130.62.52.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA17928
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 13:27:00 -0800 (PST)
	mail_from (robj@quid.engr.sgi.com)
Received: (from robj@localhost) by quid.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA16116; Fri, 3 Apr 1998 13:26:59 -0800
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9804031326.ZM16114@quid.engr.sgi.com>
Date: Fri, 3 Apr 1998 13:26:58 -0800
In-Reply-To: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
        "Frame Freeze" (Apr  3, 11:39am)
References: <214A87629D4FD111931F0060972989BA072E6A@VISTA.TACCSF.KIRTLAND.AF.MIL>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Bemis, Suzie CEI-TACCSF" <suzie@taccsf.kirtland.af.mil>,
        "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: Frame Freeze
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

We're running 2 separate 'perfly' executables on an 8 processor ONYX.
> We've bound each perfly to it's own processor using the runon command on
> the command line.  We also have several other processes running on all
> of the other processors.  The display freezes for 1-3 seconds quite
> frequently.  We've tried taking out the runon command and letting the
> perfly run freely on whatever processor it chooses.  This does not stop
> the freezing display.  We've cut the frame rate down to 20.0 HZ and that
> helped the frequent freezes, but it makes the display more jumpy.  Does
> anyone have any suggestions on how to avoid the freezing display?
>
> Should we try to bind the Draw processes to their own processors, and
> put the APP and CULL somewhere else?
>
> Thanks in advance for any help.
>
> Suzie
>
> --Press any key to go on.--
>

Suzie

Sounds like something is fighting for CPU time. I would suggest setting
PFNFYLEVEL 6, look at the Performer Process State messages to see what pids run
on what CPUs then use par -rQQtN where N is enough seconds to catch a freeze (
you'll need to run that as root ). This should show you what processes run on
which CPUs with what priority and also what is switching them on/off CPUs. The
if you see obvious conflicts you can try moving things around. Make sure you
have the latest recommended patchset too to get the latest kernel roll up patch
( see www.sgi.com/support for patchsets ).

Cheers
Rob

-- 
________________________________________________________________
Rob Jenkins mailto:robj@sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 15:22:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA08580 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 15:11:32 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA08553 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 15:11:31 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA7529277
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 15:11:30 -0800 (PST)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA28223
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 15:11:29 -0800 (PST)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA7550394;
	Fri, 3 Apr 1998 15:11:24 -0800 (PST)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA32000; Fri, 3 Apr 1998 15:11:23 -0800 (PST)
Sender: dorbie@sgi.com
Message-ID: <35256C9B.7E5A35ED@sgi.com>
Date: Fri, 03 Apr 1998 15:11:23 -0800
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Steve Baker <sbaker@link.com>
CC: Michael Boccara <boccara@MIT.EDU>, Performer <info-performer@sgi.com>
Subject: Re: ZB limits & Overlaid channels
References: <Pine.SGI.3.96.980403152143.15023A-100000@lechter.bgm.link.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Steve Baker wrote:
> 
> On Fri, 3 Apr 1998, Michael Boccara wrote:
> 
> > Hi Performers,
> >
> > For my space application, I have to use a very large Near/Far range : 1m/1e6km.
> > I chose to superpose 2 channels, sharing all attributes except near/far and draw
> > callback.
> > ChanFG : N = 1m      F = 10km
> > ChanBG : N = 10km    F = 1e6km
> > Better than a long speech, my piece of code is at the end of the message.
> >
> > If I used only 1 channel, it would draw all the scene.
> > While my 2 channels draw 2 complementary parts of the scene, using draw
> > traversal masks.
> > So we should have the same graphic load...
> >
> > BUT using 2 superposed channels is almost twice longer than using only 1 channel
> > !!!
> 
> > 1/ Why does it take longer than using only 1 channel ?
> 
> There are quite a few reasons why it'll take longer:
> 
> * Much more CULL workload (the scene graph has to be traversed twice).
> * Z buffer is cleared twice.
> * (perhaps) Many more state changes since Performer will be
> * (perhaps) Rendering the same material/texture properties once in the
>   near channel and again in the far.
> * There is (presumably) some per-channel overhead in Performer for setting
>   up viewpoint and projection matrixes, clipping planes, etc.
> 
> ...it's a bit suprising that it's *TWICE* as long unless your rendering is
> severely CULL limited (possible - since you only have two CPU's) or has an
> insane number of pfGeoState changes that are happening for pfGeoState that
> appear on both far and near objects.

I agree, try running in APPCULL_DRAW mode. Most of the overheads should
be
extremely small except cull.

> 
> > 2/ What does happen in the pfDraw() function that is uselessly repeated between
> > the 2 channels ?
> 
> It'll be drawing two different display lists - so that isn't (in itself) a
> huge deal.
> 
> > 3/ How come can I call twice pfDraw() without any argument, into each draw
> > callback, letting Performer guess that it is for 2 separate channels ?

No, you only call pfDraw once in each callback for a total of 2 draws,
like
Steve said, the callback is invoked BY the channel class.
I hope this is just a grammatical ambiguity.

> 
> It's not guessing, it knows which channel it is because it knows which
> of your draw callbacks was being called.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 16:02:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA08751 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 15:47:14 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA08724 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 15:47:14 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA7441349
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 15:47:13 -0800 (PST)
Received: from holodeck.engr.sgi.com ([150.166.37.78]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id PAA11913
	for <info-performer@sgi.com>; Fri, 3 Apr 1998 15:47:12 -0800 (PST)
	mail_from (allan@holodeck.engr.sgi.com)
Received: (from allan@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA08721 for info-performer@sgi.com; Fri, 3 Apr 1998 15:47:12 -0800
Date: Fri, 3 Apr 1998 15:47:12 -0800
From: allan@holodeck.engr.sgi.com (Allan Schaffer)
Message-Id: <199804032347.PAA08721@holodeck.engr.sgi.com>
To: info-performer@sgi.com
Subject: New & Improved Performer Web Site
Status: O


Performers,

The Performer Web site in Silicon Surf has been revamped with a lot
of new content, online presentations, and a whole new look.  If you
haven't seen it recently, check it out:

	http://www.sgi.com/Technology/Performer/

In particular, be sure to take a look through the Witches Brew, a
collection of cool tips & techniques to use in your development.
Thanks go to Angus Dorbie for putting together this material.

And coming someday soon: an updated FAQ list :-)

Allan
----
Allan Schaffer                                                allan@sgi.com
Silicon Graphics                               http://reality.sgi.com/allan
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr  3 23:11:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id WAA15693 for info-performer-dist@holodeck.engr.sgi.com; Fri, 3 Apr 1998 22:56:30 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id WAA15666 for <info-performer@holodeck.engr.sgi.com>; Fri, 3 Apr 1998 22:56:29 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id WAA7696139
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 3 Apr 1998 22:56:28 -0800 (PST)
Received: from cupid.dt.nchc.gov.tw (cupid.dt.nchc.gov.tw [140.110.33.240]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id WAA18655; Fri, 3 Apr 1998 22:56:05 -0800 (PST)
	mail_from (c00chu00@nchc.gov.tw)
Received: from nchc.gov.tw (elc044.dt.nchc.gov.tw [140.110.12.28])
	by cupid.dt.nchc.gov.tw (8.8.5/8.8.5) with ESMTP id OAA25628;
	Sat, 4 Apr 1998 14:56:07 +0800 (CST)
Received: (from c00chu00@localhost)
	by nchc.gov.tw (8.8.5/8.8.5) id OAA00737;
	Sat, 4 Apr 1998 14:56:05 +0800 (CST)
From: Sam Chu <c00chu00@nchc.gov.tw>
Message-Id: <199804040656.OAA00737@nchc.gov.tw>
Subject: Re: Stats Question correction
To: info-performer@sgi.com
Date: Sat, 4 Apr 1998 14:56:04 +0800 (CST)
Cc: gischer@sgi.com
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O


>Yesterday I posted a response to a question about stats for a
>multi-channel, single pipe configuration. 
>
>The stats for the channel were reporting something like this:
>
>frame=50.7  app=3.5 cull=5.7 draw=9.2 isect=2.3
>
>The question I got wrong was the interpretation of the "frame" stat.
>This figure is in fact the channel latency, i.e., the length of time from when
>the frame first enters the APP stage to the time when the DRAW stage
>completes. I erroneously reported this as rather the period time of the draw
>stage.  So the numbers are not supposed to add up at all. 

>In more recent versions of Performer the term "frame" has been replaced with 
>"latency".
>

  I still get some confused. I try 'perfly' in a single channel single pipe 
configuration, and got the following result.
  (I run "perfly -m 4 -p 1 esprit.flt" (using APPCULL_DRAW mode))

  15.0/30.0 HZ LOCK APPCULL_DRAW 
  frame = 96.3 app=0.4 cull=1.0 draw=31.2 isect=0.0
 
  I think the reason that app+cull+draw+isect(32.6) in much small than
fram(96.3) is that the process in wait for the Transformation and Fill 
stage to finish. So May I say that app+cull+draw is just for the CPU stage?

(In "Performance Turning & Debugging" chapter said that the Graphics
 pipeline comprises the CPU stage, Transformation stage and Fill statge)
(In "Frame and Load Contril" - Review of Rendering Stage said that
 Draw Issue graphics library commands to a Geometry Pipiline in order to
 create an image for subsequent display)

  If the above is true, how can I measure the time spent in the 
Transformation stage and Fill stage?

  Thank you for your answer.

Sam Chu 
National Center for High-Performance Computing 
Scientific Visualization Lab  Email: c00chu00@nchc.gov.tw 
Tel: (886)35-776085 Ext 248   Fax  : (886)35-773538
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sat Apr  4 04:37:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA16230 for info-performer-dist@holodeck.engr.sgi.com; Sat, 4 Apr 1998 04:22:17 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA16203 for <info-performer@holodeck.engr.sgi.com>; Sat, 4 Apr 1998 04:22:15 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA7730688
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 4 Apr 1998 04:22:15 -0800 (PST)
Received: from beyond.clubfed.sgi.com ([169.238.1.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id EAA05050
	for <info-performer@sgi.com>; Sat, 4 Apr 1998 04:22:14 -0800 (PST)
	mail_from (brian@dingbat.clubfed.sgi.com)
Received: from dingbat.clubfed.sgi.com by beyond.clubfed.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/930416.SGI)
	 id HAA04494; Sat, 4 Apr 1998 07:22:08 -0500
Received: (from brian@localhost) by dingbat.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA27524; Sat, 4 Apr 1998 07:15:10 -0500
Date: Sat, 4 Apr 1998 07:15:10 -0500
From: brian@dingbat.clubfed.sgi.com (Brian Furtaw)
Message-Id: <9804040715.ZM27523@dingbat.clubfed.sgi.com>
In-Reply-To: "Rob Jenkins" <robj@quid.engr.sgi.com>
        "Re: Frame Freeze" (Apr  3,  1:26pm)
References: <214A87629D4FD111931F0060972989BA072E6A@VISTA.TACCSF.KIRTLAND.AF.MIL> 
	<9804031326.ZM16114@quid.engr.sgi.com>
Reply-To: brian@sgi.com
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "'info-performer@sgi.com'" <info-performer@sgi.com>,
        "Bemis, Suzie CEI-TACCSF" <suzie@taccsf.kirtland.af.mil>
Subject: Re: Frame Freeze
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Suzie,

If your running IRIX 6.2 or greater get yourself a copy of Windview run the
apps in single process mode `perfly -m 0' with the runon, command don't pick
CPU 0. Then start `rtmon-client' specifing the CPUs you asked for in the runon
command. i.e. % rtmon-client -o -p <CPUa>,<CPUb> -f pause.test

Let the applications run until a freeze happens then control c or kill the
rtmon-client program. Start up Windview use File->Analyze All to read in the
pause.test* files. Then choose View->New Graph to see what windview found. You
will see a one to three second gap in processing where your apps froze on the
Windview timeline. You can then see what else was running on that CPU while
your app was frozen by scanning up and down the graph.

I used this same technique to debug a customer problem last year and found that
sar was dumping  its data to disk during the freezes. Once sar was turned off
the problem went away. They where using sar to collect a lot of detailed
statistics which required long write backs to disk from memory cache.

If you have any questions don't hesitate to ask,

Brian


On Apr 3,  1:26pm, Rob Jenkins wrote:
> Subject: Re: Frame Freeze
> We're running 2 separate 'perfly' executables on an 8 processor ONYX.
> > We've bound each perfly to it's own processor using the runon command on
> > the command line.  We also have several other processes running on all
> > of the other processors.  The display freezes for 1-3 seconds quite
> > frequently.  We've tried taking out the runon command and letting the
> > perfly run freely on whatever processor it chooses.  This does not stop
> > the freezing display.  We've cut the frame rate down to 20.0 HZ and that
> > helped the frequent freezes, but it makes the display more jumpy.  Does
> > anyone have any suggestions on how to avoid the freezing display?
> >
> > Should we try to bind the Draw processes to their own processors, and
> > put the APP and CULL somewhere else?
> >
> > Thanks in advance for any help.
> >
> > Suzie
> >
> > --Press any key to go on.--
> >
>
> Suzie
>
> Sounds like something is fighting for CPU time. I would suggest setting
> PFNFYLEVEL 6, look at the Performer Process State messages to see what pids
run
> on what CPUs then use par -rQQtN where N is enough seconds to catch a freeze
(
> you'll need to run that as root ). This should show you what processes run on
> which CPUs with what priority and also what is switching them on/off CPUs.
The
> if you see obvious conflicts you can try moving things around. Make sure you
> have the latest recommended patchset too to get the latest kernel roll up
patch
> ( see www.sgi.com/support for patchsets ).
>
> Cheers
> Rob
>
> --
> ________________________________________________________________
> Rob Jenkins mailto:robj@sgi.com
> Silicon Graphics, Mtn View, California, USA
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>
>-- End of excerpt from Rob Jenkins



-- 
    ----oOOo----    ----oOOo----    ----oOOo----    ----oOOo----

Brian Furtaw  (brian@sgi.com)	
VisSim  Technical  Consultant
12200-G  Plum  Orchard  Drive  Office:(301)572-3293   Fax: (301)872-3293	
Silver Spring, Maryland 20904  OpenGL/ImageVision/OpenInventor/Performer

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sun Apr  5 00:04:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA17578 for info-performer-dist@holodeck.engr.sgi.com; Sat, 4 Apr 1998 23:43:49 -0800
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id XAA17551 for <info-performer@holodeck.engr.sgi.com>; Sat, 4 Apr 1998 23:43:47 -0800
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA7878426
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 4 Apr 1998 23:43:47 -0800 (PST)
Received: from cupid.dt.nchc.gov.tw ([140.110.33.240]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id XAA29738
	for <info-performer@sgi.com>; Sat, 4 Apr 1998 23:41:34 -0800 (PST)
	mail_from (c00chu00@nchc.gov.tw)
Received: from nchc.gov.tw (elc044.dt.nchc.gov.tw [140.110.12.28])
	by cupid.dt.nchc.gov.tw (8.8.5/8.8.5) with ESMTP id PAA01146
	for <info-performer@sgi.com>; Sun, 5 Apr 1998 15:41:17 +0800 (CST)
Received: (from c00chu00@localhost)
	by nchc.gov.tw (8.8.5/8.8.5) id PAA00846
	for info-performer@sgi.com; Sun, 5 Apr 1998 15:41:16 +0800 (CST)
From: Sam Chu <c00chu00@nchc.gov.tw>
Message-Id: <199804050741.PAA00846@nchc.gov.tw>
Subject: normal angle of FOV
To: info-performer@sgi.com
Date: Sun, 5 Apr 1998 15:41:15 +0800 (CST)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

Dear Performers:

  IF I want to simulate the normal angle lens(neither wide angle nor
telephoto)of the camera(I think which is 50mm) which Field of View 
should I set ? (My window size is 640x480 )

  The programming Guide mention the default value of FOV is 45, 
Can  that value let people just like to see throught from a normal 
angle lens(or mirror)? 


  Thank you for your answer in advance.

Sam Chu 
National Center for High-Performance Computing 
Scientific Visualization Lab  Email: c00chu00@nchc.gov.tw 
Tel: (886)35-776085 Ext 248   Fax  : (886)35-773538
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sun Apr  5 18:57:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA18728 for info-performer-dist@holodeck.engr.sgi.com; Sun, 5 Apr 1998 18:37:45 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA18701 for <info-performer@holodeck.engr.sgi.com>; Sun, 5 Apr 1998 18:37:44 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA8195759
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 5 Apr 1998 18:37:43 -0700 (PDT)
Received: from imo17.mx.aol.com (imo17.mx.aol.com [198.81.17.39]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id SAA06769; Sun, 5 Apr 1998 18:37:20 -0700 (PDT)
	mail_from (PASociety@aol.com)
Received: from PASociety@aol.com
	by imo17.mx.aol.com (IMOv13.ems) id FEYSa16332
	for <info@pasociety.org>; Sun, 5 Apr 1998 20:55:59 -0500 (EDT)
From: PA Society <PASociety@aol.com>
Message-ID: <10cadc59.35282822@aol.com>
Date: Sun, 5 Apr 1998 20:55:59 EDT
To: info@pasociety.org
Mime-Version: 1.0
Subject: Facial Animation Meeting on May 4th
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Mailer: AOL 3.0 for Windows 95 sub 18
Status: O

           MARK YOUR CALENDARS IN EARLY MAY !!

*************************    IMPORTANT ANNOUNCEMENT
***************************

THE PERFORMANCE ANIMATION SOCIETY KICKS OFF THE COMPUTER
GAME DEVELOPERS CONFERENCE MONDAY (MAY 4th) EVENING WITH
AN EXCITING PRESENTATION ON CREATING REALISTIC FACIAL ANIMATION
IN COMPUTER GAMES.

******************************************************************************
*****************

MEETING HIGHLIGHT:         "Computer Games get a Face Lift"


TIME & PLACE:   COMPUTER GAME DEVELOPERS CONFERENCE
                MONDAY, MAY 4th at 7:00PM Sharp!
                LONG BEACH CONVENTION CENTER ROOM 103A

The "Performance Animation Society", the world's premier organization
for artists and developers working with the exciting new tools of human
digitization and simulation, will present a 1 + 1/2 hour seminar at the
Computer Games Developers Conference in Long Beach, CA. in Room 103A in
the Long Beach Convention Center on Monday, May 4th at 7:00 PM sharp.

MEETING DETAILS AND PRESENTATIONS:

TOPIC:   "COMPUTER GAMES GET A FACE LIFT"

Motion Capture and Performance Animation techniques are valuable tools
in adding realism to character animation in Computer Games. These tools
are being focused and refined even further to meet a growing need for
believable, accurate facial animation in gaming characters.

Motion Analysis Corporation, a leading solutions provider in human motion
and performance capture will present late-breaking developments and
applications of facial expression capture and image processing as they
apply to enhancing expressiveness in computer game characters.

Videos and demonstrations will also augment this exciting meeting of
artists, developers, scientists and performers. The meeting is free and
all who are interested are welcome and encouraged to attend this exciting
meeting.


FOR ADDITIONAL INFORMATION PLEASE VISIT OUR WEBSITE AT:

 WWW.PASOCIETY.ORG

THANK YOU
***********************   PLEASE CIRCULATE !!!! ***********************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 01:07:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA19189 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 00:51:48 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id AAA19162 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 00:51:47 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA8273501
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 00:51:46 -0700 (PDT)
Received: from flaska.autosim.no (port01.nord.eunet.no [195.1.163.162]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id AAA16283
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 00:51:43 -0700 (PDT)
	mail_from (inge@autosim.no)
Received: from david by flaska.autosim.no with smtp
	(Linux Smail3.2.0.92 #1) id m0yM7fE-000vtvC; Mon, 6 Apr 1998 10:54:00 +0200 (MET DST)
Message-ID: <001801bd6130$fb214cf0$2902a8c0@david.autosim.no>
Reply-To: "Inge E.Henriksen" <inge@autosim.no>
From: "Inge E.Henriksen" <inge@autosim.no>
To: <info-performer@sgi.com>
Subject: Re:Frame Freeze
Date: Mon, 6 Apr 1998 09:52:43 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Status: O

Hello
-------
Thought I would say that a bad structure in your model-hiarky might cause
such a problem. If you are using a large terrain database then this might be
it. If the model-hiarky is not made in a clever way you might have a freeze
now-and then in your simulation, caused by the culling-process. A good way
of modeling a terrain database would be as follows:
Have one top group that contains all the polygons in sub-groups, these
subgroups(let's say we have ten of them ) contains all the polygons inside a
defined area(let's say 1000x1000 feet ). These sub-groups have their own
sub-groups that (let's say that there are ten of these also) contain all the
polygons inside a defined area(let's say 100x100 feet).These sub-groups
might contain sub-groups too.
This way the culling-process can early elliminate which polygons should not
be culled an which that should. If one of the top groups is first culled
away the culling-process will not try to cull the sub-groups also. If you on
the other hand have modeled just a top group with lot's of polygons attached
to it, the culling-process will have a much harder task to perform.

Hope this will help :)


Greetings from
---------------------------------------------------------------------------
Inge E.Henriksen, Database designer
Autosim A/S, P.B.2303, 9001 Tromsoe, Norway
Tlf.+47 77675075, fax +47 77676701
---------------------------------------------------------------------------
*****************************************John.3.16-21
---------------------------------------------------------------------------
>***************************************************************************
***
>
> From: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
> Date: Fri, 3 Apr 1998 11:39:09 -0700
> Subject: Frame Freeze
>
>This message is in MIME format. Since your mail reader does not understand
>this format, some or all of this message may not be legible.
>
>------ =_NextPart_001_01BD5F2F.CA63EF70
>Content-Type: text/plain
>
>We're running 2 separate 'perfly' executables on an 8 processor ONYX.
>We've bound each perfly to it's own processor using the runon command on
>the command line.  We also have several other processes running on all
>of the other processors.  The display freezes for 1-3 seconds quite
>frequently.  We've tried taking out the runon command and letting the
>perfly run freely on whatever processor it chooses.  This does not stop
>the freezing display.  We've cut the frame rate down to 20.0 HZ and that
>helped the frequent freezes, but it makes the display more jumpy.  Does
>anyone have any suggestions on how to avoid the freezing display?
>
>Should we try to bind the Draw processes to their own processors, and
>put the APP and CULL somewhere else?
>
>Thanks in advance for any help.
>
>Suzie
>
>------ =_NextPart_001_01BD5F2F.CA63EF70
>Content-Type: text/html
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
><HTML>
><HEAD>
><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>charset=3DUS-ASCII">
><META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
>5.5.1960.3">
><TITLE>Frame Freeze</TITLE>
></HEAD>
><BODY>
>
><P><FONT SIZE=3D2>We're running 2 separate 'perfly' executables on an 8 =
>processor ONYX.&nbsp;&nbsp; We've bound each perfly to it's own =
>processor using the runon command on the command line.&nbsp; We also =
>have several other processes running on all of the other =
>processors.&nbsp; The display freezes for 1-3 seconds quite =
>frequently.&nbsp; We've tried taking out the runon command and letting =
>the perfly run freely on whatever processor it chooses.&nbsp; This does =
>not stop the freezing display.&nbsp; We've cut the frame rate down to =
>20.0 HZ and that helped the frequent freezes, but it makes the display =
>more jumpy.&nbsp; Does anyone have any suggestions on how to avoid the =
>freezing display?&nbsp; </FONT></P>
>
><P><FONT SIZE=3D2>Should we try to bind the Draw processes to their own =
>processors, and put the APP and CULL somewhere else?</FONT>
></P>
>
><P><FONT SIZE=3D2>Thanks in advance for any help.</FONT>
></P>
>
><P><FONT SIZE=3D2>Suzie</FONT>
></P>
>
></BODY>
></HTML>
>------ =_NextPart_001_01BD5F2F.CA63EF70--
>
>***************************************************************************
***
>

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 07:17:19 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA19729 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 07:06:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA19702 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 07:06:35 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA8390929
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 07:06:35 -0700 (PDT)
Received: from ns1.sara.nl (ns1.sara.nl [145.100.5.30]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA00969
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 07:06:27 -0700 (PDT)
	mail_from (wilfred@sara.nl)
Received: from barney.sara.nl (barney.sara.nl [192.42.131.71])
	by ns1.sara.nl (8.8.3/8.8.8) with ESMTP id QAA00589;
	Mon, 6 Apr 1998 16:06:31 +0200 (MET DST)
Message-ID: <3528E14A.DCAED77@sara.nl>
Date: Mon, 06 Apr 1998 16:06:02 +0200
From: Wilfred Janssen <wilfred@sara.nl>
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: asdfly question
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hello All,

I'm trying to use a user defined call back function for the LOD
evaluation with ASD. I compiled asdfly (Perf 2.2) and did some testing.
When I set the evaluation method to Pixel Bound (Which is a user defined
evaluation function) the evaluation function (lodEvalFunc) is never
called. The lodEvalFunc_pass function is called every frame and
lodEvalFunc_init is called once.
So I guess the evaluation is still done on basis of the distance and not
through the evaluation function. How can I make sure that the evaluation
function is used (and is this a bug in asdfly or am I doing something
wrong??)

Regards,

Wilfred

-- 
===================================================================
| Wilfred Janssen                         SARA                    |
| Project Manager CAVE                    P.O. Box 94613          |
| Consultant Scientific Computing         1090 GP Amsterdam       |
| Academic Computing Services Amsterdam   The Netherlands         |
|                                                                 |
| Phone: +31 (0) 20 592 3000              e-mail: wilfred@sara.nl |
| Fax:   +31 (0) 20 668 3167              URL: http://www.sara.nl |
===================================================================
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 07:58:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA19835 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 07:49:17 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA19808 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 07:49:16 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA8397279
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 07:49:16 -0700 (PDT)
Received: from vista.taccsf.kirtland.af.mil (vista.taccsf.kirtland.af.mil [132.62.150.76]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA13203
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 07:49:14 -0700 (PDT)
	mail_from (Sorroche@TACCSF.KIRTLAND.AF.MIL)
Received: by VISTA.TACCSF.KIRTLAND.AF.MIL with Internet Mail Service (5.5.1960.3)
	id <H8JMC5CQ>; Mon, 6 Apr 1998 08:49:12 -0600
Message-ID: <214A87629D4FD111931F0060972989BA09033C@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Missile Trails
Date: Mon, 6 Apr 1998 08:48:59 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD616B.224AE0F0"
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD616B.224AE0F0
Content-Type: text/plain

People;

	I'm working with Suzi Bemis on our Performer upgrade at TACCSF.
I'm working on missile trails.  I got some Open GL code from the
training course which creates a missile trail, then attaches it to a
model using the model's present location.  I converted the code to Iris
GL, then put the function call after a missile is fired, and the GL draw
code before our HUD function is drawn.  The missile trails are drawn on
our HUD.  Next, I put the GL code in PostDraw, and it seems PostDraw is
never called.  I have two questions.  First, is there a way to draw a
missile trail using performer functions rather that Iris GL, and second,
where would one put the function call and draw code?

Thanks

Joe


------ =_NextPart_001_01BD616B.224AE0F0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>Missile Trails</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">People;</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I'm working with Suzi Bemis on our Performer upgrade at =
TACCSF.&nbsp; I'm working on missile trails.&nbsp; I got some Open GL =
code from the training course which creates a missile trail, then =
attaches it to a model using the model's present location.&nbsp; I =
converted the code to Iris GL, then put the function call after a =
missile is fired, and the GL draw code before our HUD function is =
drawn.&nbsp; The missile trails are drawn on our HUD.&nbsp; Next, I put =
the GL code in PostDraw, and it seems PostDraw is never called.&nbsp; I =
have two questions.&nbsp; First, is there a way to draw a missile trail =
using performer functions rather that Iris GL, and second, where would =
one put the function call and draw code?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Joe</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD616B.224AE0F0--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 09:29:15 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA20424 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 09:23:06 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA20398 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 09:23:04 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA8417943
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 09:23:04 -0700 (PDT)
Received: from mercurio.interbook.net (mercurio.interbook.net [194.224.78.15]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA18772
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 09:23:01 -0700 (PDT)
	mail_from (ct3msi@interbook.net)
Received: from ct3msi.interbook.net (ppp3157.interbook.net [195.57.28.157])
	by mercurio.interbook.net (8.8.8/8.8.8) with SMTP id QAA09131
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 16:24:30 GMT
From: "Ct3" <ct3msi@interbook.net>
To: "info-performer" <info-performer@sgi.com>
Date: Mon, 6 Apr 1998 19:22:47 -0500
Message-ID: <01bd61bb$4aa13760$9d1c39c3@ct3msi.interbook.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0012_01BD6191.61CB2F60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Status: O

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01BD6191.61CB2F60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Performers:

I am trying to define the angle for my projection system and some people =
says that I can use angles until 70=BA, but other people says that more =
than 45=BA disturb and provides strange images. Do you know something =
about it?. Thanks.

Susi=20

------=_NextPart_000_0012_01BD6191.61CB2F60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Hello =
Performers:</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>I am trying to define =
the angle for=20
my projection system and some people says that I can use angles until =
70&ordm;,=20
but other people says that more than 45&ordm; disturb and provides =
strange=20
images. Do you know something about it?. Thanks.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3DArial =
size=3D2>Susi&nbsp;</FONT></DIV></BODY></HTML>

------=_NextPart_000_0012_01BD6191.61CB2F60--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 09:11:01 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA20153 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 08:54:07 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA20126 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 08:54:06 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA8405882
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 08:54:05 -0700 (PDT)
Received: from crcg.edu ([205.245.135.125]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id IAA07446
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 08:54:03 -0700 (PDT)
	mail_from (gnewton@crcg.edu)
Received: from peregrine by crcg.edu (SMI-8.6/SMI-SVR4)
	id LAA17515; Mon, 6 Apr 1998 11:59:31 -0400
Reply-To: <gnewton@crcg.edu>
From: "Greg Newton" <gnewton@crcg.edu>
To: "Info-Performer" <info-performer@sgi.com>
Subject: changing cursors
Date: Mon, 6 Apr 1998 11:49:56 -0400
Message-ID: <000901bd6173$a5e7b100$b087f5cd@peregrine.crcg.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Status: O


Hi,

Does anyone have a snippet of code that will show me how to dynamically
change the cursor in a Performer application?  I've read the pfuCursor man
page but I have to confess it confuses me a bit.

Thanks,
Greg


---
Greg Newton                 | gnewton@crcg.edu                       |
Researcher, Fraunhofer CRCG | (401) 453-6363 (x104)                  |
321 South Main St, Suite 2  | (401) 453-0444 (fax)                   |
Providence, RI 02903  USA   | http://www.crcg.edu/Staff/gnewton.html |

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 09:29:12 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA20303 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 09:14:04 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA20276 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 09:14:03 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA7913598
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 09:14:02 -0700 (PDT)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA15465
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 09:14:01 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id SAA22192; Mon, 6 Apr 1998 18:22:11 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma022188; Mon, 6 Apr 98 18:22:03 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id SAA05148;
	Mon, 6 Apr 1998 18:13:46 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804061613.SAA05148@s00sn1.fel.tno.nl>
Subject: Re: Enabling channels
To: erik.heuer@ks-t.no (Erik Heuer)
Date: Mon, 6 Apr 1998 18:13:45 +0200 (MET DST)
Cc: info-performer@sgi.com (Performer)
In-Reply-To: <01BD4B90.BFCD7990@PC127> from "Erik Heuer" at Mar 9, 98 07:22:48 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> 
> Hi,
> 
> I have a dual pipe (2+4RM) Onyx2 IR with 2 DG-8 boards (16 channels).  In ircombine I define (up to) 8 channels per pipe.  In order to not exceed the fill bandwidth, I disable some of the channels (i.e. check off the enable switch in the channel attributes dialog).  
> 
> How can I during runtime enable and disabled combinations of the defined channels ?  
To reduce fill bandwith you must disable the performer channel by setting
the traversal mode for the DRAW traversal to PF_OFF.

> 
> Regards,
> Erik Heuer, Kongsberg Simulation & Training, 3600 Kongsberg, Norway
> E-mail: erik.heuer@ks-t.no  Phone:(+47) 32735766 Fax:(+47) 32736965

Mario
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 10:31:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA21026 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 10:30:39 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA20999 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 10:30:38 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA8428826
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 10:30:36 -0700 (PDT)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA20132
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 10:30:34 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id MAA28100; Mon, 6 Apr 1998 12:29:52 -0500 (CDT)
Date: Mon, 6 Apr 1998 12:30:36 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Ct3 <ct3msi@interbook.net>
cc: info-performer <info-performer@sgi.com>
Subject: Re: your mail
In-Reply-To: <01bd61bb$4aa13760$9d1c39c3@ct3msi.interbook.net>
Message-ID: <Pine.SGI.3.96.980406121637.8090B-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
Status: O

On Mon, 6 Apr 1998, Ct3 wrote:

> I am trying to define the angle for my projection system and
> some people says that I can use angles until 70=BA, but other people
> says that more than 45=BA disturb and provides strange images.=20
> Do you know something about it?. Thanks.

(NOTE: I'm talking angle-subtended-by-screen-at-eyepoint here -
some people talk "half-angles" - make sure you know which you are
talking about)

* If you are projecting onto a FLAT screen then there is no distortion
  in the image for any field of view up to some point just under 180
  degrees. At or beyond 180 degrees everything screws up big time!

  The Z buffer precision for objects at the edges of very wide angle
  displays becomes a bit of a problem - and the kludgy way that
  fog is implemented is certainly a problem with wide FOV.

* If you are projecting onto a curved screen (without some kind of
  distortion correction) then in principal even a 1 degree field of
  view has *some* distortion - and the maximum field of view that
  you can tolerate is very much an application-specific thing.

  Sometimes you can reduce the worst effects of distortion by
  adjusting the controls on the projector - but you really
  can't eliminate it properly by doing that.

  There are ways of doing much better distortion correction
  using Performer/OpenGL - but the price you pay in performance
  is pretty steep. Also, the distortion correction that
  is often suggested in these circumstances is never perfect
  and will cause either some fuzziness or some aliasing (or
  perhaps some compromise with both aliasing and fuzziness)
  depending on how it is set up.

Either way, there is no 'hard' limit at either 45 or 70 degrees.

Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 10:33:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA21057 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 10:31:36 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA21030 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 10:31:34 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA8458834
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 10:31:34 -0700 (PDT)
Received: from archimedes.vislab.navy.mil (archimedes.chinalake.navy.mil [129.131.31.8]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA20756
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 10:31:32 -0700 (PDT)
	mail_from (jan@archimedes.vislab.navy.mil)
Received: (jan@localhost) by archimedes.vislab.navy.mil (8.7.5/8.x-CL-SOS5.3) id KAA19461; Mon, 6 Apr 1998 10:40:06 -0700 (PDT)
From: Jan Barglowski <jan@archimedes.vislab.navy.mil>
Posted-Date: Mon, 6 Apr 1998 10:40:06 -0700 (PDT)
Message-Id: <199804061740.KAA19461@archimedes.vislab.navy.mil>
Subject: Re: C++ cliptexures...
To: jan@archimedes.vislab.navy.mil (Jan Barglowski)
Date: Mon, 6 Apr 1998 10:40:06 -0700 (PDT)
Cc: info-performer@sgi.com
In-Reply-To: <199804012321.PAA28898@archimedes.vislab.navy.mil> from "Jan Barglowski" at Apr 1, 98 03:21:17 pm
X-Mailer: ELM [version 2.4 PL24 ME8b]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

Jan Barglowski wrote:
> I've created a virtual cliptexure callback that works when used in
> conjunction with clipfly.  When I took this function and put it 
> into perfly, my virtual cliptextures no longer work!  I've printed
> out the values for VirtualLODOffset, NumEffectiveLevels, and LODRange
> and they are identical for both programs.
> 
> My symptoms are a rapid sharpening/blurring of the virtual cliptexture
> when zooming in or out towards it.  It doesn't seem to matter what
> speed I zoom at.  Since the numbers calculated for the above parameters
> work with clipfly, I'm assuming I'm doing the calculations correctly.
> And when I comment out the tile-by-tile cliptexture updates, the 
> cliptexture acts as if it's on Level=0.
> 
> I think this is one of two things:
> 1) Clipfly does something for virtual cliptextures that perfly
>    doesn't.  And I can't find what this is!  I looked at the README
>    file for clipfly, and the consideration for viewpoint update
>    shouldn't cause this (am I right?).  The only thing I can figure
>    is some of the parameters that control cliptextures are getting
>    some (important) initialization in clipfly.  Yet I look at 
>    virtcliptexture.c and don't see a lot of these values getting
>    set at all.  Any ideas for what I'm missing?
> 2) the C++ cliptexture functions don't work, but I'd hate to think
>    this is the case.  Still, anyone do virtual cliptextures with
>    C++ bindings out there?
> 
> Any hints/help/insight will be appreciated!

Well, I figured this one out.  In my C code is used the pfuSetVirtualParams().
The C++ man pages do not list an analogous function!  So I used the pair
of functions setVirtualLODOffset() and setNumEffectiveLevels().  Until
I hunted down the .ct file loader, which is the only C++ virtual cliptexure
example program I could find, I didn't know there was a setVirtualParams()
function.  In short, setVirtualParams() must do a little something more
than setVirtualLODOffset() and setNumEffectiveLevels().  Just wish this
function was in the man pages -- it could've saved a lot of work...

jan

-- 
Jan Anthony Barglowski	              jan@chinalake.navy.mil
Real-time Computer Graphics           http://www1.ridgecrest.ca.us/~jan
Naval Air Warfare Center, China Lake  (760) 927-1057
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 10:28:52 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA20977 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 10:19:25 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA20950 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 10:19:20 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA8420951
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 10:19:19 -0700 (PDT)
Received: from vacherin.geo.unizh.ch (mail.geo.unizh.ch [130.60.176.42]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA14915
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 10:19:13 -0700 (PDT)
	mail_from (hilko@geo.unizh.ch)
Received: from lynx.geo.unizh.ch ([130.60.176.27]) by vacherin.geo.unizh.ch
          (Post.Office MTA v3.1.2 release (PO203-101c)
          ID# 0-42730U500L100S0) with SMTP id AAA11433
          for <info-performer@sgi.com>; Mon, 6 Apr 1998 19:19:08 +0200
Received: from geo.unizh.ch by lynx.geo.unizh.ch (950413.SGI.8.6.12) id TAA16752; Mon, 6 Apr 1998 19:19:02 +0200
Sender: hilko@geo.unizh.ch (Hilko Hoffmann)
Message-ID: <35290E85.73B1470B@geo.unizh.ch>
Date: Mon, 06 Apr 1998 19:19:02 +0200
From: Hilko Hoffmann <hilko@geo.unizh.ch>
Organization: Uni Zuerich, Remote Sensing Lab
X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX64 6.4 IP30)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: draw process crashes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi Performers,

we try to port our application from an ONYX IR
with 8 CPUs to our  2 CPU Octane MXE  with
Performer 2.2 (N64)

If we load max. 5 nodes (tiles) everthing works
fine but if we load more than 5 tiles the
application crashes

PF Notice:                     Caught SIGCHLD.
Exiting due to death of child with pid 16714.



16714 is the draw process

The number of triangles and the size of textures
seems not to be the reason...


Any help will be appreciated!

regards

Hilko



--
****************************************************************
Hilko Hoffmann
Remote Sensing Laboratories;    University of Zurich
Winterthurerstrasse 190; CH-8057 Zurich; Switzerland
Phone: +41 - 1 / 63 56519; FAX:   +41 - 1 / 63 56842
mailto:hilko@geo.unizh.ch
http://www.geo.unizh.ch/rsl1/lvg/research/
****************************************************************



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 11:03:01 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA21177 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 10:50:47 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA21150 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 10:50:45 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA8420831
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 10:50:44 -0700 (PDT)
Received: from bhole2.cae.ca (postit.cae.ca [142.39.200.51]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id KAA29354
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 10:50:43 -0700 (PDT)
	mail_from (mayer@poster.cae.ca)
Received: 	id MAA25766; Mon, 6 Apr 1998 12:18:53 -0400
Received: by gateway id AA91043; Mon, 6 Apr 1998 12:15:13 -0400
Received: by gateway id MAA04519; Mon, 6 Apr 1998 12:19:48 -0400
Sender: mayer@poster.cae.ca
Message-Id: <352900A4.59E2@cae.ca>
Date: Mon, 06 Apr 1998 12:19:48 -0400
From: Sylvain Mayer <mayer@poster.cae.ca>
Organization: CAE Electronics Ltd
X-Mailer: Mozilla 3.01SC-SGI (X11; I; IRIX 6.2 IP22)
Mime-Version: 1.0
To: info-performer@sgi.com
Subject: clipmap on other HW than IR
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi,

how come clipmap are available only on IR systems?

Is there a chance to see it running on the O2?

thanks

-- 
Sylvain Mayer, 3D Graphics Developer
CAE Electronics Ltd. (http://www.cae.ca)
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 11:03:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA21377 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 11:00:19 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA21350 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 11:00:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA7893681
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 11:00:17 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA03176
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 11:00:14 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA8405531
	for <@cthulhu.engr.sgi.com:info-performer@sgi.com>;
	Mon, 6 Apr 1998 11:00:03 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA03422 for <info-performer@sgi.com>; Mon, 6 Apr 1998 11:00:03 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35291822.6BA1E465@sgi.com>
Date: Mon, 06 Apr 1998 11:00:02 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Frame Freeze
References: <001801bd6130$fb214cf0$2902a8c0@david.autosim.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Are you building the scene graphand / or making any system calls
such as disk i//0 in your application?

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 11:39:00 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA21600 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 11:28:26 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA21573 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 11:28:26 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA8448112
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 11:28:25 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA16753
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 11:28:24 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA8158572;
	Mon, 6 Apr 1998 11:28:23 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA03548; Mon, 6 Apr 1998 11:28:22 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35291EC6.7D4C7871@sgi.com>
Date: Mon, 06 Apr 1998 11:28:22 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
CC: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: Missile Trails
References: <214A87629D4FD111931F0060972989BA09033C@VISTA.TACCSF.KIRTLAND.AF.MIL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

> Sorroche, Joe CEI-TACCSF wrote:
> 
> People;
> 
>         I'm working with Suzi Bemis on our Performer upgrade at
> TACCSF.  I'm working on missile trails.  I got some Open GL code from
> the training course which creates a missile trail, then attaches it to
> a model using the model's present location.  I converted the code to
> Iris GL, then put the function call after a missile is fired, and the
> GL draw code before our HUD function is drawn.  The missile trails are
> drawn on our HUD.  Next, I put the GL code in PostDraw, and it seems
> PostDraw is never called.  I have two questions.  First, is there a
> way to draw a missile trail using performer functions rather that Iris
> GL, and second, where would one put the function call and draw code?

You should use pfFluxed attributes on a geoset.

What pletform are you running on?
You _really_ should use OpenGL on IMPACT, OCTANE or iR, using geoset
geometry should ease the transition.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 11:52:18 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA21785 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 11:46:57 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA21758 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 11:46:56 -0700
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id LAA18895; Mon, 6 Apr 1998 11:46:55 -0700 (PDT)
Date: Mon, 6 Apr 1998 11:46:55 -0700 (PDT)
Message-Id: <199804061846.LAA18895@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: Sam Chu <c00chu00@nchc.gov.tw>
cc: info-performer@puget.engr.sgi.com
Subject: Re: Stats Question correction
In-Reply-To: <199804040656.OAA00737@nchc.gov.tw>
References: <199804040656.OAA00737@nchc.gov.tw>
Status: O

Sam Chu writes:
 > 
 > 
 >   I still get some confused. I try 'perfly' in a single channel single pipe 
 > configuration, and got the following result.
 >   (I run "perfly -m 4 -p 1 esprit.flt" (using APPCULL_DRAW mode))
 > 
 >   15.0/30.0 HZ LOCK APPCULL_DRAW 
 >   frame = 96.3 app=0.4 cull=1.0 draw=31.2 isect=0.0
 >  
I believe that you are running on an mp system using at least two
processors (since you are in APPCULL_DRAW mode, more won't matter).

 >   I think the reason that app+cull+draw+isect(32.6) in much small than
 > fram(96.3) is that the process in wait for the Transformation and Fill 
 > stage to finish. So May I say that app+cull+draw is just for the CPU stage?
 > 

The label "frame" appears to be causing a great deal of confusion
here.  Recall the picture of Performer's pipe

APP    | Frame 1  |  Frame 2 |  Frame 3 | Frame 4 | etc

CULL   |          |  Frame 1 |  Frame 2 | Frame 3 | etc

DRAW   |          |          |  Frame 1 | Frame 2 | etc

If 30.0 Hz is the target frame rate then the target from one pipe
stage boundary to the next is 33.3 ms.

However, the time reported with the label "frame" is a latency time,
and measures the time from when the frame starts the APP stage, to
when it completes the draw stage.  Ignoring special cases, this time
is 3 times as long as the time for a single stage.  Three time 33.3 is
100, so 96.3 is about right.

The app time of 0.4 means that the APP stage finished very quickly,
and then hung around for a long time waiting for the next pfSynch(),
so it could start the CULL stage.  Likewise for the cull time.
For each of the stages, Performer measures the time from the beginning
of that stage for the frame to when it completes its work, not to the
synch boundary, since that wouldn't be a very interesting number

Here's the picture again with annotations for what time each of 
the stats measures.


APP    | Frame 1  |  Frame 2 |  Frame 3 | Frame 4 | etc
app    |<----->A1
CULL   |          |  Frame 1 |  Frame 2 | Frame 3 | etc
cull              |<------>C1
DRAW   |          |          |  Frame 1 | Frame 2 | etc
draw                         |<---->D1
frame  |<-------------------------->D1

A1 = APP stage completes on frame 1
C1 = APP stage completes on frame 1
D1 = Draw stage completes on frame 1

But this begs the question, why, if my draw time is 31.3, and my
latency is 96.3, am I not getting a frame rate of 30hz?

As it turns out, in perfly there are two contributions to the DRAW
stage which are not measured by the perfly stats, pre-draw and
post-draw. 

In perfly, the GUI is drawn in the pre-draw phase, and statistics are
drawn in the post-draw phase.  Together, they could easily take up
enough time (about 2 msecs) to push your application over the 33.3 ms
mark.  The printed displays do not measure these times, but you can
glean this information from the graphical display by noticing that the
line representing the DRAW stage of a frame doesn't start quite at the
boundary (because of the pre-draw time before it), and is extended by
a dotted line after it (representing post-draw time).  

The draw time *does* include transformation and fill.

Okay, so if that explains why we are running at 15hz instead of 30,
then why isn't the latency equal to about 66.6+66.6+31.3 =  164.5?

This is because you are running in LOCK mode.  In LOCK mode, the
picture I gave above gets more complicated (assuming you are missing
the target rate in the draw stage):

APP    | F1  |  F2 |  F3 | F4 | F5 | F6 | F7 | F8 | etc
app    |<-->A1
CULL   |     |  F1 |  F2 | F3 | F4 | F5 | F6 | F7 | F8 | etc
cull         |<-->C1
DRAW   |     |     |  F1 | F1 | F3 | F3 | F5 | F5 | F7 | F7 | etc
draw               |<------->D1
frame  |<------------------->D1

In LOCK mode the APP and CULL stages start each frame at the target
frame rate, and the DRAW stage merely ignores frames that it wasn't
ready to draw at the proper time, hence, in your case, it displays
only every other frame.  But the latency from beginning of pipe to end
is smaller, on the order of 33.3+33.3+31.2 =  97.8 which is very close
to the reported latency of 96.3.

 >   If the above is true, how can I measure the time spent in the 
 > Transformation stage and Fill stage?
 > 

So, to summarize, the missing time (about 2ms) is due probably to GUI
and the stats display rendering.  It is not due to fill time, which is
measured and included in the "draw" time.

------------------------------------------------------------------------
Jay L Gischer        +  "I see great things in baseball.  It's our game.
Advanced Graphics    +  It will repair our losses and be a blessing to
Software             +  us."
Silicon Graphics     +    -Walt Whitman
(415) 390-4277       +    
gischer@sgi.com      +  "A life has no meaning except in the impact it
                     +  has on other lives"
                     +    -Jackie Robinson

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 11:38:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA21659 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 11:32:14 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA21632 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 11:32:13 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA8478517
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 11:32:13 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA18435
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 11:32:11 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA8459247;
	Mon, 6 Apr 1998 11:32:10 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA03479; Mon, 6 Apr 1998 11:32:10 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35291FAA.E0C6B1A3@sgi.com>
Date: Mon, 06 Apr 1998 11:32:10 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
CC: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: Missile Trails
References: <214A87629D4FD111931F0060972989BA09033C@VISTA.TACCSF.KIRTLAND.AF.MIL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

> Sorroche, Joe CEI-TACCSF wrote:
> 
> People;
> 
>         I'm working with Suzi Bemis on our Performer upgrade at
> TACCSF.  I'm working on missile trails.  I got some Open GL code from
> the training course which creates a missile trail, then attaches it to
> a model using the model's present location.  I converted the code to
> Iris GL, then put the function call after a missile is fired, and the
> GL draw code before our HUD function is drawn.  The missile trails are
> drawn on our HUD.  Next, I put the GL code in PostDraw, and it seems
> PostDraw is never called.  I have two questions.  First, is there a
> way to draw a missile trail using performer functions rather that Iris
> GL, and second, where would one put the function call and draw code?
> 

Sorry here's the answer to your second question.

Make the call to draw the missiles immediately after you call pfDraw
in the channel draw callback, if you use the gl.

Perfly is a bit screwed up because it has redundant application level
callbacks and callbacks within callbacks instead of simply leaving it
to the programmer to use the Performer callbacks. Look for the pfDraw
call and follow the calls in the rest of the channel draw callback and
you'll see what I mean.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 11:52:19 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA21746 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 11:42:44 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA21719 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 11:42:44 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA8494914
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 11:42:42 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA22652
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 11:42:41 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA8453710;
	Mon, 6 Apr 1998 11:42:40 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA03576; Mon, 6 Apr 1998 11:42:39 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3529221F.D048298A@sgi.com>
Date: Mon, 06 Apr 1998 11:42:39 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Steve Baker <sbaker@link.com>
CC: Ct3 <ct3msi@interbook.net>, info-performer <info-performer@sgi.com>
Subject: Re: your mail
References: <Pine.SGI.3.96.980406121637.8090B-100000@lechter.bgm.link.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by cthulhu.engr.sgi.com id LAA8468345
Status: O

Steve Baker wrote:
>=20
> On Mon, 6 Apr 1998, Ct3 wrote:
>=20
> > I am trying to define the angle for my projection system and
> > some people says that I can use angles until 70=BA, but other people
> > says that more than 45=BA disturb and provides strange images.
> > Do you know something about it?. Thanks.

This is because they don't move their eye w.r.t. the display surface.

The FOV in a simulator should be determined by the display and the
position of the eye w.r.t. that display. So sit in the design eyepoint
with a protractor and measure the angle of the fullk screen horizontally
and vertically. That's the horizontal and vertical FOV you need.
Anything
else either too narrow or too wide will distorted.

The wider the FOV the poorer the resolution in the center of the
channel because your eye is basically too close to the screen.


>=20
> (NOTE: I'm talking angle-subtended-by-screen-at-eyepoint here -
> some people talk "half-angles" - make sure you know which you are
> talking about)
>=20
> * If you are projecting onto a FLAT screen then there is no distortion
>   in the image for any field of view up to some point just under 180
>   degrees. At or beyond 180 degrees everything screws up big time!
>=20
>   The Z buffer precision for objects at the edges of very wide angle
>   displays becomes a bit of a problem - and the kludgy way that
>   fog is implemented is certainly a problem with wide FOV.

I disagree with the zbuffer part, in fact I'd say precision _better_ by
range at the sides because you have nearer z for equivalent range. The
penalty is ofcourse the clip is in z not range but this is trivial. Fog
is a problem because it's z fog and not range fog so I agree with you
there.

Cheers,Angus.



--=20
"Only the mediocre are always at their best." -- Jean Giraudoux=20

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 12:24:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA22269 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 12:16:57 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA22242 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 12:16:55 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA8460923
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 12:16:55 -0700 (PDT)
Received: from ait.nrl.navy.mil (ait.nrl.navy.mil [132.250.128.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA07907
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 12:16:52 -0700 (PDT)
	mail_from (ekuo@ait.nrl.navy.mil)
Received: from fargo.ait.nrl.navy.mil (fargo [132.250.128.95])
	by ait.nrl.navy.mil (8.8.8/8.8.8) with SMTP id PAA12743
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 15:16:46 -0400 (EDT)
Date: Mon, 6 Apr 1998 15:16:46 -0400 (EDT)
From: Eddy Kuo <ekuo@ait.nrl.navy.mil>
To: info-performer@sgi.com
Subject: Question related to FluxGeoSet
Message-ID: <Pine.SGI.3.91.980406145536.13620A-100000@fargo.ait.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello performer:

I am trying to use fluxed geoset from the fluxed_geoset.C example without
much success.  I have created a flux for a geoset, and then
allocated three arrays (color, coord, and normal) for the geoset.
For each frame
  I call gset = (pfGeoSet*)fluxed_gset->getWritableData(); to
  get my geoset back , and gset->getAttrLists to get back all three
  arrays.  But after pfFrame, there is still nothing show up in the
  window.

thanks for any advice

Ed.
  	


-------------------------------------------------------------------
Eddy Kuo 		      		work phone: 202-767-6025 
Virtual Reality Lab 			home phone: 703-893-2553
Naval Research Lab		http://www.cis.ohio-state.edu/~ekuo
-------------------------------------------------------------------

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 12:24:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA21991 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 12:08:40 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA21964 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 12:08:39 -0700
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105]) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) via ESMTP id MAA19034; Mon, 6 Apr 1998 12:08:38 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA03826; Mon, 6 Apr 1998 12:08:33 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35292831.F1B09969@sgi.com>
Date: Mon, 06 Apr 1998 12:08:33 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Jay Gischer <gischer@puget.engr.sgi.com>
CC: Sam Chu <c00chu00@nchc.gov.tw>, info-performer@puget.engr.sgi.com
Subject: Re: Stats Question correction
References: <199804040656.OAA00737@nchc.gov.tw> <199804061846.LAA18895@puget.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Jay Gischer wrote:
> 
> Sam Chu writes:
>  >
>  >
>  >   I still get some confused. I try 'perfly' in a single channel single pipe
>  > configuration, and got the following result.
>  >   (I run "perfly -m 4 -p 1 esprit.flt" (using APPCULL_DRAW mode))
>  >
>  >   15.0/30.0 HZ LOCK APPCULL_DRAW
>  >   frame = 96.3 app=0.4 cull=1.0 draw=31.2 isect=0.0
>  >
> I believe that you are running on an mp system using at least two
> processors (since you are in APPCULL_DRAW mode, more won't matter).
> 
>  >   I think the reason that app+cull+draw+isect(32.6) in much small than
>  > fram(96.3) is that the process in wait for the Transformation and Fill
>  > stage to finish. So May I say that app+cull+draw is just for the CPU stage?
>  >
> 
> The label "frame" appears to be causing a great deal of confusion
> here.  Recall the picture of Performer's pipe
> 
> APP    | Frame 1  |  Frame 2 |  Frame 3 | Frame 4 | etc
> 
> CULL   |          |  Frame 1 |  Frame 2 | Frame 3 | etc
> 
> DRAW   |          |          |  Frame 1 | Frame 2 | etc
> 
> If 30.0 Hz is the target frame rate then the target from one pipe
> stage boundary to the next is 33.3 ms.
> 
> However, the time reported with the label "frame" is a latency time,
> and measures the time from when the frame starts the APP stage, to
> when it completes the draw stage.  Ignoring special cases, this time
> is 3 times as long as the time for a single stage.  Three time 33.3 is
> 100, so 96.3 is about right.
> 
> The app time of 0.4 means that the APP stage finished very quickly,
> and then hung around for a long time waiting for the next pfSynch(),
> so it could start the CULL stage.  Likewise for the cull time.
> For each of the stages, Performer measures the time from the beginning
> of that stage for the frame to when it completes its work, not to the
> synch boundary, since that wouldn't be a very interesting number
> 
> Here's the picture again with annotations for what time each of
> the stats measures.
> 
> APP    | Frame 1  |  Frame 2 |  Frame 3 | Frame 4 | etc
> app    |<----->A1
> CULL   |          |  Frame 1 |  Frame 2 | Frame 3 | etc
> cull              |<------>C1
> DRAW   |          |          |  Frame 1 | Frame 2 | etc
> draw                         |<---->D1
> frame  |<-------------------------->D1
> 
> A1 = APP stage completes on frame 1
> C1 = APP stage completes on frame 1
> D1 = Draw stage completes on frame 1
> 
> But this begs the question, why, if my draw time is 31.3, and my
> latency is 96.3, am I not getting a frame rate of 30hz?
> 
> As it turns out, in perfly there are two contributions to the DRAW
> stage which are not measured by the perfly stats, pre-draw and
> post-draw.
> 
> In perfly, the GUI is drawn in the pre-draw phase, and statistics are
> drawn in the post-draw phase.  Together, they could easily take up
> enough time (about 2 msecs) to push your application over the 33.3 ms
> mark.  The printed displays do not measure these times, but you can
> glean this information from the graphical display by noticing that the
> line representing the DRAW stage of a frame doesn't start quite at the
> boundary (because of the pre-draw time before it), and is extended by
> a dotted line after it (representing post-draw time).
> 
> The draw time *does* include transformation and fill.
> 
> Okay, so if that explains why we are running at 15hz instead of 30,
> then why isn't the latency equal to about 66.6+66.6+31.3 =  164.5?
> 
> This is because you are running in LOCK mode.  In LOCK mode, the
> picture I gave above gets more complicated (assuming you are missing
> the target rate in the draw stage):
> 
> APP    | F1  |  F2 |  F3 | F4 | F5 | F6 | F7 | F8 | etc
> app    |<-->A1
> CULL   |     |  F1 |  F2 | F3 | F4 | F5 | F6 | F7 | F8 | etc
> cull         |<-->C1
> DRAW   |     |     |  F1 | F1 | F3 | F3 | F5 | F5 | F7 | F7 | etc
> draw               |<------->D1
> frame  |<------------------->D1
> 
> In LOCK mode the APP and CULL stages start each frame at the target
> frame rate, and the DRAW stage merely ignores frames that it wasn't
> ready to draw at the proper time, hence, in your case, it displays
> only every other frame.  But the latency from beginning of pipe to end
> is smaller, on the order of 33.3+33.3+31.2 =  97.8 which is very close
> to the reported latency of 96.3.
> 
>  >   If the above is true, how can I measure the time spent in the
>  > Transformation stage and Fill stage?
>  >
> 
> So, to summarize, the missing time (about 2ms) is due probably to GUI
> and the stats display rendering.  It is not due to fill time, which is
> measured and included in the "draw" time.

Very erudite.

I'll only add that if you need less latency you can read eye positions
from
shared memory directly in the draw process and update the channel
position
and FOV prior to calling pfDraw.

Also if you call pfSync it is possible to make latency critical updates
after the pfSync call but before the pfFrame call which will avoid app
processing latency. The only price you pay is that you lose microseconds
of CULL time.

Basically you only really have to worry about draw time latency if you
do the right thing.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 13:09:22 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA22679 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 12:53:45 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA22652 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 12:53:44 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA8141688
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 12:53:43 -0700 (PDT)
Received: from relay3.smtp.psi.net (relay3.smtp.psi.net [38.8.210.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA22323
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 12:53:41 -0700 (PDT)
	mail_from (bills@FTIORL02.ENZIAN.COM)
Received: from FTIORL02.ENZIAN.COM by relay3.smtp.psi.net (8.8.5/SMI-5.4-PSI)
	id PAA19504; Mon, 6 Apr 1998 15:53:38 -0400 (EDT)
Received: from FTIORL02/SpoolDir by FTIORL02.ENZIAN.COM (Mercury 1.40);
    6 Apr 98 15:56:17 EST
Received: from SpoolDir by FTIORL02 (Mercury 1.40); 6 Apr 98 15:55:47 EST
From: "Bill Storma" <bills@FTIORL02.ENZIAN.COM>
Organization: Future Technologies, Inc.
To: info-performer@sgi.com
Date: Mon, 6 Apr 1998 15:55:43 EST
Subject: Performer POSIX compatibility
Message-ID: <1CB8044B6C@FTIORL02.ENZIAN.COM>
Status: O

IS Performer 2.0.X compatible with IRIX 5.3 POSIX ??  There doesn't 
seem to be any info on this in the SGI web pages, FAQ's or release 
notes.

I am trying to use POSIX signal handlers, instead of the SVR4 signal 
handlers, to get more information about some elusive SIGSEGV and 
SIGUSR1 crash conditions.  However, compiling with _POSIX_SOURCE 
produces numerous errors with Performer.  I am currently using the 
SVR4 signal handlers, but cannot get the detailed info out of them 
that I could with the POSIX signal handlers.  Any help on this 
subject ??

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Bill Storma                     Phone:  407-384-6900
Future Technologies             FAX:    407-381-1010
Orlando, Fl.  32826             e-mail: bills@fti.enzian.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 13:09:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA22708 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 12:54:37 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA22681 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 12:54:36 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) via ESMTP id MAA19100 for <info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 12:54:27 -0700 (PDT)
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA3973371
	for <info-performer@puget.engr.sgi.com>;
	Mon, 6 Apr 1998 12:54:26 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA22590
	for <info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 12:54:25 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id NAA09387 for <info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 13:05:07 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id TAA09392 for <@plateau.engr.multigen.com:info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 19:55:05 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA13503 for info-performer@puget.engr.sgi.com; Mon, 6 Apr 1998 12:55:04 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804061255.ZM13501@logan.engr.multigen.com>
Date: Mon, 6 Apr 1998 12:55:04 -0700
In-Reply-To: Jay Gischer <gischer@puget.engr.sgi.com>
        "Re: Stats Question correction" (Apr  6, 11:46am)
References: <199804040656.OAA00737@nchc.gov.tw> 
	<199804061846.LAA18895@puget.engr.sgi.com>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@puget.engr.sgi.com
Subject: Re: Stats Question correction
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 6, 11:46am, Jay Gischer wrote:
>The label "frame" appears to be causing a great deal of confusion
>here.  Recall the picture of Performer's pipe
>
>APP    | Frame 1  |  Frame 2 |  Frame 3 | Frame 4 | etc
>
>CULL   |          |  Frame 1 |  Frame 2 | Frame 3 | etc
>
>DRAW   |          |          |  Frame 1 | Frame 2 | etc
>
>If 30.0 Hz is the target frame rate then the target from one pipe
>stage boundary to the next is 33.3 ms.
>
>However, the time reported with the label "frame" is a latency time,
>and measures the time from when the frame starts the APP stage, to
>when it completes the draw stage.  Ignoring special cases, this time
>is 3 times as long as the time for a single stage.  Three time 33.3 is
>100, so 96.3 is about right.

I don't believe that this timeline takes the video refresh period into account.
Recall that the draw is double buffered. Therefore you don't actually see the
results of the draw process for another "video frame". This adds to your
latency.

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 13:30:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA22812 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 13:13:33 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA22785 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 13:13:31 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA8422318
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 13:13:32 -0700 (PDT)
Received: from mclapo.apo.saic.com (apo.saic.com [149.8.95.65]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA00120
	for <info-performer@SGI.com>; Mon, 6 Apr 1998 13:13:26 -0700 (PDT)
	mail_from (BLANCHARD@mclapo.apo.saic.com)
From: BLANCHARD@mclapo.apo.saic.com
Date: Mon, 6 Apr 1998 16:13:24 -0400
To: info-performer@SGI.com
Message-Id: <980406161324.a65e@mclapo.apo.saic.com>
Subject: MAX / MAX2 loader for Performer 2.1???
Status: O

Hey pfLoaders!

Does anyone know of a 3ds-max and/or MAX2 loader for Performer 2.1?

Seems that the current 3ds loader for Performer 2.1 neglects to load
all of the object.  Some color, materials, and parts of the meshes
don't load.  Our situation is this: we're doing some of our modelling
in 3ds-max (soon MAX2), exporting our model in 3ds format, and loading
it into perfly.

Any help would be appreciated.  Thanks!

--Paul
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 13:53:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA23057 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 13:42:43 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA23030 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 13:42:42 -0700
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105]) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) via ESMTP id NAA18781 for <info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 13:42:42 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA04229; Mon, 6 Apr 1998 13:42:23 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35293E2F.C762CFF0@sgi.com>
Date: Mon, 06 Apr 1998 13:42:23 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Marcus Barnes <marcus@multigen.com>
CC: info-performer@puget.engr.sgi.com
Subject: Re: Stats Question correction
References: <199804040656.OAA00737@nchc.gov.tw> 
		<199804061846.LAA18895@puget.engr.sgi.com> <9804061255.ZM13501@logan.engr.multigen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Marcus Barnes wrote:
> 
> On Apr 6, 11:46am, Jay Gischer wrote:
> >The label "frame" appears to be causing a great deal of confusion
> >here.  Recall the picture of Performer's pipe
> >
> >APP    | Frame 1  |  Frame 2 |  Frame 3 | Frame 4 | etc
> >
> >CULL   |          |  Frame 1 |  Frame 2 | Frame 3 | etc
> >
> >DRAW   |          |          |  Frame 1 | Frame 2 | etc
> >
> >If 30.0 Hz is the target frame rate then the target from one pipe
> >stage boundary to the next is 33.3 ms.
> >
> >However, the time reported with the label "frame" is a latency time,
> >and measures the time from when the frame starts the APP stage, to
> >when it completes the draw stage.  Ignoring special cases, this time
> >is 3 times as long as the time for a single stage.  Three time 33.3 is
> >100, so 96.3 is about right.
> 
> I don't believe that this timeline takes the video refresh period into account.
> Recall that the draw is double buffered. Therefore you don't actually see the
> results of the draw process for another "video frame". This adds to your
> latency.
> 

This is incorrect. The vertical line is the vertical retrace. When the
draw ends it swaps and the image is switched at the next vertical
retrace,
in the diagram this is the line at the end of draw. Almost immediately
thereafter the video starts getting sent on the wire without any video
buffering and should begin to appear on your screen if you use CRTs.
There are different schools of thought on where latency should be
measured to. Some say the beginning of video, others say the end
but it has little to do with the I.G. You say potato I say potato.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 15:55:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA24140 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 15:33:53 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA24107 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 15:33:51 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA7514703
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 15:33:51 -0700 (PDT)
Received: from archimedes.vislab.navy.mil (archimedes.chinalake.navy.mil [129.131.31.8]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA00748
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 15:33:47 -0700 (PDT)
	mail_from (jan@archimedes.vislab.navy.mil)
Received: (jan@localhost) by archimedes.vislab.navy.mil (8.7.5/8.x-CL-SOS5.3) id PAA20570 for info-performer@sgi.com; Mon, 6 Apr 1998 15:42:29 -0700 (PDT)
From: Jan Barglowski <jan@archimedes.vislab.navy.mil>
Posted-Date: Mon, 6 Apr 1998 15:42:29 -0700 (PDT)
Message-Id: <199804062242.PAA20570@archimedes.vislab.navy.mil>
Subject: Multipipe virtual clipmaps?
To: info-performer@sgi.com
Date: Mon, 6 Apr 1998 15:42:28 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL24 ME8b]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

Performers:

I'm trying to view a virtual clipmap with my 3-pipe Onyx iR using clipfly.  
If I use only one pipe (-M 0) then everything works fine.  But if I
let it use all 3 pipes the cliptexture starts to do, well, funky
things.  The mipmap levels seem to appear at random locations and I
get pfErrors of "Invalid Texture Load".

Looking at the source to clipfly, it appears that it's setup to slave
the cliptexture between pipes as explained in the programmer's manual.
I've perused the clipmap docs, and see nothing that could explain this.

Questions are:

- is clipfly incapable of displaying a virtual clipmap on more than
  one pipe?
- can Performer display a virtual clipmap on more than one pipe?
- does anyone have some source snippets showing how they successfully
  set the pfuAddMPClipTexturesToPipes() in a slave fashion?  Something
  a bit more specific (and less do-everything) than clipfly...

Thanks for any help!

jan

-- 
Jan Anthony Barglowski	              jan@chinalake.navy.mil
Real-time Computer Graphics           http://www1.ridgecrest.ca.us/~jan
Naval Air Warfare Center, China Lake  (760) 927-1057
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 16:27:26 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA24916 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 16:11:17 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA24889 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 16:11:15 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA7338139
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 16:11:15 -0700 (PDT)
Received: from hell.engr.sgi.com ([150.166.37.67]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA19484
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 16:11:13 -0700 (PDT)
	mail_from (hatch@hell.engr.sgi.com)
Received: (from hatch@localhost) by hell.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA12797; Mon, 6 Apr 1998 16:11:12 -0700
Date: Mon, 6 Apr 1998 16:11:12 -0700
From: hatch@hell.engr.sgi.com (Don Hatch)
Message-Id: <9804061611.ZM12795@hell.engr.sgi.com>
In-Reply-To: Jan Barglowski <jan@archimedes.vislab.navy.mil>
        "Re: C++ cliptexures..." (Apr  6, 10:40am)
References: <199804061740.KAA19461@archimedes.vislab.navy.mil>
X-Face: /7QDEc=iPrsQG=j>iQo4F||T'ys-t--1bb9IJ9qo~4|i0nB|OG%gK}I3J2{/u*-q.I8=OSv/&K}V(pw:~5aIV!Y4:y+Vk#AAX)|i'B-jHf+r(?U'"B'9"D|<-(/1PD32tUN
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Jan Barglowski <jan@archimedes.vislab.navy.mil>
Subject: Re: C++ cliptexures...
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 6, 10:40am, Jan Barglowski wrote:
> Subject: Re: C++ cliptexures...
> Jan Barglowski wrote:
> > I've created a virtual cliptexure callback that works when used in
> > conjunction with clipfly.  When I took this function and put it 
> > into perfly, my virtual cliptextures no longer work!  I've printed
> > out the values for VirtualLODOffset, NumEffectiveLevels, and LODRange
> > and they are identical for both programs.
> > 
> > My symptoms are a rapid sharpening/blurring of the virtual cliptexture
> > when zooming in or out towards it.  It doesn't seem to matter what
> > speed I zoom at.  Since the numbers calculated for the above parameters
> > work with clipfly, I'm assuming I'm doing the calculations correctly.
> > And when I comment out the tile-by-tile cliptexture updates, the 
> > cliptexture acts as if it's on Level=0.
> > 
> > I think this is one of two things:
> > 1) Clipfly does something for virtual cliptextures that perfly
> >    doesn't.  And I can't find what this is!  I looked at the README
> >    file for clipfly, and the consideration for viewpoint update
> >    shouldn't cause this (am I right?).  The only thing I can figure
> >    is some of the parameters that control cliptextures are getting
> >    some (important) initialization in clipfly.  Yet I look at 
> >    virtcliptexture.c and don't see a lot of these values getting
> >    set at all.  Any ideas for what I'm missing?
> > 2) the C++ cliptexture functions don't work, but I'd hate to think
> >    this is the case.  Still, anyone do virtual cliptextures with
> >    C++ bindings out there?
> > 
> > Any hints/help/insight will be appreciated!
> 

> Well, I figured this one out.  In my C code is used the pfuSetVirtualParams().
> The C++ man pages do not list an analogous function!

??
I don't think we have any such function...
do you mean pfApplyClipTextureVirtualParams()?
Neither this nor its C++ equivalent is in the man page :-(
Sorry, we blew it and didn't make man page entries for:
	pfClipTexture::applyVirtualParams()
	pfClipTexture::applyClipCenter()
Their purpose and functionality is analogous to those of:
	pfTexture::applyMinLOD()
	pfTexture::applyMaxLOD()
	pfTexture::applyLODBias()
which are described in the pfTexture man page.

You'd use them if you want to change the parameters
multiple times per frame (like the .ct scene loader does).

Make sure you have read the following, which describes
how to use all of these functions and when you'd want to:
	/usr/share/Performer/doc/clipmap/HowToDoVirtual.html
There is a C example in:
	/usr/share/Performer/src/pguide/libpf/C/virtcliptex.c
Also, you already found the .ct loader source (which sets
the values multiple times per frame)-- there is
also the .spherepatch loader (which only sets the values once
per frame, using a simpler interface, if that works for you).

Don

-- 
Don Hatch  hatch@sgi.com  (415) 933-5150  Silicon Graphics, Inc.
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 16:45:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA25168 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 16:33:22 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA25141 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 16:33:21 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA7522916
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 16:33:21 -0700 (PDT)
Received: from hell.engr.sgi.com ([150.166.37.67]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA28311
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 16:33:20 -0700 (PDT)
	mail_from (hatch@hell.engr.sgi.com)
Received: (from hatch@localhost) by hell.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA12970; Mon, 6 Apr 1998 16:33:15 -0700
Date: Mon, 6 Apr 1998 16:33:15 -0700
From: hatch@hell.engr.sgi.com (Don Hatch)
Message-Id: <9804061633.ZM12968@hell.engr.sgi.com>
In-Reply-To: Jan Barglowski <jan@archimedes.vislab.navy.mil>
        "Multipipe virtual clipmaps?" (Apr  6,  3:42pm)
References: <199804062242.PAA20570@archimedes.vislab.navy.mil>
X-Face: /7QDEc=iPrsQG=j>iQo4F||T'ys-t--1bb9IJ9qo~4|i0nB|OG%gK}I3J2{/u*-q.I8=OSv/&K}V(pw:~5aIV!Y4:y+Vk#AAX)|i'B-jHf+r(?U'"B'9"D|<-(/1PD32tUN
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Jan Barglowski <jan@archimedes.vislab.navy.mil>, info-performer@sgi.com
Subject: Re: Multipipe virtual clipmaps?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 6,  3:42pm, Jan Barglowski wrote:
> Subject: Multipipe virtual clipmaps?
> Performers:
> 
> I'm trying to view a virtual clipmap with my 3-pipe Onyx iR using clipfly.  
> If I use only one pipe (-M 0) then everything works fine.  But if I
> let it use all 3 pipes the cliptexture starts to do, well, funky
> things.  The mipmap levels seem to appear at random locations and I
> get pfErrors of "Invalid Texture Load".
> 
> Looking at the source to clipfly, it appears that it's setup to slave
> the cliptexture between pipes as explained in the programmer's manual.
> I've perused the clipmap docs, and see nothing that could explain this.
> 
> Questions are:
> 
> - is clipfly incapable of displaying a virtual clipmap on more than
>   one pipe?
> - can Performer display a virtual clipmap on more than one pipe?

Clipfly should be able to do this.
(Make sure you have the latest IR patches and...)
Try the following on your 3-pipe machine:
	clipfly hl.ct.vct
(the .vct pseudo-loader takes the given scene
and makes all clip texture virtual
by tweaking the initial value of effectiveLevels so that it's smaller
than the total number of levels).
You can tell it's virtual by manually adjusting virtualLODOffset
and numEffectiveLevels with the sliders.
Let me know if that doesn't work.

> - does anyone have some source snippets showing how they successfully
>   set the pfuAddMPClipTexturesToPipes() in a slave fashion?  Something
>   a bit more specific (and less do-everything) than clipfly...

Try these:
    /usr/share/Performer/src/pguide/libpf/C/cliptex.c
    /usr/share/Performer/src/pguide/libpf/C/virtcliptex.c

Don

-- 
Don Hatch  hatch@sgi.com  (415) 933-5150  Silicon Graphics, Inc.
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 16:45:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA25258 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 16:41:48 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA25231 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 16:41:46 -0700
Received: from remi.engr.sgi.com (remi.engr.sgi.com [150.166.37.25]) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) via SMTP id QAA19369 for <info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 16:41:45 -0700 (PDT)
Received: (from remi@localhost) by remi.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA07799; Mon, 6 Apr 1998 16:41:43 -0700
From: remi@remi.engr.sgi.com (Rémi Arnaud)
Message-Id: <199804062341.QAA07799@remi.engr.sgi.com>
Subject: Re: Stats Question correction
To: dorbie@sgi.com (Angus Dorbie)
Date: Mon, 6 Apr 1998 16:41:42 -0700 (PDT)
Cc: marcus@multigen.com, info-performer@puget.engr.sgi.com
In-Reply-To: <35293E2F.C762CFF0@sgi.com> from "Angus Dorbie" at Apr 6, 98 01:42:23 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Status: O

Angus Dorbie wrote:
> 
> Marcus Barnes wrote:
> > 
> > On Apr 6, 11:46am, Jay Gischer wrote:
> > >The label "frame" appears to be causing a great deal of confusion
> > >here.  Recall the picture of Performer's pipe
> > >
> > >APP    | Frame 1  |  Frame 2 |  Frame 3 | Frame 4 | etc
> > >
> > >CULL   |          |  Frame 1 |  Frame 2 | Frame 3 | etc
> > >
> > >DRAW   |          |          |  Frame 1 | Frame 2 | etc
> > >
> > >If 30.0 Hz is the target frame rate then the target from one pipe
> > >stage boundary to the next is 33.3 ms.
> > >
> > >However, the time reported with the label "frame" is a latency time,
> > >and measures the time from when the frame starts the APP stage, to
> > >when it completes the draw stage.  Ignoring special cases, this time
> > >is 3 times as long as the time for a single stage.  Three time 33.3 is
> > >100, so 96.3 is about right.
> > 
> > I don't believe that this timeline takes the video refresh period into account.
> > Recall that the draw is double buffered. Therefore you don't actually see the
> > results of the draw process for another "video frame". This adds to your
> > latency.
> > 
> 
> This is incorrect. The vertical line is the vertical retrace. When the
> draw ends it swaps and the image is switched at the next vertical
> retrace,
> in the diagram this is the line at the end of draw. Almost immediately
> thereafter the video starts getting sent on the wire without any video
> buffering and should begin to appear on your screen if you use CRTs.
> There are different schools of thought on where latency should be
> measured to. Some say the beginning of video, others say the end
> but it has little to do with the I.G. You say potato I say potato.

 It is often added as 1/2 frame of latency. I guess this is from the
 ages where IG and projector were unable to provide non-interlaced
 video.

> 
> Cheers,Angus.
> 
> -- 
> "Only the mediocre are always at their best." -- Jean Giraudoux 
> 
> For advanced 3D graphics Performer + OpenGL based examples and tutors:
> http://www.dorbie.com/
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
> 

    _  /              _             _ 
   |_) _ ._ _ o   /\ |_)|\ | /\ | || \
   | \(/_| | ||  /--\| \| \|/--\|_||_/
                                          
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 17:14:25 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA25439 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 16:59:16 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA25412 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 16:59:09 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) via ESMTP id QAA19411 for <info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 16:59:06 -0700 (PDT)
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA8553791
	for <info-performer@puget.engr.sgi.com>;
	Mon, 6 Apr 1998 16:58:57 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA11558
	for <info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 16:58:53 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id RAA11776 for <info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 17:09:34 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id XAA19075 for <@plateau.engr.multigen.com:info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 23:59:33 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA17526 for info-performer@puget.engr.sgi.com; Mon, 6 Apr 1998 16:59:32 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804061659.ZM17524@logan.engr.multigen.com>
Date: Mon, 6 Apr 1998 16:59:32 -0700
In-Reply-To: Angus Dorbie <dorbie@sgi.com>
        "Re: Stats Question correction" (Apr  6,  1:42pm)
References: <199804040656.OAA00737@nchc.gov.tw> 
	<199804061846.LAA18895@puget.engr.sgi.com> 
	<9804061255.ZM13501@logan.engr.multigen.com> 
	<35293E2F.C762CFF0@sgi.com>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@puget.engr.sgi.com
Subject: Re: Stats Question correction
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 6,  1:42pm, Angus Dorbie wrote:
>Marcus Barnes wrote:
>>
>> I don't believe that this timeline takes the video refresh period into
>> account.
>> Recall that the draw is double buffered. Therefore you don't actually see
the
>> results of the draw process for another "video frame". This adds to your
>> latency.
>
>This is incorrect.

[chuckle]

>The vertical line is the vertical retrace. When the
>draw ends it swaps and the image is switched at the next vertical
>retrace, in the diagram this is the line at the end of draw. Almost
immediately
>thereafter the video starts getting sent on the wire without any video
>buffering and should begin to appear on your screen if you use CRTs.

Raster refresh takes a full video field (interlaced) or frame (noninterlaced).
The scan out is a sequential operation after all. On a 60Hz noninterlaced
monitor (most common these days) that means an additional 16.67 ms. of latency
before the man in the loop sees the update caused by his sitck input.

>There are different schools of thought on where latency should be
>measured to. Some say the beginning of video, others say the end
>but it has little to do with the I.G. You say potato I say potato.

Latency includes the period of time between a control input and the resulting
feedback. In this case, feedback means a visable update of the display. You can
choose to ignore video refesh, and input sampling latency for that matter, when
calculating your end to end latency  ... if it like. Just keep some motion
sickness bags handy ;)

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 19:02:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA26499 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 18:47:22 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA26472 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 18:47:15 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA8650137
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 6 Apr 1998 18:47:15 -0700 (PDT)
Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id SAA22772
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 18:47:05 -0700 (PDT)
	mail_from (dslayton@d-a-s.com)
Received: from d-a-s.com (picard.d-a-s.com [209.122.52.34])
	by smtp3.erols.com (8.8.8/8.8.5) with SMTP id VAA00507
	for <info-performer@sgi.com>; Mon, 6 Apr 1998 21:47:02 -0400 (EDT)
Received: from mulder by d-a-s.com (4.1/SMI-4.1)
	id AA04277; Mon, 6 Apr 98 21:52:54 EDT
Sender: dslayton@d-a-s.com
Message-Id: <3529A1CE.E8A86D3D@d-a-s.com>
Date: Mon, 06 Apr 1998 23:47:27 -0400
From: "David A. Slayton (DAS)" <dslayton@d-a-s.com>
Organization: Dynamic Animation Systems Inc.
X-Mailer: Mozilla 4.04j2 [en] (X11; I; IRIX 6.3 IP32)
Mime-Version: 1.0
To: info-performer@sgi.com
Subject: VR Sand Table Developer Wanted
Content-Type: multipart/alternative; boundary="------------46EE56D7D5732B067EFBE648"
Status: O


--------------46EE56D7D5732B067EFBE648
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dynamic Animation Systems, Inc.

A progressive young virtual reality software company
is searching for qualified candidates to join our hearty
band of visionaries in defining the future of distributed
online virtual environments.

We have immediately available positions for both senior
and mid-level software developers and expert modelers
and animators for supporting the following application areas:

o  Stereoscopic Virtual Reality Sand Table Development.

o  Strong Performer and OpenGL experience.

o  Experience building interfaces to 6DOF tracking systems
    such as those made by Ascension and Polhemous.

o Distributed Interactive Simulation / High Level
  Architecture system software and application design
  and development.

o Advanced imagery applications such as terrain feature
  extraction from remotely sensed imagery.

o An MS/CS or equivalent experience with a proven
    background in software design and development.

o  2+ years C++/C, Java Experience

o  Multigen, MaK, and Paradigm Vega experience a plus.

Please fax your resume and salary requirements to (703)425-2204
or email this information to jobs@d-a-s.com
or snail mail it to:

        Dynamic Animation Systems, Inc.
        ATTN: VR Developer Recruiting
        6035 Burke Centre Parkway
        Suite 200
        Burke VA, 22015


Thanks!


--
#####################################################################
!                                                                   !
!  David A. Slayton                 Dynamic Animation Systems, Inc. !
!  Senior Vice President            6035 Burke Centre Parkway       !
!                                   Suite 200                       !
!                                   Burke, VA 22015                 !
!  mailto:dslayton@d-a-s.com        (703)425-2203                   !
!  http://www.d-a-s.com/            (703)425-2204 (FAX)             !
!                                                                   !
!  "Dedicated to the development of distributed interactive and     !
!  immersive virtual reality applications."                         !
!                                                                   !
#####################################################################



--------------46EE56D7D5732B067EFBE648
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>


<P>Dynamic Animation Systems, Inc.

<P>A progressive young virtual reality software company
<BR>is searching for qualified candidates to join our hearty
<BR>band of visionaries in defining the future of distributed
<BR>online virtual environments.

<P>We have immediately available positions for both senior
<BR>and mid-level software developers and expert modelers
<BR>and animators for supporting the following application areas:

<P>o&nbsp; Stereoscopic Virtual Reality Sand Table Development.

<P>o&nbsp; Strong Performer and OpenGL experience.

<P>o&nbsp; Experience building interfaces to 6DOF tracking systems
<BR>&nbsp;&nbsp;&nbsp; such as those made by Ascension and Polhemous.

<P>o Distributed Interactive Simulation / High Level
<BR>&nbsp; Architecture system software and application design
<BR>&nbsp; and development.

<P>o Advanced imagery applications such as terrain feature
<BR>&nbsp; extraction from remotely sensed imagery.

<P>o An MS/CS or equivalent experience with a proven
<BR>&nbsp;&nbsp;&nbsp; background in software design and development.

<P>o&nbsp; 2+ years C++/C, Java Experience

<P>o&nbsp; Multigen, MaK, and Paradigm Vega experience a plus.

<P>Please fax your resume and salary requirements to (703)425-2204
<BR>or email this information to jobs@d-a-s.com
<BR>or snail mail it to:

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dynamic Animation Systems,
Inc.
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ATTN: VR Developer Recruiting
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6035 Burke Centre Parkway
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suite 200
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Burke VA, 22015
<BR>&nbsp;

<P>Thanks!
<BR>&nbsp;
<PRE>--&nbsp;
#####################################################################
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !
!&nbsp; David A. Slayton&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dynamic Animation Systems, Inc. !
!&nbsp; Senior Vice President&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6035 Burke Centre Parkway&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suite 200&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Burke, VA 22015&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !
!&nbsp; <A HREF="mailto:dslayton@d-a-s.com">mailto:dslayton@d-a-s.com</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (703)425-2203&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !
!&nbsp; <A HREF="http://www.d-a-s.com/">http://www.d-a-s.com/</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (703)425-2204 (FAX)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !
!&nbsp; "Dedicated to the development of distributed interactive and&nbsp;&nbsp;&nbsp;&nbsp; !
!&nbsp; immersive virtual reality applications."&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !
#####################################################################</PRE>
&nbsp;</HTML>

--------------46EE56D7D5732B067EFBE648--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr  6 20:02:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA26753 for info-performer-dist@holodeck.engr.sgi.com; Mon, 6 Apr 1998 19:41:22 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id TAA26726 for <info-performer@holodeck.engr.sgi.com>; Mon, 6 Apr 1998 19:41:21 -0700
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105]) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) via ESMTP id TAA19631 for <info-performer@puget.engr.sgi.com>; Mon, 6 Apr 1998 19:41:20 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA04644; Mon, 6 Apr 1998 19:41:09 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35299244.EC614C69@sgi.com>
Date: Mon, 06 Apr 1998 19:41:08 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Marcus Barnes <marcus@multigen.com>
CC: info-performer@puget.engr.sgi.com
Subject: Re: Stats Question correction
References: <199804040656.OAA00737@nchc.gov.tw> 
		<199804061846.LAA18895@puget.engr.sgi.com> 
		<9804061255.ZM13501@logan.engr.multigen.com> 
		<35293E2F.C762CFF0@sgi.com> <9804061659.ZM17524@logan.engr.multigen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Marcus Barnes wrote:
> 
> On Apr 6,  1:42pm, Angus Dorbie wrote:
> >Marcus Barnes wrote:
> >>
> >> I don't believe that this timeline takes the video refresh period into
> >> account.
> >> Recall that the draw is double buffered. Therefore you don't actually see
> the
> >> results of the draw process for another "video frame". This adds to your
> >> latency.
> >
> >This is incorrect.
> 
> [chuckle]
> 
> >The vertical line is the vertical retrace. When the
> >draw ends it swaps and the image is switched at the next vertical
> >retrace, in the diagram this is the line at the end of draw. Almost
> immediately
> >thereafter the video starts getting sent on the wire without any video
> >buffering and should begin to appear on your screen if you use CRTs.
> 
> Raster refresh takes a full video field (interlaced) or frame (noninterlaced).
> The scan out is a sequential operation after all. On a 60Hz noninterlaced
> monitor (most common these days) that means an additional 16.67 ms. of latency
> before the man in the loop sees the update caused by his sitck input.
> 
> >There are different schools of thought on where latency should be
> >measured to. Some say the beginning of video, others say the end
> >but it has little to do with the I.G. You say potato I say potato.
> 
> Latency includes the period of time between a control input and the resulting
> feedback. In this case, feedback means a visable update of the display. You can
> choose to ignore video refesh, and input sampling latency for that matter, when
> calculating your end to end latency  ... if it like. Just keep some motion
> sickness bags handy ;)

This whole thing boils down to where you compute latency to, the
end of vertical retrace or the beginning. Different RFPs have different
statements about this. The simple fact is that on a CRT you begin to
see the new image almost immediately and a field later all is visible.
You can actually perceive the difference on displays where multiple
channels are vertically abutted unless you reverse the scan direction.
You say tomato I say tomato.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 03:40:02 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA28144 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 03:24:16 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id DAA28117 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 03:24:11 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id DAA8785681
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 03:24:10 -0700 (PDT)
Received: from shallow.division.co.uk (shallow.division.co.uk [194.223.245.89]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id DAA13746
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 03:23:46 -0700 (PDT)
	mail_from (nga@division.co.uk)
Received: from nga.division.co.uk (nga.division.co.uk [194.223.245.87]) by shallow.division.co.uk (8.8.5/8.7) with SMTP id LAA15729 for <info-performer@sgi.com>; Tue, 7 Apr 1998 11:23:42 +0100 (BST)
Received: by nga.division.co.uk with Microsoft Mail
	id <01BD6217.98F33F10@nga.division.co.uk>; Tue, 7 Apr 1998 11:23:32 +0100
Message-ID: <01BD6217.98F33F10@nga.division.co.uk>
From: Andrew Ng <nga@division.co.uk>
To: "'Performer Mailing List'" <info-performer@sgi.com>
Subject: iR Shadows in Stereo
Date: Tue, 7 Apr 1998 11:23:31 +0100
Encoding: 16 TEXT
Status: O

I've run into a problem with pfLightSource shadows on the iR when running 
in quad buffer stereo mode. What appears to be happening is that the 
automatic pass which generates the shadow map is rendering in the same 
buffer for both the left and right buffer channels and as a result leaves a 
red square on the bottom left hand corner of one of the channels.

Does anyone know of a fix or workaround?

Thanks.
------------------------------------------------------------------------  
------
  Andrew Ng (Software Engineer)
  Division Limited, 19 Apex Court,                 Email: 
nga@division.co.uk
  Woodlands, Almondsbury.                          Tel: +44 (0)1454 615554
  Bristol BS32 4JT.                                Fax: +44 (0)1454 615532

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 04:37:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA28393 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 04:16:04 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA28366 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 04:15:58 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA8714716
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 04:15:58 -0700 (PDT)
Received: from kronos (kronos.gup.uni-linz.ac.at [140.78.104.11]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id EAA22133
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 04:15:51 -0700 (PDT)
	mail_from (pachler@marvin.gup.uni-linz.ac.at)
Received: from localhost (pachler@localhost) by kronos (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA05346; Tue, 7 Apr 1998 13:14:32 +0200
Date: Tue, 7 Apr 1998 13:14:32 +0200 (CEST)
From: Uwe Pachler <pachler@marvin.gup.uni-linz.ac.at>
X-Sender: pachler@kronos
Reply-To: Uwe Pachler <pachler@marvin.gup.uni-linz.ac.at>
To: BLANCHARD@mclapo.apo.saic.com
cc: info-performer@sgi.com
Subject: Re: MAX / MAX2 loader for Performer 2.1???
In-Reply-To: <980406161324.a65e@mclapo.apo.saic.com>
Message-ID: <Pine.SGI.3.96.980407114103.5257A-100000@kronos>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


We're facing the same problem. What we're doing currently is that we
export the files as VRML2 and convert them (somehow...) to VRML1 (=
Inventor - .iv). I couldn't find any good converter from VRML2 to VRML1 so
I decided to write one - it will be finished soon. However, exporting
meshes as VRML2 is also not really satisfying because it seems that max
isn't able to export texture coordinates correctly in VRML2. A native max
loader would be the best solution...

Uwe


On Mon, 6 Apr 1998 BLANCHARD@mclapo.apo.saic.com wrote:

> Hey pfLoaders!
> 
> Does anyone know of a 3ds-max and/or MAX2 loader for Performer 2.1?
> 
> Seems that the current 3ds loader for Performer 2.1 neglects to load
> all of the object.  Some color, materials, and parts of the meshes
> don't load.  Our situation is this: we're doing some of our modelling
> in 3ds-max (soon MAX2), exporting our model in 3ds format, and loading
> it into perfly.
> 
> Any help would be appreciated.  Thanks!
> 
> --Paul
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
> 


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 07:43:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA28741 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 07:29:20 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA28714 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 07:29:19 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA8809832
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 07:29:18 -0700 (PDT)
Received: from ptah.cra.com (ptah.opensesame.com [205.181.6.81]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA07266
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 07:29:17 -0700 (PDT)
	mail_from (smulgund@cra.com)
Received: from 205.181.6.126 by ptah.cra.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8)
	id 2N41YN44; Tue, 7 Apr 1998 10:34:15 -0400
X-Sender: smulgund@mail.cra.com
Message-Id: <v03102804b14fe8841008@[205.181.6.126]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 7 Apr 1998 10:29:10 -0400
To: info-performer@sgi.com
From: Sandeep Mulgund <smulgund@cra.com>
Subject: Disabling resizing of pfPipeWindows?
Status: O

Is there any easy way to disable window resizing on a pfPipeWindow? (so
that the small resize control doesn't appear on any of the window's corners)

Thanks,

Sandeep


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 07:41:18 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA28709 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 07:16:42 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA28682 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 07:16:40 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA8832750
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 07:16:39 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA03727
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 07:16:38 -0700 (PDT)
	mail_from (bmannlein@multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id HAA14618; Tue, 7 Apr 1998 07:27:20 -0700
Received: from zulu1.engr.multigen.com (xserv.engr.multigen.com [209.24.52.8]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id OAA27397; Tue, 7 Apr 1998 14:17:19 GMT
Received: by xserv.engr.multigen.com with Internet Mail Service (5.5.1960.3)
	id <2F34MNSS>; Tue, 7 Apr 1998 07:12:06 -0700
Message-ID: <86F098AC14A7D11194DD00A0C9499D040D2DF2@xserv.engr.multigen.com>
From: Brian Mannlein <bmannlein@multigen.com>
To: "'Uwe Pachler'" <pachler@marvin.gup.uni-linz.ac.at>,
        BLANCHARD@mclapo.apo.saic.com
Cc: info-performer@sgi.com
Subject: RE: MAX / MAX2 loader for Performer 2.1???
Date: Tue, 7 Apr 1998 07:11:59 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Status: O

Uwe & Paul,

Not sure if you have access to MultiGen, but MultiGenII and Creator both
have converters from 3DS to OpenFlight which might interest you.  You
can even get from 3DS Max to Flight.  Here is an article written about
the 3DS Max to OpenFlight conversion:

http://www.multigen.com/news/newsletter/vol4_3/nov10.htm

Regards,
Brian Mannlein

> -----Original Message-----
> From:	Uwe Pachler [SMTP:pachler@marvin.gup.uni-linz.ac.at]
> Sent:	Tuesday, April 07, 1998 4:15 AM
> To:	BLANCHARD@mclapo.apo.saic.com
> Cc:	info-performer@sgi.com
> Subject:	Re: MAX / MAX2 loader for Performer 2.1???
> 
> 
> We're facing the same problem. What we're doing currently is that we
> export the files as VRML2 and convert them (somehow...) to VRML1 (=
> Inventor - .iv). I couldn't find any good converter from VRML2 to
> VRML1 so
> I decided to write one - it will be finished soon. However, exporting
> meshes as VRML2 is also not really satisfying because it seems that
> max
> isn't able to export texture coordinates correctly in VRML2. A native
> max
> loader would be the best solution...
> 
> Uwe
> 
> 
> On Mon, 6 Apr 1998 BLANCHARD@mclapo.apo.saic.com wrote:
> 
> > Hey pfLoaders!
> > 
> > Does anyone know of a 3ds-max and/or MAX2 loader for Performer 2.1?
> > 
> > Seems that the current 3ds loader for Performer 2.1 neglects to load
> > all of the object.  Some color, materials, and parts of the meshes
> > don't load.  Our situation is this: we're doing some of our
> modelling
> > in 3ds-max (soon MAX2), exporting our model in 3ds format, and
> loading
> > it into perfly.
> > 
> > Any help would be appreciated.  Thanks!
> > 
> > --Paul
> >
> ======================================================================
> =
> > List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
> >             Submissions:  info-performer@sgi.com
> >         Admin. requests:  info-performer-request@sgi.com
> > 
> 
> 
> ======================================================================
> =
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 08:01:43 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA28784 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 07:43:59 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA28757 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 07:43:58 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA7309644
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 07:43:57 -0700 (PDT)
Received: from camus.paradigmsim.com (camus.paradigmsim.com [206.7.114.160]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA11849
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 07:43:55 -0700 (PDT)
	mail_from (rweyrauch@paradigmsim.com)
Received: from paradigmsim.com (camus.paradigmsim.com [206.7.114.160]) by camus.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA21446; Tue, 7 Apr 1998 09:39:08 -0500
Sender: rweyrauch@paradigmsim.com
Message-ID: <352A3A8B.E2CB58E8@paradigmsim.com>
Date: Tue, 07 Apr 1998 09:39:07 -0500
From: Rick Weyrauch <rweyrauch@paradigmsim.com>
Reply-To: rweyrauch@paradigmsim.com
Organization: Paradigm Simulation Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: TexLoad stats
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

I would like to monitor the status of texture loads initiated by
clip-textures using Performer stats.

prstats.h defines a pfStatsValTexLoads structure but does not define a
PFSTATSVAL_TEXLOAD token to enable the query using pfQueryFStats.

Are the PFSTATSVAL_TEXLOAD_* tokens missing from the prstats.h file or
is this functionality not exposed?


Thanks,

Rick

-- 

Rick Weyrauch				voice: (972) 960-2301
Paradigm Simulation Inc.		fax:   (972) 960-2303
14900 Landmark Blvd., Suite 400		rweyrauch@paradigmsim.com
Dallas TX 75240				www.paradigmsim.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 09:24:09 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA29166 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 09:05:25 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA29139 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 09:05:20 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA8766018
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 09:05:19 -0700 (PDT)
Received: from aleve.media.mit.edu (aleve.media.mit.edu [18.85.2.171]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA13197
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 09:05:17 -0700 (PDT)
	mail_from (kbrussel@media.mit.edu)
Received: from komodo-dragon.media.mit.edu (komodo-dragon.media.mit.edu [18.85.23.10])
	by aleve.media.mit.edu (8.8.7/ML970927) with ESMTP id MAA22552;
	Tue, 7 Apr 1998 12:05:17 -0400 (EDT)
Received: (from kbrussel@localhost) by komodo-dragon.media.mit.edu (950413.SGI.8.6.12/8.6.11) id QAA19873; Tue, 7 Apr 1998 16:05:16 GMT
Date: Tue, 7 Apr 1998 16:05:16 GMT
Message-Id: <199804071605.QAA19873@komodo-dragon.media.mit.edu>
From: Kenneth B Russell <kbrussel@media.mit.edu>
To: Performer Enthusiasts <info-performer@sgi.com>
Subject: Shadowed lights
Reply-to: kbrussel@media.mit.edu
Status: O


Hello,

We'd love to use shadowed lights in our Performer 2.2
application. However, just trying out the "shadows" example in
/usr/share/Performer/src/pguide/libpf/C/shadows.c verbatim, we
run into two problems:
  1. Moire effects at polygon edges
  2. Glitches in the shadow itself (only seems to happen with
     certain pieces of geometry)
I thought the first of these effects might be the "self
shadowing" problem mentioned in the man pages; however, playing
with the PFLS_SHADOW_DISPLACE_SCALE and
PFLS_SHADOW_DISPLACE_OFFSET parameters results in something that
looks wrong (the part of the shadow which should appear on the
geometry seems to "slide off"), and the moire is still visible.

I've illustrated these problems in the following images:
http://www.media.mit.edu/~kbrussel/shadow0.jpg
http://www.media.mit.edu/~kbrussel/shadow1.jpg
http://www.media.mit.edu/~kbrussel/shadow2.jpg

Could someone who is using shadowed lights please take a quick
look and tell me whether or not this is normal behavior?

This is on an Onyx2 with iR graphics, but not the latest patch
set; the latest graphics patch we have is 2326. It doesn't look
like graphics rollup #4 addressed this, though.

Thanks very much,

-Ken


__________________________________________________________________________
Kenneth B. Russell               Synthetic Characters Group, MIT Media Lab
kbrussel@media.mit.edu                  http://www.media.mit.edu/~kbrussel
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 10:11:02 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA29313 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 09:50:48 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA29286 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 09:50:46 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA8902795
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 09:50:46 -0700 (PDT)
Received: from archimedes.vislab.navy.mil (archimedes.chinalake.navy.mil [129.131.31.8]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA05043
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 09:50:44 -0700 (PDT)
	mail_from (jan@archimedes.vislab.navy.mil)
Received: (jan@localhost) by archimedes.vislab.navy.mil (8.7.5/8.x-CL-SOS5.3) id JAA24463; Tue, 7 Apr 1998 09:59:26 -0700 (PDT)
From: Jan Barglowski <jan@archimedes.vislab.navy.mil>
Posted-Date: Tue, 7 Apr 1998 09:59:26 -0700 (PDT)
Message-Id: <199804071659.JAA24463@archimedes.vislab.navy.mil>
Subject: Re: Multipipe virtual clipmaps?
To: jan@archimedes.vislab.navy.mil (Jan Barglowski)
Date: Tue, 7 Apr 1998 09:59:26 -0700 (PDT)
Cc: info-performer@sgi.com
In-Reply-To: <199804062242.PAA20570@archimedes.vislab.navy.mil> from "Jan Barglowski" at Apr 6, 98 03:42:28 pm
X-Mailer: ELM [version 2.4 PL24 ME8b]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

Jan Barglowski wrote:
> 
> Performers:
> 
> I'm trying to view a virtual clipmap with my 3-pipe Onyx iR using clipfly.  
> If I use only one pipe (-M 0) then everything works fine.  But if I
> let it use all 3 pipes the cliptexture starts to do, well, funky
> things.  The mipmap levels seem to appear at random locations and I
> get pfErrors of "Invalid Texture Load".
> 
> Looking at the source to clipfly, it appears that it's setup to slave
> the cliptexture between pipes as explained in the programmer's manual.
> I've perused the clipmap docs, and see nothing that could explain this.
> 
> Questions are:
> 
> - is clipfly incapable of displaying a virtual clipmap on more than
>   one pipe?
> - can Performer display a virtual clipmap on more than one pipe?
> - does anyone have some source snippets showing how they successfully
>   set the pfuAddMPClipTexturesToPipes() in a slave fashion?  Something
>   a bit more specific (and less do-everything) than clipfly...
> 
> Thanks for any help!

OK, I solved this one by reading the error messages more carefully...

Seems Performer calculated that with my cliptexture (888, virtual, 
clipsize 1024) I would run out of texture memory.  So it downsized
the clipsize to 512.  Unfortunately, Performer then started to ask
for tiles with really odd sizes (832x512, for example) which didn't
exist!  This caused my texture weirdness.

The fix was to edit the .ct file and set the clipsize to 512 to
begin with.  Everything worked fine.  I've since converted the 
cliptexture to 5551 and tested with clipsize 1024 and it works
fine, too.

Whew!

jan

-- 
Jan Anthony Barglowski	              jan@chinalake.navy.mil
Real-time Computer Graphics           http://www1.ridgecrest.ca.us/~jan
Naval Air Warfare Center, China Lake  (760) 927-1057
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 10:20:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA29380 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 10:09:25 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA29353 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 10:09:24 -0700
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id KAA20569; Tue, 7 Apr 1998 10:09:23 -0700 (PDT)
Date: Tue, 7 Apr 1998 10:09:23 -0700 (PDT)
Message-Id: <199804071709.KAA20569@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: info-performer@puget.engr.sgi.com
Subject: Re: Stats Question correction
In-Reply-To: <9804061311.ZM7807@rose.engr.sgi.com>
References: <199804040656.OAA00737@nchc.gov.tw>
	<199804061846.LAA18895@puget.engr.sgi.com>
	<gischer@puget>
	<9804061311.ZM7807@rose.engr.sgi.com>
Status: O


As they say, learning is a lifetime process.  Earlier I said:

->As it turns out, in perfly there are two contributions to the DRAW
->stage which are not measured by the perfly stats, pre-draw and
->post-draw. 
 
I've since found out that this is not completely accurate. Pre-draw
time is measured and is represented by a dark line before the normal
line. Post-draw time is measured and is represented by a dark line
after the normal line.  

The GUI redraw is done in a separate channel,
rather than in pre-draw, but the effect is the same... it appears as
the gap between the frame-synch vertical bar and the beginning of the
normal line.  

The dotted line represents the time taken to draw stats. 

One other contribution to draw time is system overhead.  If you aren't
running as root with the DRAW process locked down to a processor, you
could easily be spending 1-2 ms in the OS handling interrupts, I/O,
and who knows what...

------------------------------------------------------------------------
Jay L Gischer        +  "I see great things in baseball.  It's our game.
Advanced Graphics    +  It will repair our losses and be a blessing to
Software             +  us."
Silicon Graphics     +    -Walt Whitman
(415) 390-4277       +    
gischer@sgi.com      +  "A life has no meaning except in the impact it
                     +  has on other lives"
                     +    -Jackie Robinson

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 11:02:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA29555 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 10:37:49 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA29527 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 10:37:48 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA8325101
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 10:37:47 -0700 (PDT)
Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA26888
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 10:37:42 -0700 (PDT)
	mail_from (Donna.Allen@PHL.Boeing.com)
Received: from xch-phlbh-01.he.boeing.com ([128.225.22.200])
	by mailgate2.boeing.com (8.8.5/8.8.5) with ESMTP id KAA07345
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 10:37:37 -0700 (PDT)
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.0.1458.49)
	id <H0QHQ3S6>; Tue, 7 Apr 1998 13:37:49 -0400
Message-ID: <51CC653FD8E0D011B82900805FFE090CF92AF7@xch-phl-03.he.boeing.com>
From: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>
To: "'SGI Performer Users Group'" <info-performer@sgi.com>
Cc: "Reynolds, Berton" <Berton.Reynolds@PHL.Boeing.com>
Subject: Too Big?
Date: Tue, 7 Apr 1998 13:37:39 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Status: O

hi,

I'm trying to load a 152MB Open Flight database with about 150 KB of
texture into perfly on an Indigo 2 Extreme with 250 MH processor and 256
MB Ram.  I crashes with a memory allocation error.  I would think 256MB
ram would be enough for this.  Is this too big?

Also, I heard that you can convert to Performer binaries, but have no
idea how to do this.  Could someone help?

Thanks in advance,

Donna
Donna Allen
Boeing Philadelphia                                 phone:    voice:
610-591-7963
Flight Simulation Lab                               fax:   610-591-5636
donna.n.allen@boeing.com                            lab:   610-591-7971
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 11:31:43 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA29730 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 11:16:48 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA29703 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 11:16:47 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA7080298
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 11:16:47 -0700 (PDT)
Received: from quid.engr.sgi.com ([130.62.52.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA13966
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 11:16:45 -0700 (PDT)
	mail_from (robj@quid.engr.sgi.com)
Received: (from robj@localhost) by quid.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA21779; Tue, 7 Apr 1998 11:16:44 -0700
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9804071116.ZM21777@quid.engr.sgi.com>
Date: Tue, 7 Apr 1998 11:16:43 -0700
In-Reply-To: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>
        "Too Big?" (Apr  7,  1:37pm)
References: <51CC653FD8E0D011B82900805FFE090CF92AF7@xch-phl-03.he.boeing.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>,
        "'SGI Performer Users Group'" <info-performer@sgi.com>
Subject: Re: Too Big?
Cc: "Reynolds, Berton" <Berton.Reynolds@PHL.Boeing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 7,  1:37pm, Allen, Donna N wrote:
> Subject: Too Big?
> hi,
>
> I'm trying to load a 152MB Open Flight database with about 150 KB of
> texture into perfly on an Indigo 2 Extreme with 250 MH processor and 256
> MB Ram.  I crashes with a memory allocation error.  I would think 256MB
> ram would be enough for this.  Is this too big?
>

You need to account for other stuff running at the same time, look at the
output of 'top' or gmemusage to see how much memory is in use. You could get it
running by adding swap space, see man swap but if you're swapping then it could
be slow.

> Also, I heard that you can convert to Performer binaries, but have no
> idea how to do this.  Could someone help?
>

There's a utility called pfconv to convert from any format performer can read
into pfa ( ascii ) or pfb ( binary and fast loading ). pfconv has a man page
for more info.

Cheers
Rob

> Thanks in advance,
>
> Donna
> Donna Allen
> Boeing Philadelphia                                 phone:    voice:
> 610-591-7963
> Flight Simulation Lab                               fax:   610-591-5636
> donna.n.allen@boeing.com                            lab:   610-591-7971
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from Allen, Donna N



-- 
________________________________________________________________
Rob Jenkins mailto:robj@sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 11:55:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA29860 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 11:37:51 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA29833 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 11:37:51 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA8913229
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 11:37:50 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA22881
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 11:37:49 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA8867399;
	Tue, 7 Apr 1998 11:37:48 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA05507; Tue, 7 Apr 1998 11:37:47 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <352A727B.ECBF944F@sgi.com>
Date: Tue, 07 Apr 1998 11:37:47 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: kbrussel@media.mit.edu
CC: Performer Enthusiasts <info-performer@sgi.com>
Subject: Re: Shadowed lights
References: <199804071605.QAA19873@komodo-dragon.media.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Kenneth B Russell wrote:
> 
> Hello,
> 
> We'd love to use shadowed lights in our Performer 2.2
> application. However, just trying out the "shadows" example in
> /usr/share/Performer/src/pguide/libpf/C/shadows.c verbatim, we
> run into two problems:
>   1. Moire effects at polygon edges

This is a percentage closef filtering artifact because the
reconstruction filter is after the depth test, by definition
there is no depth reconstruction between samples in s&t before
the depth (otherwise edges & soft shadows would be broken), the
price you pay is that when you _want_ sample reconstruction ie
on a steeply sloping polygon in z you don't get it, there are
three things you can do:

1) increase the resolution of the shadow map.
2) Your problem is a lighting problem in theory the 'moire' effect
   is only bad as your diffuse term L.N approaches 0 so this should hide
   artifact if you have the lighting correct.
3) You can offset the depth buffer values in the shadow map be
   adjusting r texture coordinate w.r.t the depth buffer info
   since this is essentially a shadow map z fighting issue this
   is similar to polygon offset in more conventional circumstances.

>   2. Glitches in the shadow itself (only seems to happen with
>      certain pieces of geometry)

This might be ralated to LOD switching, consistent LOD is important.

> I thought the first of these effects might be the "self
> shadowing" problem mentioned in the man pages; however, playing
> with the PFLS_SHADOW_DISPLACE_SCALE and
> PFLS_SHADOW_DISPLACE_OFFSET parameters results in something that
> looks wrong (the part of the shadow which should appear on the
> geometry seems to "slide off"), and the moire is still visible.
> 
> I've illustrated these problems in the following images:
> http://www.media.mit.edu/~kbrussel/shadow0.jpg
> http://www.media.mit.edu/~kbrussel/shadow1.jpg
> http://www.media.mit.edu/~kbrussel/shadow2.jpg
> 
> Could someone who is using shadowed lights please take a quick
> look and tell me whether or not this is normal behavior?
> 
> This is on an Onyx2 with iR graphics, but not the latest patch
> set; the latest graphics patch we have is 2326. It doesn't look
> like graphics rollup #4 addressed this, though.
> 
> Thanks very much,
> 
> -Ken
> 
> __________________________________________________________________________
> Kenneth B. Russell               Synthetic Characters Group, MIT Media Lab
> kbrussel@media.mit.edu                  http://www.media.mit.edu/~kbrussel
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 12:44:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA00302 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 12:30:53 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA00275 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 12:30:52 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA8931039
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 12:30:51 -0700 (PDT)
Received: from rose.engr.sgi.com ([150.166.37.6]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA13782
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 12:30:50 -0700 (PDT)
	mail_from (src@rose.engr.sgi.com)
Received: (from src@localhost) by rose.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA11069; Tue, 7 Apr 1998 12:30:49 -0700
Date: Tue, 7 Apr 1998 12:30:49 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9804071230.ZM11067@rose.engr.sgi.com>
In-Reply-To: Jay Gischer <gischer@puget>
        "Re: Stats Question correction" (Apr  7, 10:09am)
References: <199804040656.OAA00737@nchc.gov.tw> 
	<199804061846.LAA18895@puget.engr.sgi.com>  <gischer@puget> 
	<9804061311.ZM7807@rose.engr.sgi.com> 
	<199804071709.KAA20569@puget.engr.sgi.com>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Jay Gischer <gischer@puget.engr.sgi.com>,
        info-performer@puget.engr.sgi.com
Subject: Re: Stats Question correction
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

+>---- On Apr 7, 10:09am, Jay Gischer wrote:
> Subject: Re: Stats Question correction
->In-Reply-To: <9804061311.ZM7807@rose.engr.sgi.com>
->
->As they say, learning is a lifetime process.  Earlier I said:

And part of that is obviously being well aware of clearly how complicated
the stats have gotten which is unfortunate since that degrades their
usefulness. I think some folks have some better stats tools in 
progress and we are looking at how to better enable these (including of
coures fixing bugs) and how to make some of these trade-offs better
in the future and more self-explanatory tools we should provide.

->
->->As it turns out, in perfly there are two contributions to the DRAW
->->stage which are not measured by the perfly stats, pre-draw and
->->post-draw. 
-> 
->I've since found out that this is not completely accurate. Pre-draw
->time is measured and is represented by a dark line before the normal
->line. Post-draw time is measured and is represented by a dark line
->after the normal line.  
->
->The GUI redraw is done in a separate channel,
->rather than in pre-draw, but the effect is the same... it appears as
->the gap between the frame-synch vertical bar and the beginning of the
->normal line.  
->
->The dotted line represents the time taken to draw stats. 

That is the main thing it includes in the simple case but I'll attempt to match Jay's 
standards for perfection and detail.
Basically, the dotted line is everything after the end of the draw of the given channel
until swapbuffers is called for that pfPipe.
1) Early Performers (1.0) will remember that the dotted line went to the vertical
    retrace boundary.  We stopped that since you can figure out when the
    swap happened yourself and instead stop the line at when we call 
    swapbuffers for that pfPipe.
2) Multiple channels just aren't handled as gracefully as they probably could.
    For channels before current one, you get a big space.
    Channels after the current one on the current pipe are thrown into
    the dotted line as well.
    It is just a lot of extra overhead for one channel to know about the
    others (even that there were other active channels) so basically this 
    just wasn't handled.
	
Phew!  On a positive note, I think the man page (in pfChannel (obviously :-)) and 
pguide notes for this graph in Performer2.2 are pretty good and if you sit with
both up in front of you at once you should come up with the above and more...
Just wait till you start cliptexturing and using calligraphic lights!  
We found just a bit more space in that graph...


->One other contribution to draw time is system overhead.  If you aren't
->running as root with the DRAW process locked down to a processor, you
->could easily be spending 1-2 ms in the OS handling interrupts, I/O,
->and who knows what...

The X clock running on the background :-))


src.

-- 
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src@sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 12:44:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA00273 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 12:30:51 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA00245 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 12:30:51 -0700
Received: from rose.engr.sgi.com (rose.engr.sgi.com [150.166.37.6]) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) via SMTP id MAA20828; Tue, 7 Apr 1998 12:30:50 -0700 (PDT)
Received: (from src@localhost) by rose.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA11069; Tue, 7 Apr 1998 12:30:49 -0700
Date: Tue, 7 Apr 1998 12:30:49 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9804071230.ZM11067@rose.engr.sgi.com>
In-Reply-To: Jay Gischer <gischer@puget>
        "Re: Stats Question correction" (Apr  7, 10:09am)
References: <199804040656.OAA00737@nchc.gov.tw> 
	<199804061846.LAA18895@puget.engr.sgi.com>  <gischer@puget> 
	<9804061311.ZM7807@rose.engr.sgi.com> 
	<199804071709.KAA20569@puget.engr.sgi.com>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Jay Gischer <gischer@puget.engr.sgi.com>,
        info-performer@puget.engr.sgi.com
Subject: Re: Stats Question correction
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

+>---- On Apr 7, 10:09am, Jay Gischer wrote:
> Subject: Re: Stats Question correction
->In-Reply-To: <9804061311.ZM7807@rose.engr.sgi.com>
->
->As they say, learning is a lifetime process.  Earlier I said:

And part of that is obviously being well aware of clearly how complicated
the stats have gotten which is unfortunate since that degrades their
usefulness. I think some folks have some better stats tools in 
progress and we are looking at how to better enable these (including of
coures fixing bugs) and how to make some of these trade-offs better
in the future and more self-explanatory tools we should provide.

->
->->As it turns out, in perfly there are two contributions to the DRAW
->->stage which are not measured by the perfly stats, pre-draw and
->->post-draw. 
-> 
->I've since found out that this is not completely accurate. Pre-draw
->time is measured and is represented by a dark line before the normal
->line. Post-draw time is measured and is represented by a dark line
->after the normal line.  
->
->The GUI redraw is done in a separate channel,
->rather than in pre-draw, but the effect is the same... it appears as
->the gap between the frame-synch vertical bar and the beginning of the
->normal line.  
->
->The dotted line represents the time taken to draw stats. 

That is the main thing it includes in the simple case but I'll attempt to match Jay's 
standards for perfection and detail.
Basically, the dotted line is everything after the end of the draw of the given channel
until swapbuffers is called for that pfPipe.
1) Early Performers (1.0) will remember that the dotted line went to the vertical
    retrace boundary.  We stopped that since you can figure out when the
    swap happened yourself and instead stop the line at when we call 
    swapbuffers for that pfPipe.
2) Multiple channels just aren't handled as gracefully as they probably could.
    For channels before current one, you get a big space.
    Channels after the current one on the current pipe are thrown into
    the dotted line as well.
    It is just a lot of extra overhead for one channel to know about the
    others (even that there were other active channels) so basically this 
    just wasn't handled.
	
Phew!  On a positive note, I think the man page (in pfChannel (obviously :-)) and 
pguide notes for this graph in Performer2.2 are pretty good and if you sit with
both up in front of you at once you should come up with the above and more...
Just wait till you start cliptexturing and using calligraphic lights!  
We found just a bit more space in that graph...


->One other contribution to draw time is system overhead.  If you aren't
->running as root with the DRAW process locked down to a processor, you
->could easily be spending 1-2 ms in the OS handling interrupts, I/O,
->and who knows what...

The X clock running on the background :-))


src.

-- 
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src@sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 14:00:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA00613 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 13:41:59 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA00586 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 13:41:57 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA8975854
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 13:41:53 -0700 (PDT)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id NAA11129
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 13:41:51 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id PAA00720; Tue, 7 Apr 1998 15:41:32 -0500 (CDT)
Date: Tue, 7 Apr 1998 15:42:20 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>
cc: "'SGI Performer Users Group'" <info-performer@sgi.com>,
        "Reynolds, Berton" <Berton.Reynolds@PHL.Boeing.com>
Subject: Re: Too Big?
In-Reply-To: <51CC653FD8E0D011B82900805FFE090CF92AF7@xch-phl-03.he.boeing.com>
Message-ID: <Pine.SGI.3.96.980407154042.27806D-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Tue, 7 Apr 1998, Allen, Donna N wrote:

> hi,
> 
> I'm trying to load a 152MB Open Flight database with about 150 KB of
> texture into perfly on an Indigo 2 Extreme with 250 MH processor and 256
> MB Ram.  I crashes with a memory allocation error.  I would think 256MB
> ram would be enough for this.  Is this too big?
 
Sounds like it. You are assuming that the size of a '.flt' file on disk
is somehow a 1:1 correspondance with the amount of memory that a similar
Performer data structure will consume in main memory. This is very far
from the truth (although I confess that I don't know what the actual
ratio is likely to be).



Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 14:38:53 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA00901 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 14:15:12 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA00874 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 14:15:11 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA8960673
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 14:15:11 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA28474
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 14:15:10 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA8994191;
	Tue, 7 Apr 1998 14:15:09 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA05733; Tue, 7 Apr 1998 14:15:08 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <352A975C.186AE2A8@sgi.com>
Date: Tue, 07 Apr 1998 14:15:08 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Steve Baker <sbaker@link.com>
CC: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>,
        "'SGI Performer Users Group'" <info-performer@sgi.com>,
        "Reynolds, Berton" <Berton.Reynolds@PHL.Boeing.com>
Subject: Re: Too Big?
References: <Pine.SGI.3.96.980407154042.27806D-100000@lechter.bgm.link.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Steve Baker wrote:
> 
> On Tue, 7 Apr 1998, Allen, Donna N wrote:
> 
> > hi,
> >
> > I'm trying to load a 152MB Open Flight database with about 150 KB of
> > texture into perfly on an Indigo 2 Extreme with 250 MH processor and 256
> > MB Ram.  I crashes with a memory allocation error.  I would think 256MB
> > ram would be enough for this.  Is this too big?
> 
> Sounds like it. You are assuming that the size of a '.flt' file on disk
> is somehow a 1:1 correspondance with the amount of memory that a similar
> Performer data structure will consume in main memory. This is very far
> from the truth (although I confess that I don't know what the actual
> ratio is likely to be).

A flt file should take up much less memory than disk space in Performer.

However textures are not embeded in the OpenFlight file format and you'd
have to add those to memory useage so what I just said is probably
untrue
for many textured databases. And during the loading phase a texture
will exist in main memory, in  OpenGL, plus MIP maps. Ultimately
you won't have a host copy but you still have a copy in system memory
in the GL even if it's currently downloaded to texture memory.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 15:11:52 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA01266 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 14:57:23 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA01239 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 14:57:22 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA8587235
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 14:57:21 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id OAA24115
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 14:57:20 -0700 (PDT)
	mail_from (awalker@multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id PAA19666; Tue, 7 Apr 1998 15:08:03 -0700
Received: from zulu1.engr.multigen.com (xserv.engr.multigen.com [209.24.52.8]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id VAA13430; Tue, 7 Apr 1998 21:58:02 GMT
Received: by xserv.engr.multigen.com with Internet Mail Service (5.5.1960.3)
	id <2F34M3S4>; Tue, 7 Apr 1998 14:52:49 -0700
Message-ID: <86F098AC14A7D11194DD00A0C9499D040219EC@xserv.engr.multigen.com>
From: Andy Walker <awalker@multigen.com>
To: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>,
        "'SGI Performer Users Group'" <info-performer@sgi.com>
Subject: RE: Too Big?
Date: Tue, 7 Apr 1998 14:52:41 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Status: O

Hello Donna

I am not sure how Performer deals with the OpenFlight construct of
external references and instances.  My experience in the past was that
externals and instances are turned into unique elements in memory not
just pointers to one piece of memory.  So in this case a flight file
with a lot of externals and instances could grow much larger.  

Does your database use external references and instances extensively?

Andy Walker

> -----Original Message-----
> From:	Angus Dorbie [SMTP:dorbie@sgi.com]
> Sent:	Tuesday, April 07, 1998 2:15 PM
> To:	Steve Baker
> Cc:	Allen, Donna N; 'SGI Performer Users Group'; Reynolds, Berton
> Subject:	Re: Too Big?
> 
> Steve Baker wrote:
> > 
> > On Tue, 7 Apr 1998, Allen, Donna N wrote:
> > 
> > > hi,
> > >
> > > I'm trying to load a 152MB Open Flight database with about 150 KB
> of
> > > texture into perfly on an Indigo 2 Extreme with 250 MH processor
> and 256
> > > MB Ram.  I crashes with a memory allocation error.  I would think
> 256MB
> > > ram would be enough for this.  Is this too big?
> > 
> > Sounds like it. You are assuming that the size of a '.flt' file on
> disk
> > is somehow a 1:1 correspondance with the amount of memory that a
> similar
> > Performer data structure will consume in main memory. This is very
> far
> > from the truth (although I confess that I don't know what the actual
> > ratio is likely to be).
> 
> A flt file should take up much less memory than disk space in
> Performer.
> 
> However textures are not embeded in the OpenFlight file format and
> you'd
> have to add those to memory useage so what I just said is probably
> untrue
> for many textured databases. And during the loading phase a texture
> will exist in main memory, in  OpenGL, plus MIP maps. Ultimately
> you won't have a host copy but you still have a copy in system memory
> in the GL even if it's currently downloaded to texture memory.
> 
> Cheers,Angus.
> 
> -- 
> "Only the mediocre are always at their best." -- Jean Giraudoux 
> 
> For advanced 3D graphics Performer + OpenGL based examples and tutors:
> http://www.dorbie.com/
> ======================================================================
> =
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr  7 17:28:23 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA02390 for info-performer-dist@holodeck.engr.sgi.com; Tue, 7 Apr 1998 17:07:51 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA02363 for <info-performer@holodeck.engr.sgi.com>; Tue, 7 Apr 1998 17:07:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA9060119
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 7 Apr 1998 17:07:48 -0700 (PDT)
Received: from aud.ucla.edu (alberti.aud.ucla.edu [128.97.173.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id RAA18461
	for <info-performer@sgi.com>; Tue, 7 Apr 1998 17:07:47 -0700 (PDT)
	mail_from (friedman@ucla.edu)
Received: from ucla.edu by aud.ucla.edu (SMI-8.6/SMI-SVR4)
	id RAA10847; Tue, 7 Apr 1998 17:08:40 -0700
Sender: scott@ucla.edu
Message-ID: <352ABF98.B4F79743@ucla.edu>
Date: Tue, 07 Apr 1998 17:06:49 -0700
From: "Scott A. Friedman" <friedman@ucla.edu>
X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX64 6.2 IP28)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Problem with pfSwitch
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi,

Moving to the released version of Performer 2.2...

Switch values do not change in the cull process when running under
APP_CULL_DRAW.   APP and DRAW report the correct value using getVal().
When running under APPCULLDRAW or APPCULL_DRAW there is no problem -
which I suppose is to be expected since APP and CULL are using the same
copy of the node on both cases.  I have tried this under irix 6.2,6.3
and 6.4 / N32 and O32  -  all do the same thing - switch value not
updated in CULL.

The switch was allocated from the APP process if that matters.

Interestingly, when I call setVal with a constant (e.g. 2) and not a
variable it works - go figure.

BTW - this was working with earlier beta versions of Performer 2.2.

Suggestions as to what may be wrong are appreciated.  I am a little
confused since this same code has worked for several years now without a
problem.

Thanks,
Scott


Scott Friedman
UCLA



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 06:02:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA03762 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 05:50:02 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA03735 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 05:50:00 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA9248124
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 05:50:00 -0700 (PDT)
Received: from csnet.cs.technion.ac.il (csnet.cs.technion.ac.il [132.68.32.7]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id FAA24777
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 05:49:56 -0700 (PDT)
	mail_from (anda@CS.Technion.AC.IL)
Received: from CS.Technion.AC.IL (csa [132.68.32.1]) by csnet.cs.technion.ac.il (8.6.11/8.6.10) with ESMTP id PAA16230 for <info-performer@sgi.com>; Wed, 8 Apr 1998 15:49:39 +0300
Received: from localhost by CS.Technion.AC.IL (SMI-8.6/SMI-SVR4)
	id PAA10124; Wed, 8 Apr 1998 15:49:52 +0300
Date: Wed, 8 Apr 1998 15:49:51 +0300 (IDT)
From: Anda Singer <anda@CS.Technion.AC.IL>
X-Sender: anda@csa
To: info-performer@sgi.com
Subject: Texture loading
Message-ID: <Pine.GSO.3.95-heb-2.07.980408154333.8367A-100000@csa>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hi,
I'd like to read a texture directly from memory,
not from the disk.
How can I do that, and what data format does the
Performer expects (rgb, ...)?
Any insight will be much appreciated.

Thanks,
 Anda
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Anda Singher		anda@cs.technion.ac.il
			tel: 04-8293905
http://www.cs.technion.ac.il/~anda/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 06:02:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA03733 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 05:47:14 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA03706 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 05:47:12 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA9096458
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 05:47:11 -0700 (PDT)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA24391
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 05:47:04 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id OAA09804; Wed, 8 Apr 1998 14:55:22 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma009793; Wed, 8 Apr 98 14:55:17 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id OAA07579;
	Wed, 8 Apr 1998 14:46:46 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804081246.OAA07579@s00sn1.fel.tno.nl>
Subject: Re: Too Big?
To: awalker@multigen.com (Andy Walker)
Date: Wed, 8 Apr 1998 14:46:45 +0200 (MET DST)
Cc: Donna.Allen@PHL.Boeing.com, info-performer@sgi.com
In-Reply-To: <86F098AC14A7D11194DD00A0C9499D040219EC@xserv.engr.multigen.com> from "Andy Walker" at Apr 7, 98 02:52:41 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Hello,

My experience is that if you disable the flattening of loaded flight
geometry there will be only one copy of externals in memory.
I haven't tried instancing to see the results.
You can do this with perfly with the option
    perfly -y,1,0 myfile.flt
Look at the tree to see how the geometry is stored.

In your program with
    pfdConverterMode("flt", PFFLT_FLATTEN, FALSE);

Mario

Andy Walker wrote:
> 
> Hello Donna
> 
> I am not sure how Performer deals with the OpenFlight construct of
> external references and instances.  My experience in the past was that
> externals and instances are turned into unique elements in memory not
> just pointers to one piece of memory.  So in this case a flight file
> with a lot of externals and instances could grow much larger.  
> 
> Does your database use external references and instances extensively?
> 
> Andy Walker
> 
> > -----Original Message-----
> > From:	Angus Dorbie [SMTP:dorbie@sgi.com]
> > Sent:	Tuesday, April 07, 1998 2:15 PM
> > To:	Steve Baker
> > Cc:	Allen, Donna N; 'SGI Performer Users Group'; Reynolds, Berton
> > Subject:	Re: Too Big?
> > 
> > Steve Baker wrote:
> > > 
> > > On Tue, 7 Apr 1998, Allen, Donna N wrote:
> > > 
> > > > hi,
> > > >
> > > > I'm trying to load a 152MB Open Flight database with about 150 KB
> > of
> > > > texture into perfly on an Indigo 2 Extreme with 250 MH processor
> > and 256
> > > > MB Ram.  I crashes with a memory allocation error.  I would think
> > 256MB
> > > > ram would be enough for this.  Is this too big?
> > > 
> > > Sounds like it. You are assuming that the size of a '.flt' file on
> > disk
> > > is somehow a 1:1 correspondance with the amount of memory that a
> > similar
> > > Performer data structure will consume in main memory. This is very
> > far
> > > from the truth (although I confess that I don't know what the actual
> > > ratio is likely to be).
> > 
> > A flt file should take up much less memory than disk space in
> > Performer.
> > 
> > However textures are not embeded in the OpenFlight file format and
> > you'd
> > have to add those to memory useage so what I just said is probably
> > untrue
> > for many textured databases. And during the loading phase a texture
> > will exist in main memory, in  OpenGL, plus MIP maps. Ultimately
> > you won't have a host copy but you still have a copy in system memory
> > in the GL even if it's currently downloaded to texture memory.
> > 
> > Cheers,Angus.
> > 
> > -- 
> > "Only the mediocre are always at their best." -- Jean Giraudoux 
> > 
> > For advanced 3D graphics Performer + OpenGL based examples and tutors:
> > http://www.dorbie.com/
> > ======================================================================
> > =
> > List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
> >             Submissions:  info-performer@sgi.com
> >         Admin. requests:  info-performer-request@sgi.com
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
> 

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 06:56:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA04011 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 06:39:43 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA03984 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 06:39:42 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA8591091
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 06:39:41 -0700 (PDT)
Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA07856
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 06:39:40 -0700 (PDT)
	mail_from (Donna.Allen@PHL.Boeing.com)
Received: from xch-phlbh-01.he.boeing.com ([128.225.22.200])
	by mailgate2.boeing.com (8.8.5/8.8.5) with ESMTP id GAA02513
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 06:39:36 -0700 (PDT)
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.0.1458.49)
	id <H0QHQ45P>; Wed, 8 Apr 1998 09:39:47 -0400
Message-ID: <51CC653FD8E0D011B82900805FFE090CF92B04@xch-phl-03.he.boeing.com>
From: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>
To: "'SGI Performer Users Group'" <info-performer@sgi.com>
Subject: Color?
Date: Wed, 8 Apr 1998 09:39:40 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Status: O

hi again,

This is probably a simple question for most of you folks.  I have
created a flight database using MultiGen Pro II.  When I start up perfly
with:
%      perfly  database.flt

I can see the database textures that are loaded (so it is getting them)
 
I get many of these errors,
PF Notice/Assert:    convTree() unsupported node 113 "unknown" found.

When the database comes up, there are no colors, everything is black.  I
have never had the problem before and do not know what is causing it
now.

Appreciate any info.

Thanks  ( and thanks to all who responded about the too big question!),

Donna


Donna Allen
Boeing Philadelphia                                 phone:    voice:
610-591-7963
Flight Simulation Lab                               fax:   610-591-5636
donna.n.allen@boeing.com                            lab:   610-591-7971
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 07:32:12 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA04215 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 07:20:47 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA04188 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 07:20:46 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA9272245
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 07:20:46 -0700 (PDT)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA19008
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 07:20:44 -0700 (PDT)
	mail_from (boccara@MIT.EDU)
Received: from MIT.MIT.EDU by MIT.EDU with SMTP
	id AA21550; Wed, 8 Apr 98 10:21:28 EDT
Received: from VETREC2.MIT.EDU by MIT.MIT.EDU (5.61/4.7) id AA00238; Wed, 8 Apr 98 10:20:35 EDT
Sender: boccara@MIT.EDU
Message-Id: <352BB22D.151AD7A@mit.edu>
Date: Wed, 08 Apr 1998 10:21:49 -0700
From: Michael Boccara <boccara@MIT.EDU>
Organization: MIT
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22)
Mime-Version: 1.0
To: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>
Cc: "'SGI Performer Users Group'" <info-performer@sgi.com>
Subject: Re: Color?
References: <51CC653FD8E0D011B82900805FFE090CF92B04@xch-phl-03.he.boeing.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Allen, Donna N wrote:
> 
> hi again,
> 
> This is probably a simple question for most of you folks.  I have
> created a flight database using MultiGen Pro II.  When I start up perfly
> with:
> %      perfly  database.flt
> 
> I can see the database textures that are loaded (so it is getting them)
> 
> I get many of these errors,
> PF Notice/Assert:    convTree() unsupported node 113 "unknown" found.
> 
> When the database comes up, there are no colors, everything is black.  I
> have never had the problem before and do not know what is causing it
> now.

You are just working with the bad version of the Multigen loader.
Multigen II Pro generates Openflight version 15.?, while you seem to use version
14.something.
Go to the ftp site of Multigen and get the latest version of the loader :
ftp://ftp.multigen.com

Mike

-- 
Michael Boccara :-)    Massachussets Institute of Technology
boccara@mit.edu :->    Research Laboratory of Electronics
 (617) 253 0005 :-D    Virtual Environment Technologies for Training
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 07:32:14 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA04174 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 07:17:32 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA04147 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 07:17:29 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA6486074
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 07:17:28 -0700 (PDT)
Received: from narnia.aero.swri.edu (narnia.aero.swri.edu [129.162.90.12]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA18192
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 07:17:26 -0700 (PDT)
	mail_from (mcoleman@txdirect.net)
Received: from txdirect.net (pants.aero.swri.edu [129.162.90.59])
	by narnia.aero.swri.edu (8.8.7/8.8.7) with ESMTP id JAA00053;
	Wed, 8 Apr 1998 09:18:26 -0500
Message-ID: <352B8722.E622BFE0@txdirect.net>
Date: Wed, 08 Apr 1998 09:18:10 -0500
From: "Michael A. Coleman" <mcoleman@txdirect.net>
Reply-To: mcoleman@txdirect.net
Organization: Drunk Works Home Brewery
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>
CC: "'SGI Performer Users Group'" <info-performer@sgi.com>
Subject: Re: Color?
References: <51CC653FD8E0D011B82900805FFE090CF92B04@xch-phl-03.he.boeing.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Allen, Donna N wrote:
> 
> hi again,
> 
> This is probably a simple question for most of you folks.  I have
> created a flight database using MultiGen Pro II.  When I start up perfly
> with:
> %      perfly  database.flt
> 
> I can see the database textures that are loaded (so it is getting them)
> 
> I get many of these errors,
> PF Notice/Assert:    convTree() unsupported node 113 "unknown" found.

You are loading a v15.x database with the v14.x loader.  

Make sure:

1.  You have the 15.4 loader.
2.  The various environment variables include its path (LD_LIBRARY_PATH,
PFLD_LIBRARY_PATH, etc).

It happened to me too :>

Regards,

Michael Coleman
mcoleman@txdirect.net
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 08:14:52 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA04398 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 07:52:02 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA04371 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 07:52:01 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA8383173
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 07:52:00 -0700 (PDT)
Received: from vista.taccsf.kirtland.af.mil (vista.taccsf.kirtland.af.mil [132.62.150.76]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA28378
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 07:51:41 -0700 (PDT)
	mail_from (suzie@TACCSF.KIRTLAND.AF.MIL)
Received: by VISTA.TACCSF.KIRTLAND.AF.MIL with Internet Mail Service (5.5.1960.3)
	id <H8JMC6CF>; Wed, 8 Apr 1998 08:51:40 -0600
Message-ID: <214A87629D4FD111931F0060972989BA072E7F@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Loaders
Date: Wed, 8 Apr 1998 08:50:57 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD62FD.BD2C2280"
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD62FD.BD2C2280
Content-Type: text/plain

Speaking of loaders ...

We're currently running Performer 2.0 on a 5.3 OS.  I don't think we can
run with Performer 2.2 executables, but can we use the 15.4 loader?

Thanks,
Suzie

------ =_NextPart_001_01BD62FD.BD2C2280
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>Loaders</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Speaking of loaders ...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We're currently running Performer 2.0 =
on a 5.3 OS.&nbsp; I don't think we can run with Performer 2.2 =
executables, but can we use the 15.4 loader?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Suzie</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD62FD.BD2C2280--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 08:28:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA04529 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 08:11:23 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA04498 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 08:11:22 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA9300836
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 08:11:22 -0700 (PDT)
Received: from quid.engr.sgi.com ([130.62.52.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id IAA04979
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 08:11:21 -0700 (PDT)
	mail_from (robj@quid.engr.sgi.com)
Received: (from robj@localhost) by quid.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA23683; Wed, 8 Apr 1998 08:11:20 -0700
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9804080811.ZM23681@quid.engr.sgi.com>
Date: Wed, 8 Apr 1998 08:11:19 -0700
In-Reply-To: Sandeep Mulgund <smulgund@cra.com>
        "Disabling resizing of pfPipeWindows?" (Apr  7, 10:29am)
References: <v03102804b14fe8841008@[205.181.6.126]>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Sandeep Mulgund <smulgund@cra.com>, info-performer@sgi.com
Subject: Re: Disabling resizing of pfPipeWindows?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 7, 10:29am, Sandeep Mulgund wrote:
> Subject: Disabling resizing of pfPipeWindows?
> Is there any easy way to disable window resizing on a pfPipeWindow? (so
> that the small resize control doesn't appear on any of the window's corners)
>
> Thanks,
>
> Sandeep

I think what you're asking is how to make a window run with no borders, if so
then pfWindow::setMode of PFWIN_NOBORDER is the ticket

Cheers
Rob


-- 
________________________________________________________________
Rob Jenkins mailto:robj@sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 09:49:30 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA04870 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 09:36:24 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA04843 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 09:36:22 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA9247020
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 09:36:22 -0700 (PDT)
Received: from gwinternal.aaicorp.com (gw.aaicorp.com [208.227.103.114]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA10911
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 09:36:17 -0700 (PDT)
	mail_from (daniel@aaicorp.com)
Received: by gwinternal.aaicorp.com; id MAA10543; Wed, 8 Apr 1998 12:37:21 -0400
Received: from aaicorp.com(158.0.0.29) by gw.aaicorp.com. via smap (V3.1.1)
	id xma010530; Wed, 8 Apr 98 12:37:10 -0400
Received: from AAI-Message_Server by aaicorp.com
	with Novell_GroupWise; Wed, 08 Apr 1998 12:36:42 -0400
Message-Id: <s52b6f5a.093@aaicorp.com>
X-Mailer: Novell GroupWise 4.1
Date: Wed, 08 Apr 1998 12:36:33 -0400
From: DANIEL BASS <daniel@aaicorp.com>
To: info-performer@sgi.com
Subject: Alpha-only textures
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Status: O

Hi Performers,

For my application, I want to create a texture map which consists of a series of
silhouettes, stored as different alpha values.  Then by setting an appropriate 
alpha reference value and alpha function, I can choose which sillhouette to use.
The polygon I attach this to, I just want black and z-buffered, so it just hides or
doesn't hide things behind it.

So my question is, what is the most efficient way to store and use a set of these
textures?  Since I am only really using 8 bits of interest, can I somehow use the
Texture environment channel select feature and overlay 4 different textures
in a single RGBA image?

P.S. For what its worth, my application is running on an O2, with Performer 2.0

--daniel
Daniel Bass
AAI Corporation
(410)628-8551
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 20:16:51 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA07602 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 19:54:52 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id TAA07575 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 19:54:50 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id TAA9593350
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 19:54:49 -0700 (PDT)
Received: from cupid.dt.nchc.gov.tw (cupid.dt.nchc.gov.tw [140.110.33.240]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id TAA11272
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 19:53:04 -0700 (PDT)
	mail_from (c00chu00@nchc.gov.tw)
Received: from nchc.gov.tw (elc044.dt.nchc.gov.tw [140.110.12.28])
	by cupid.dt.nchc.gov.tw (8.8.5/8.8.5) with ESMTP id KAA07561;
	Thu, 9 Apr 1998 10:52:47 +0800 (CST)
Received: (from c00chu00@localhost)
	by nchc.gov.tw (8.8.5/8.8.5) id KAA02231;
	Thu, 9 Apr 1998 10:52:39 +0800 (CST)
From: Sam Chu <c00chu00@nchc.gov.tw>
Message-Id: <199804090252.KAA02231@nchc.gov.tw>
Subject: Re: Stats Question correction
To: gischer@puget.engr.sgi.com
Date: Thu, 9 Apr 1998 10:52:38 +0800 (CST)
Cc: info-performer@sgi.com
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O


Thank you for detail explanation about statistics. And from 
all informtion provided by those stats Can we find out the 
program is transform bottleneck or fill bottleneck?


Sam Chu 
National Center for High-Performance Computing 
Scientific Visualization Lab  Email: c00chu00@nchc.gov.tw 
Tel: (886)35-776085 Ext 248   Fax  : (886)35-773538
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 21:17:23 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id UAA07813 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 20:58:03 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id UAA07786 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 20:58:02 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id UAA9570932
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 20:58:01 -0700 (PDT)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id UAA24862
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 20:58:00 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id WAA08133; Wed, 8 Apr 1998 22:56:43 -0500 (CDT)
Date: Wed, 8 Apr 1998 22:56:47 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Sam Chu <c00chu00@nchc.gov.tw>
cc: gischer@puget.engr.sgi.com, info-performer@sgi.com
Subject: Re: Stats Question correction
In-Reply-To: <199804090252.KAA02231@nchc.gov.tw>
Message-ID: <Pine.SGI.3.96.980408225401.21502A-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Thu, 9 Apr 1998, Sam Chu wrote:

> Thank you for detail explanation about statistics. And from 
> all informtion provided by those stats Can we find out the 
> program is transform bottleneck or fill bottleneck?
 
The easiest way is *still* to shrink the size of the window
and see if it goes faster. If it does then it's pretty certain
that it's fill limited. If it doesn't then it's something else
(but not necessarily transforms).

When you do this test, be sure that you switched off Performer's
feature to automatically vary LOD ranges according to display
resolution.
 
Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 21:55:02 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id VAA07910 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 21:32:33 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id VAA07883 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 21:32:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id VAA9584574
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 21:32:32 -0700 (PDT)
Received: from rose.engr.sgi.com ([150.166.37.6]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id VAA02490
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 21:32:31 -0700 (PDT)
	mail_from (src@rose.engr.sgi.com)
Received: (from src@localhost) by rose.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id VAA16153; Wed, 8 Apr 1998 21:32:29 -0700
Date: Wed, 8 Apr 1998 21:32:29 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9804082132.ZM16151@rose.engr.sgi.com>
In-Reply-To: Steve Baker <sbaker@link.com>
        "Re: Stats Question correction" (Apr  8, 10:56pm)
References: <Pine.SGI.3.96.980408225401.21502A-100000@lechter.bgm.link.com>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Steve Baker <sbaker@link.com>, Sam Chu <c00chu00@nchc.gov.tw>
Subject: Re: Stats Question correction
Cc: gischer@puget.engr.sgi.com, info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

+>---- On Apr 8, 10:56pm, Steve Baker wrote:
> Subject: Re: Stats Question correction
->
->On Thu, 9 Apr 1998, Sam Chu wrote:
->
->> Thank you for detail explanation about statistics. And from 
->> all informtion provided by those stats Can we find out the 
->> program is transform bottleneck or fill bottleneck?
-> 
->The easiest way is *still* to shrink the size of the window
->and see if it goes faster. If it does then it's pretty certain
->that it's fill limited. If it doesn't then it's something else
->(but not necessarily transforms).

If you have an iR, you can use manual DVR to do this to draw to a smaller
screen area independent of normal viewport size.

->
->When you do this test, be sure that you switched off Performer's
->feature to automatically vary LOD ranges according to display
->resolution.
-> 

Right!  By default we scale LODs based on viewport and FOV.
You can set the Channel LOD scale factor to 0.  DVR doesn't change
the channel viewport or FOV so will not have this problem.

src.

-- 
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src@sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr  8 23:16:53 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id WAA08191 for info-performer-dist@holodeck.engr.sgi.com; Wed, 8 Apr 1998 22:57:16 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id WAA08164 for <info-performer@holodeck.engr.sgi.com>; Wed, 8 Apr 1998 22:57:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id WAA9562028
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 8 Apr 1998 22:57:13 -0700 (PDT)
Received: from aba.ihpc.nus.edu.sg (aba.nsrc.nus.sg [137.132.15.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id WAA19692
	for <info-performer@sgi.com>; Wed, 8 Apr 1998 22:57:03 -0700 (PDT)
	mail_from (liuxy@nsrc.nus.edu.sg)
Received: (from smap@localhost)
          by aba.ihpc.nus.edu.sg (8.8.5/8.8.4)
	  id NAA16153; Thu, 9 Apr 1998 13:56:14 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma016148; Thu Apr  9 13:55:49 1998
Message-ID: <352C6324.70D1@nsrc.nus.edu.sg>
Date: Thu, 09 Apr 1998 13:56:52 +0800
From: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Organization: National Supercomputing Research Center
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: Michael Boccara <boccara@MIT.EDU>
CC: "Allen, Donna N" <Donna.Allen@PHL.Boeing.com>,
        "'SGI Performer Users Group'" <info-performer@sgi.com>
Subject: Re: Color?  .flt loader problem
References: <51CC653FD8E0D011B82900805FFE090CF92B04@xch-phl-03.he.boeing.com> <352BB22D.151AD7A@mit.edu>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

> >
> > This is probably a simple question for most of you folks.  I have
> > created a flight database using MultiGen Pro II.  When I start up perfly
> > with:
> > %      perfly  database.flt
> > I can see the database textures that are loaded (so it is getting them)
> > I get many of these errors,
> > PF Notice/Assert:    convTree() unsupported node 113 "unknown" found.
> You are just working with the bad version of the Multigen loader.
> Multigen II Pro generates Openflight version 15.?, while you seem to use version
> 14.something.
> Go to the ftp site of Multigen and get the latest version of the loader :
> ftp://ftp.multigen.com

I ran into the same problem yesterday. After I downloaded
Performer-loader-21.tar.Z
(which includes 6 versions loader for 32/64 and IRIS/OPenGL), I have
another problem
now: the sigdlopen version of my performer program is different from
that of the loader,
so it goes back to the old .flt loader and the 'convTree' error remains. 

How to get the same sgi version?

2338: 12:51:41 /home1/liuxy/CAVE/work/navy/navy: loading obj
./libpfflt_ogl.so with version sgi2.4
2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy:
dlopen/sgidladd/sgidlopen_version is called with name =
/home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so, version = sgi2.4
2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy: loading obj
/home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so with versionsgi2.4
2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy: mapped
/home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so at 0x3fdb0000
2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy: Unmapped
/home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so because it is called
from sgidlopen_version with version string 'sgi2.4' and
/home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so does not have the same
version string
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

omni 6% elfdump -L /home1/liuxy/tmp/OPTN64.OPENGL/libpfflt_ogl.so | grep
VER
[7]     RLDVERS  0x1
[27]    IVERSION sgi3.0
           ^^^^^^^^^^^^

Thanks for any information.

Liu Xiaoyan


***********************************************************************
Liu Xiaoyan                 National Supercomputing Research Center
Data Visualization Group    http://www.nsrc.nus.edu.sg Tel:(65)7709267
***********************************************************************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 01:06:10 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA08875 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 00:48:47 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id AAA08848 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 00:48:42 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA9635598
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 00:48:41 -0700 (PDT)
Received: from merki.connect.com.au (merki.connect.com.au [192.189.54.36]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id AAA11139
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 00:48:39 -0700 (PDT)
	mail_from (simonb@wormald.com.au)
Received: from zebedee.UUCP (Uzebedee@localhost) by merki.connect.com.au with UUCP id RAA18210
  (8.8.8/IDA-1.7 for info-performer@sgi.com); Thu, 9 Apr 1998 17:48:37 +1000 (EST)
Received: from aggro (aggro_e [8.0.0.25]) by zebedee.wormald.com.au with ESMTP id RAA19166
  (8.8.7/IDA-1.6 for <info-performer@sgi.com>); Thu, 9 Apr 1998 17:29:56 +1000 (EST)
Received: from murad (murad [8.0.0.108]) by aggro with SMTP id RAA03982
  (8.6.12/IDA-1.6 for <info-performer@sgi.com>); Thu, 9 Apr 1998 17:33:11 +1000
Received: from localhost by murad (5.65) id AA06947; Thu, 9 Apr 1998 17:33:11 +1000
Date: Thu, 9 Apr 1998 17:43:08 +1010 (EST)
From: Simon Bennett <simonb@wormald.com.au>
X-Sender: simonb@murad
To: info-performer@sgi.com
Subject: So long...
Message-Id: <Pine.OSF.3.94.980409174236.1566L-100000@murad>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O



..and thanx for all the fish 

:)

+----------------------------------------------------------------------------+
  Simon Bennett       simonb@wormald.com.au
  Wormald Technology  Advanced Systems Engineering Ph: +61 2 9981 0669

		"Good judgement is the result of experience.
		 Experience is the result of poor judgement"

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 05:03:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA09670 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 04:49:34 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA09643 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 04:49:33 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA6253478
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 04:49:32 -0700 (PDT)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA24438
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 04:49:29 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id NAA13593; Thu, 9 Apr 1998 13:57:50 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma013560; Thu, 9 Apr 98 13:57:23 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id NAA10708;
	Thu, 9 Apr 1998 13:48:56 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804091148.NAA10708@s00sn1.fel.tno.nl>
Subject: Re: Color?  .flt loader problem
To: liuxy@ihpc.nus.edu.sg (Liu Xiaoyan)
Date: Thu, 9 Apr 1998 13:48:55 +0200 (MET DST)
Cc: info-performer@sgi.com (Performer)
In-Reply-To: <352C6324.70D1@nsrc.nus.edu.sg> from "Liu Xiaoyan" at Apr 9, 98 01:56:52 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> 
> > >
> > > This is probably a simple question for most of you folks.  I have
> > > created a flight database using MultiGen Pro II.  When I start up perfly
> > > with:
> > > %      perfly  database.flt
> > > I can see the database textures that are loaded (so it is getting them)
> > > I get many of these errors,
> > > PF Notice/Assert:    convTree() unsupported node 113 "unknown" found.
> > You are just working with the bad version of the Multigen loader.
> > Multigen II Pro generates Openflight version 15.?, while you seem to use version
> > 14.something.
> > Go to the ftp site of Multigen and get the latest version of the loader :
> > ftp://ftp.multigen.com
> 
> I ran into the same problem yesterday. After I downloaded
> Performer-loader-21.tar.Z
> (which includes 6 versions loader for 32/64 and IRIS/OPenGL), I have
> another problem
> now: the sigdlopen version of my performer program is different from
> that of the loader,
> so it goes back to the old .flt loader and the 'convTree' error remains. 
> 
> How to get the same sgi version?
> 
> 2338: 12:51:41 /home1/liuxy/CAVE/work/navy/navy: loading obj
> ./libpfflt_ogl.so with version sgi2.4
> 2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy:
> dlopen/sgidladd/sgidlopen_version is called with name =
> /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so, version = sgi2.4
> 2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy: loading obj
> /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so with versionsgi2.4
> 2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy: mapped
> /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so at 0x3fdb0000
> 2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy: Unmapped
> /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so because it is called
> from sgidlopen_version with version string 'sgi2.4' and
> /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so does not have the same
> version string
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> omni 6% elfdump -L /home1/liuxy/tmp/OPTN64.OPENGL/libpfflt_ogl.so | grep
> VER
> [7]     RLDVERS  0x1
> [27]    IVERSION sgi3.0
>            ^^^^^^^^^^^^
> 
> Thanks for any information.
> 
> Liu Xiaoyan

During link time the linker looks in the DSO's and stores the version
numbers in the executable. So my suggestion is recompile your program
and look with 'elfdump -Dl' what the versions is of the DSO's it wants
to load

Mario
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 05:03:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA09637 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 04:45:57 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA09610 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 04:45:54 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA9696234
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 04:45:53 -0700 (PDT)
Received: from acetef.nawcad.navy.mil (acetef.nawcad.navy.mil [140.229.93.252]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id EAA23759
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 04:45:51 -0700 (PDT)
	mail_from (sbrabson@southernmaryland.com)
Received: from acetef (acetef.nawcad.navy.mil [140.229.93.252]) by acetef.nawcad.navy.mil (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id HAA08684; Thu, 9 Apr 1998 07:49:23 -0400
Sender: sbrabson@southernmaryland.com
Message-ID: <352CB5C3.41C6@southernmaryland.com>
Date: Thu, 09 Apr 1998 07:49:23 -0400
From: Scott Brabson <sbrabson@southernmaryland.com>
Organization: Web Constructors
X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
CC: tdrapas@dcscorp.com, jsong@dcscorp.com
Subject: ClipTextures and Filters
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hello All,

I have a cliptexture that consists of luminance values. When I position
my viewpoint to look at the horizon it looks great. As I fly toward the
horizon the texture past level 0 appears to be flickering. I figured it
was the way the Minification filter was being applied. Looking at the
man page for MPCliptextures and ClipTextures a method to set the Mag
filter exists but not for Minification. I created this section of code
to see if I could set the Minfilter through pfTexture. The filter type
never changes. It always stays at PFTEX_TRILINEAR. 

My Questions:

1. Why is there no Minfilter option for ClipTextures?
2. Is there a way to remove this flickering? Has anyone seen this
flickering?
3. Why is the Minfilter set to trilinear?


Thanks,
Scott Brabson
DCS Corporation


Here is the code sample: Is this correct?

{
pfTexture * text;
int type;

   text = (pfTexture *)pfGetMPClipTextureClipTexture(MPClipTex);

   type = pfGetTexFilter(text, PFTEX_MINFILTER);

   if(type == PFTEX_POINT)
	cout << "--- Minfilter == POINT" << endl;
   else if(type == PFTEX_TRILINEAR
	cout << "--- Minfilter == TRILINEAR" << endl;
   else
	cout << "---Filter set to: << type << endl;


   pfTexFilter(text,PFTEX_MINFILTER,PFTEX_MIPMAP_POINT);

  
   type = pfGetTexFilter(text, PFTEX_MINFILTER);

   if(type == PFTEX_POINT)
	cout << "--- Minfilter == POINT" << endl;
   else if(type == PFTEX_TRILINEAR
	cout << "--- Minfilter == TRILINEAR" << endl;
   else
	cout << "---Filter set to: << type << endl;

   //This is always PFTEX_TRILINEAR!!!!
}
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 08:36:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA10198 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 08:18:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA10171 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 08:18:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA9739257
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 08:18:35 -0700 (PDT)
Received: from quid.engr.sgi.com ([130.62.52.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id IAA19472
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 08:18:33 -0700 (PDT)
	mail_from (robj@quid.engr.sgi.com)
Received: (from robj@localhost) by quid.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA25480; Thu, 9 Apr 1998 08:18:32 -0700
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9804090818.ZM25478@quid.engr.sgi.com>
Date: Thu, 9 Apr 1998 08:18:32 -0700
In-Reply-To: src@rose (Sharon Clay)
        "Re: Stats Question correction" (Apr  8,  9:32pm)
References: <Pine.SGI.3.96.980408225401.21502A-100000@lechter.bgm.link.com> 
	<9804082132.ZM16151@rose.engr.sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Sam Chu <c00chu00@nchc.gov.tw>
Subject: Re: Stats Question correction
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Sam

If the suggestions for testing a fill limitation show that you are not fill
limited then there's some things you can look at to test for a transform
bottleneck. Expensive things in the transform stage are: multiple lights, state
changes ( shademodel, texture, material ). The Performer programming guide has
more detail on tracking these things and also on what can be done ( and what
Performer does by default ) to sort the scene by graphics state. The P.G is
still a bit Reality Engine-centric but the principles are the same if you have
iR. pfStats that might indicate lot's of transform intensive mode changes:

tstrip histogram: large % short strips
primitives per GSet or State: low

unneeded per vertex attributes being sent, eg number of colors equals numbers
of vertices for a flat shaded scene. The geometry stats will show this info.

High total number of primitives, 'high' depends on type of primitive. GLperf
benchmarks will give an idea of peak rates for different types, see
http://www.specbench.org/gpc/opc/glperf_publish/index.html although they only
have numbers for a 1Rm iR there, numbers for more RMs are available somewhere
external to SGI I'm sure. The rule of thumb generally is that getting 70% of
peak throughput for a given primitive type is good going in a real app.

number of lights, type of lights and light models: transform overhead increases
with each light and light model. Shown in the State stats.

Cheers
Rob

On Apr 8,  9:32pm, Sharon Clay wrote:
> Subject: Re: Stats Question correction
> +>---- On Apr 8, 10:56pm, Steve Baker wrote:
> > Subject: Re: Stats Question correction
> ->
> ->On Thu, 9 Apr 1998, Sam Chu wrote:
> ->
> ->> Thank you for detail explanation about statistics. And from
> ->> all informtion provided by those stats Can we find out the
> ->> program is transform bottleneck or fill bottleneck?
> ->
> ->The easiest way is *still* to shrink the size of the window
> ->and see if it goes faster. If it does then it's pretty certain
> ->that it's fill limited. If it doesn't then it's something else
> ->(but not necessarily transforms).
>
> If you have an iR, you can use manual DVR to do this to draw to a smaller
> screen area independent of normal viewport size.
>
> ->
> ->When you do this test, be sure that you switched off Performer's
> ->feature to automatically vary LOD ranges according to display
> ->resolution.
> ->
>
> Right!  By default we scale LODs based on viewport and FOV.
> You can set the Channel LOD scale factor to 0.  DVR doesn't change
> the channel viewport or FOV so will not have this problem.
>
> src.
>
> --
> -----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
> Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
> src@sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
> -----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from Sharon Clay



-- 
________________________________________________________________
Rob Jenkins mailto:robj@sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 08:52:53 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA10276 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 08:37:58 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA10249 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 08:37:57 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA9569422
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 08:37:57 -0700 (PDT)
Received: from ns.yle.fi (ns.yle.fi [193.65.105.161]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id IAA27501
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 08:37:53 -0700 (PDT)
	mail_from (harri.kaimio@yle.fi)
Received: by ns.yle.fi; id SAA10097; Thu, 9 Apr 1998 18:40:14 +0300 (EEST)
Received: from thaxp1.yle.fi(193.65.107.2) by ns.yle.fi via smap (4.0a)
	id xma009965; Thu, 9 Apr 98 18:39:14 +0300
Received: by thaxp1.yle.fi id SAA03811 ; Thu, 9 Apr 1998 18:36:50 +0300 (EET DST)
Received: from yle.fi (bali.yle.fi [192.168.250.232]) by sgisrv.yle.fi (8.8.5/8.6.9) with ESMTP id PAA08265 for <info-performer@sgi.com>; Thu, 9 Apr 1998 15:36:49 GMT
Sender: harri@yle.fi
Message-ID: <352CEB10.14CCA43D@yle.fi>
Date: Thu, 09 Apr 1998 18:36:49 +0300
From: Harri Kaimio <harri.kaimio@yle.fi>
Organization: Finnish Broadcasting Company
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Movie file as texture
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi Performers!

This is not Performer specific, but I wonder if anyone has used a
JPEG-compressed movie file as a texture map with the old compression
library. This seems to be easy using dmbuffers, but my application must
run on 6.2 and they were not available until 6.3 (I think)

What I have done: I have a separate thread in which I read the JPEG data
and decompress it using Impact Compression card. I then load the
uncompressed frames to texture map in draw callback (using
pfTexture::subload). This works, but it CL uses the old IRIS GL pixel
format XBGR (although it calls it RGBX!)

I tried to call
  _texture->setFormat( PFTEX_INTERNAL_FORMAT, GL_ABGR_EXT );
when I defined the texture, but I got only a blank texture. Is this the
right way to set the texel format, or should I do something else? Also,
is there a fill rate penalty when using GL_ABGR_EXT texel format
compared to RGBX? I am already fill rate limited so this would be bad.

I would appreciate any ideas. What I really need is to display an
512x512 animated texture map (RGB, 8 bit per component) on High Impact.
The animation has about 100 frames and must run 25 fps, so I guess that
storing it uncompressed on disk or in memory is not possible.

--
-----------------------------------------------------------------
Harri Kaimio                    |             harri.kaimio@yle.fi
Computer Graphics Specialist    |   http://cartes.hut.fi/~hkaimio
Finnish Broadcasting Company    |          Tel. +358-40-50 67 679
TV Production Operations        |           Fax. +358-0-1480 4769



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 12:18:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA10954 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 12:08:51 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA10927 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 12:08:50 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA9796366
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 12:08:49 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA10033
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 12:08:48 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id MAA04698; Thu, 9 Apr 1998 12:19:24 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id TAA13840; Thu, 9 Apr 1998 19:09:25 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA27628; Thu, 9 Apr 1998 12:09:15 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804091209.ZM27626@logan.engr.multigen.com>
Date: Thu, 9 Apr 1998 12:09:15 -0700
In-Reply-To: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
        "Loaders" (Apr  8,  8:50am)
References: <214A87629D4FD111931F0060972989BA072E7F@VISTA.TACCSF.KIRTLAND.AF.MIL>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>,
        "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: Loaders
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 8,  8:50am, Bemis, Suzie CEI-TACCSF wrote:
>
>We're currently running Performer 2.0 on a 5.3 OS.  I don't think we can
>run with Performer 2.2 executables, but can we use the 15.4 loader?

You must upgrade to at least Performer 2.0.2 (patch 1414) to use R15.4 loaders.

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 12:18:05 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA10919 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 12:06:02 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA10892 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 12:06:01 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA9840753
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 12:06:00 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA08863
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 12:05:58 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id MAA04656 for <info-performer@sgi.com>; Thu, 9 Apr 1998 12:16:42 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id TAA13764 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Thu, 9 Apr 1998 19:06:42 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA27613 for info-performer@sgi.com; Thu, 9 Apr 1998 12:06:42 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804091206.ZM27611@logan.engr.multigen.com>
Date: Thu, 9 Apr 1998 12:06:41 -0700
In-Reply-To: Michael Boccara <boccara@MIT.EDU>
        "Re: Color?" (Apr  8, 10:21am)
References: <51CC653FD8E0D011B82900805FFE090CF92B04@xch-phl-03.he.boeing.com> 
	<352BB22D.151AD7A@mit.edu>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Re: Color?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 8, 10:21am, Michael Boccara wrote:
>
>You are just working with the bad version of the Multigen loader.

not "bad" ... just too old to understand the new format.

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 13:21:51 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA11252 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 13:11:04 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA11225 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 13:10:58 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA9886865
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 13:10:58 -0700 (PDT)
Received: from MVB.SAIC.COM (mvb.saic.com [139.121.16.104]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA02046
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 13:10:56 -0700 (PDT)
	mail_from (blanchard@apo.saic.com)
Received: from mclapo.apo.saic.com ([149.8.95.65]) by MVB.SAIC.COM (M-Mail V10.0) with SMTP
	id 3018435-M; Thu, 09 Apr 1998 06:21:29 -0700
Received: from vfr.arship21.com ([208.199.160.98]) by mclapo.apo.saic.com with SMTP;
          Thu, 9 Apr 1998 9:21:14 -0400
Message-ID: <352CCA05.119B@apo.saic.com>
Date: Thu, 09 Apr 1998 09:15:49 -0400
From: "Paul E. Blanchard" <blanchard@apo.saic.com>
Organization: SAIC
X-Mailer: Mozilla 3.01 (Win95; U)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: problems(?) w/ 3ds loader
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hey pfLoaders (again)!

Thanks to all who helped me out on the MAX loader issue.  For those
interested, it seems all folks with MAX formatted models tranlate to
3ds and use the 3ds loader in Performer.  So no, it seems that a
MAX Performer loader does not exist (forget MAX2).

Anyway...

When loading a 3ds model in Perfly, we're getting the following error:

PF Info:                         Converting and merging texture images
PF                             Supressing file:"concbrk.tga"
PF Info:                       Auto Disabling Texture coords because
texture is off

Is this a problem with how we save the 3ds model in MAX, or is the
Performer-3ds library faulty/old?  We're running Performer 2.1 on
an Onyx IR w/ 6.2.  Thanks for any help!

--Paul
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 14:52:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA11568 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 14:44:50 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA11541 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 14:44:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA9860538
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 14:44:48 -0700 (PDT)
Received: from spiffy.paradigmsim.com (spiffy.paradigmsim.com [206.7.114.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id OAA09860
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 14:44:45 -0700 (PDT)
	mail_from (jperser@paradigmsim.com)
Received: from howardspc by spiffy.paradigmsim.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO)
	for <info-performer@sgi.com> id QAA22472; Thu, 9 Apr 1998 16:39:38 -0500
From: "John Perser" <jperser@paradigmsim.com>
To: <info-performer@sgi.com>
Subject: Audio In Simulations
Date: Thu, 9 Apr 1998 16:47:18 -0500
Message-ID: <000201bd6401$11777bf0$827207ce@howardspc.paradigmsim.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0003_01BD63D7.28A3BDE0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Status: O

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01BD63D7.28A3BDE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I'm doing a personal survey about audio use in simulations.  You won't be
contacted by any marketing person.  This is for my own use for product
development purposes.  Please reply to me personally at
jperser@paradigmsim.com.
All replies will be kept in strict confidence.

Thank you.

1. Do you currently use audio in your simulation or graphics application?

2. If not, why?

3. Is localized sound a priority for audio in your application?

4. Do you prefer speakers or headphones for your simulation?

5. What % CPU load would you find acceptable for audio processes in your
simulation?

6. Are room acoustics, reverberation and echos important to you in your
simulation?

7. Are you willing to sacrifice additional main CPU cycles to perform these
functions?

8. Other audio needs?

---

------=_NextPart_000_0003_01BD63D7.28A3BDE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>I'm=20
doing a personal survey about audio use in simulations.&nbsp; You won't =
be=20
contacted by any marketing person.&nbsp; This is for my own use for =
product=20
development purposes.&nbsp; Please reply to me personally at <A=20
href=3D"mailto:jperser@paradigmsim.com">jperser@paradigmsim.com.</A></FON=
T></SPAN></DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN><SPAN class=3D343353915-09041998><FONT =
color=3D#000000=20
face=3DArial size=3D2>All replies will be kept in strict=20
confidence.</FONT></SPAN></DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>Thank=20
you.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>1. Do=20
you currently use audio in your simulation or graphics=20
application?</FONT></SPAN></DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>2. If=20
not, why?</FONT></SPAN></DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>3. Is=20
localized sound a priority for audio in your =
application?</FONT></SPAN></DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>4. Do=20
you prefer speakers or headphones for your =
simulation?</FONT></SPAN></DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>5.=20
What % CPU load would you find acceptable for audio processes in your=20
simulation?</FONT></SPAN></DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>6. Are=20
room acoustics, reverberation and echos important to you in your=20
simulation?</FONT></SPAN></DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>7. Are=20
you willing to sacrifice additional main CPU cycles to perform these=20
functions?</FONT></SPAN></DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =
size=3D2>8.=20
Other audio needs?</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=3D343353915-09041998><FONT color=3D#000000 face=3DArial =

size=3D2>---</FONT></SPAN></DIV></DIV></BODY></HTML>

------=_NextPart_000_0003_01BD63D7.28A3BDE0--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 14:52:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA11528 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 14:35:29 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA11501 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 14:35:29 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA9846476
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 14:35:28 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA06527
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 14:35:27 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA9851446;
	Thu, 9 Apr 1998 14:35:26 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA08161; Thu, 9 Apr 1998 14:35:26 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <352D3F1D.FDC34267@sgi.com>
Date: Thu, 09 Apr 1998 14:35:25 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Simon Bennett <simonb@wormald.com.au>
CC: info-performer@sgi.com
Subject: Re: So long...
References: <Pine.OSF.3.94.980409174236.1566L-100000@murad>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Keep in touch.

Where are you going?

Cheers,Angus.



-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 15:35:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA11838 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 15:16:57 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA11811 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 15:16:56 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA9891036
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 15:16:55 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA22291
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 15:16:54 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA9910785;
	Thu, 9 Apr 1998 15:16:49 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA08354; Thu, 9 Apr 1998 15:16:49 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <352D48D0.326841DD@sgi.com>
Date: Thu, 09 Apr 1998 15:16:48 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: DANIEL BASS <daniel@aaicorp.com>
CC: info-performer@sgi.com
Subject: Re: Alpha-only textures
References: <s52b6f5a.093@aaicorp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

DANIEL BASS wrote:
> 
> Hi Performers,
> 
> For my application, I want to create a texture map which consists of a series of
> silhouettes, stored as different alpha values.  Then by setting an appropriate
> alpha reference value and alpha function, I can choose which sillhouette to use.
> The polygon I attach this to, I just want black and z-buffered, so it just hides or
> doesn't hide things behind it.
> 
> So my question is, what is the most efficient way to store and use a set of these
> textures?  Since I am only really using 8 bits of interest, can I somehow use the
> Texture environment channel select feature and overlay 4 different textures
> in a single RGBA image?
> 
> P.S. For what its worth, my application is running on an O2, with Performer 2.0


You could use the GL_ALPHA8 token for the components which is probably
best
on O2, on ONYX2 you probably want to use GL_DUAL_ALPHA8_SGIS.

For occlusion information unless you need 8 bits fo rthe blend you
should
consider even smaller formats like GL_QUAD_ALPHA4_SGIS.

You need to select which bits of the image you want to address for the
DUAL & QUAD formats using glTexParameter with
GL_DUAL_TEXTURE_SELECT_SGIS
or GL_QUAD_TEXTURE_SELECT_SGIS tokens.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr  9 18:03:10 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA12439 for info-performer-dist@holodeck.engr.sgi.com; Thu, 9 Apr 1998 17:50:32 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA12412 for <info-performer@holodeck.engr.sgi.com>; Thu, 9 Apr 1998 17:50:27 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA10015913
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 9 Apr 1998 17:50:26 -0700 (PDT)
Received: from aspen (SIM.IRK.AETC.AF.MIL [192.206.75.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id RAA17026
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 17:50:23 -0700 (PDT)
	mail_from (cary@aspen.sim.irk.aetc.af.mil)
Received: from buttermilk.sim.irk.aetc.af.mil (buttermilk.sim.irk.aetc.af.mil [192.206.75.11])
	by aspen (8.8.5/8.8.5) with SMTP id SAA12288
	for <info-performer@sgi.com>; Thu, 9 Apr 1998 18:49:17 -0600 (MDT)
Received: by buttermilk.sim.irk.aetc.af.mil (SMI-8.6/SMI-SVR4)
	id SAA10212; Thu, 9 Apr 1998 18:49:15 -0600
Date: Thu, 9 Apr 1998 18:49:15 -0600
From: cary@sim.irk.aetc.af.mil (Cary Black)
Message-Id: <199804100049.SAA10212@buttermilk.sim.irk.aetc.af.mil>
To: info-performer@sgi.com
Subject: please remove from mail list
X-Sun-Charset: US-ASCII
Status: O

Would you please remove me from the mail list

Thanks

Cary Black
Lockheed Martin
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 10 04:37:32 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA02164 for info-performer-dist@holodeck.engr.sgi.com; Fri, 10 Apr 1998 04:14:01 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA02137 for <info-performer@holodeck.engr.sgi.com>; Fri, 10 Apr 1998 04:14:00 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA7822868
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 10 Apr 1998 04:13:59 -0700 (PDT)
Received: from aba.ihpc.nus.edu.sg (aba.ihpc.nus.edu.sg [137.132.15.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA02900
	for <info-performer@sgi.com>; Fri, 10 Apr 1998 04:13:52 -0700 (PDT)
	mail_from (liuxy@nsrc.nus.edu.sg)
Received: (from smap@localhost)
          by aba.ihpc.nus.edu.sg (8.8.5/8.8.4)
	  id TAA25937; Fri, 10 Apr 1998 19:13:38 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma025935; Fri Apr 10 19:13:33 1998
Message-ID: <352DFF1C.F84@nsrc.nus.edu.sg>
Date: Fri, 10 Apr 1998 19:14:36 +0800
From: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Organization: National Supercomputing Research Center
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: Mario Veraart <rioj7@fel.tno.nl>
CC: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>, Performer <info-performer@sgi.com>
Subject: Re: Color?  .flt loader problem
References: <199804091148.NAA10708@s00sn1.fel.tno.nl>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

> > another problem now: the sigdlopen version of my performer program is different from
> > that of the loader, so it goes back to the old .flt loader and the 'convTree' error remains.
> >
> > How to get the same sgi version?
> >
> > 2338: 12:51:41 /home1/liuxy/CAVE/work/navy/navy: loading obj
> > ./libpfflt_ogl.so with version sgi2.4
> > 2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy:
> > dlopen/sgidladd/sgidlopen_version is called with name =
> > /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so, version = sgi2.4
> > 2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy: loading obj
> > /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so with versionsgi2.4
> > 2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy: mapped
> > /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so at 0x3fdb0000
> > 2338: 12:51:42 /home1/liuxy/CAVE/work/navy/navy: Unmapped
> > /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so because it is called
> > from sgidlopen_version with version string 'sgi2.4' and
> > /home1/liuxy/tmp/OPT.N64.OPENGL//libpfflt_ogl.so does not have the same
> > version string
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > omni 6% elfdump -L /home1/liuxy/tmp/OPTN64.OPENGL/libpfflt_ogl.so | grep
> > VER
> > [7]     RLDVERS  0x1
> > [27]    IVERSION sgi3.0
> >            ^^^^^^^^^^^^
> >
> 
> During link time the linker looks in the DSO's and stores the version
> numbers in the executable. So my suggestion is recompile your program
> and look with 'elfdump -Dl' what the versions is of the DSO's it wants
> to load
> 
> Mario

Sorry, I didn't get what you mean. From the infomation of rld above, it
says that my program wants 'sgi2.4' while the DSO for .flt loader is
sgi3.0.

Thank you.

Liu Xiaoyan
***********************************************************************
Liu Xiaoyan                 National Supercomputing Research Center
Data Visualization Group    http://www.nsrc.nus.edu.sg Tel:(65)7709267
***********************************************************************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 10 04:53:29 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA02228 for info-performer-dist@holodeck.engr.sgi.com; Fri, 10 Apr 1998 04:30:15 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA02201 for <info-performer@holodeck.engr.sgi.com>; Fri, 10 Apr 1998 04:30:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA8582547
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 10 Apr 1998 04:30:14 -0700 (PDT)
Received: from aba.ihpc.nus.edu.sg (aba.ihpc.nus.edu.sg [137.132.15.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA04990
	for <info-performer@sgi.com>; Fri, 10 Apr 1998 04:30:11 -0700 (PDT)
	mail_from (liuxy@nsrc.nus.edu.sg)
Received: (from smap@localhost)
          by aba.ihpc.nus.edu.sg (8.8.5/8.8.4)
	  id TAA25981 for <info-performer@sgi.com>; Fri, 10 Apr 1998 19:30:10 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma025978; Fri Apr 10 19:30:04 1998
Message-ID: <352E02FB.3CC7@nsrc.nus.edu.sg>
Date: Fri, 10 Apr 1998 19:31:07 +0800
From: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Organization: National Supercomputing Research Center
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: PFQHIT_XFORM
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

Hi, all.  

After myNode->isect(.....) is called, what is the matrix returned from 
pfHit->query(PFQHIT_XFORM,...)?  the transformation matrix rooted from
'myNode' or from root of the scene graph? I just cannot get the correct
collision point.

Thanks,

Liu Xiaoyan

***********************************************************************
Liu Xiaoyan                 National Supercomputing Research Center
Data Visualization Group    http://www.nsrc.nus.edu.sg Tel:(65)7709267
***********************************************************************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 10 05:47:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA02490 for info-performer-dist@holodeck.engr.sgi.com; Fri, 10 Apr 1998 05:25:49 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA02463 for <info-performer@holodeck.engr.sgi.com>; Fri, 10 Apr 1998 05:25:48 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA10085777
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 10 Apr 1998 05:25:47 -0700 (PDT)
Received: from relay2.smtp.psi.net (relay2.smtp.psi.net [38.8.188.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA13290
	for <info-performer@sgi.com>; Fri, 10 Apr 1998 05:25:46 -0700 (PDT)
	mail_from (gwaldron@peril.com)
Received: from killer by relay2.smtp.psi.net (8.8.5/SMI-5.4-PSI)
	id IAA05687; Fri, 10 Apr 1998 08:23:00 -0400 (EDT)
Message-ID: <005701bd647b$eca911a0$0fedb526@killer.potomacinstitute.com>
From: "Glenn Waldron" <gwaldron@peril.com>
To: "Liu Xiaoyan" <liuxy@ihpc.nus.edu.sg>
Cc: <info-performer@sgi.com>
Subject: Re: Color?  .flt loader problem
Date: Fri, 10 Apr 1998 08:24:17 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Status: O

You wrote:
[...]
>> > omni 6% elfdump -L /home1/liuxy/tmp/OPTN64.OPENGL/libpfflt_ogl.so |
grep
>> > VER
>> > [7]     RLDVERS  0x1
>> > [27]    IVERSION sgi3.0
>> >            ^^^^^^^^^^^^
>> >
>>
>> During link time the linker looks in the DSO's and stores the version
>> numbers in the executable. So my suggestion is recompile your program
>> and look with 'elfdump -Dl' what the versions is of the DSO's it wants
>> to load
>>
>> Mario
>
>Sorry, I didn't get what you mean. From the infomation of rld above, it
>says that my program wants 'sgi2.4' while the DSO for .flt loader is
>sgi3.0.


This means your program was compiled with Performer 2.0, but you
have the Performer 2.1 .flt loader.  So, you either need to compile
under pf2.1, or get a .flt loader for pf2.0.  -g.

--
Glenn Waldron - Tech Dir., Peril Technologies Inc
gwaldron@peril.com - www.peril.com - 703.598.7835


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 10 06:03:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA02532 for info-performer-dist@holodeck.engr.sgi.com; Fri, 10 Apr 1998 05:43:09 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA02505 for <info-performer@holodeck.engr.sgi.com>; Fri, 10 Apr 1998 05:43:08 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA9992245
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 10 Apr 1998 05:43:08 -0700 (PDT)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA16207
	for <info-performer@sgi.com>; Fri, 10 Apr 1998 05:43:06 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id OAA05320; Fri, 10 Apr 1998 14:51:29 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma005318; Fri, 10 Apr 98 14:51:27 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id OAA03370;
	Fri, 10 Apr 1998 14:42:56 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804101242.OAA03370@s00sn1.fel.tno.nl>
Subject: Re: Color?  .flt loader problem
To: liuxy@ihpc.nus.edu.sg (Liu Xiaoyan)
Date: Fri, 10 Apr 1998 14:42:55 +0200 (MET DST)
Cc: info-performer@sgi.com (Performer)
In-Reply-To: <352DFF1C.F84@nsrc.nus.edu.sg> from "Liu Xiaoyan" at Apr 10, 98 07:14:36 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> > > omni 6% elfdump -L /home1/liuxy/tmp/OPTN64.OPENGL/libpfflt_ogl.so | grep
> > > VER
> > > [7]     RLDVERS  0x1
> > > [27]    IVERSION sgi3.0
> > >            ^^^^^^^^^^^^
> > >
> > 
> > During link time the linker looks in the DSO's and stores the version
> > numbers in the executable. So my suggestion is recompile your program
> > and look with 'elfdump -Dl' what the versions is of the DSO's it wants
> > to load
> > 
> > Mario
> 
> Sorry, I didn't get what you mean. From the infomation of rld above, it
> says that my program wants 'sgi2.4' while the DSO for .flt loader is
> sgi3.0.
> 

The linker looks for DSO's in the specified directories. If it finds
one it will get the version number and stores it in the executable,
the DSO table. You can see this table with the command elfdump -Dl.
It will have an entry for the libpfflt DSO if you have mentioned on
the link line '-lpfflt' .
If you use the pfdInitConverter(".flt"); it could be that the your
executable is incompatible with the flight loader with respect to the
ABI (o32, N32) and the mips instruction set. You can find these out
with the 'file' command.

Mario
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 10 19:42:02 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA01165 for info-performer-dist@holodeck.engr.sgi.com; Fri, 10 Apr 1998 12:54:56 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA01135 for <info-performer@holodeck.engr.sgi.com>; Fri, 10 Apr 1998 12:54:40 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA10270324
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 10 Apr 1998 11:47:27 -0700 (PDT)
Received: from quid.engr.sgi.com ([130.62.52.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA16950
	for <info-performer@sgi.com>; Fri, 10 Apr 1998 11:47:26 -0700 (PDT)
	mail_from (robj@quid.engr.sgi.com)
Received: (from robj@localhost) by quid.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA28535; Fri, 10 Apr 1998 11:47:24 -0700
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9804101147.ZM28533@quid.engr.sgi.com>
Date: Fri, 10 Apr 1998 11:47:24 -0700
In-Reply-To: Scott Brabson <sbrabson@southernmaryland.com>
        "ClipTextures and Filters" (Apr  9,  7:49am)
References: <352CB5C3.41C6@southernmaryland.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Scott Brabson <sbrabson@southernmaryland.com>, info-performer@sgi.com
Subject: Re: ClipTextures and Filters
Cc: tdrapas@dcscorp.com, jsong@dcscorp.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Scott

The iR clipmap implementatation doesn't support any min filter other than
CLIPMAP_TRILINEAR. The problem you describe could be something else, Don Hatch
had this to say:

"
As for the flickering,  I assume it's jumping back and forth between coarser
and finer levels.
It might be helpful to tweak the parameters with:
	setDTRFadeCount
	setTexLoadTime or setTexLoadTimeFrac
	setDTRBlurMargin
or move more slowly.
"

To debug this better the kind of useful info you could give is:
cliptexture 'stats' eg size ( and hence levels ), type.
the values you set with the cliptexture parameters. Can you load your data into
clipfly and manually adjust parameters to see what effect they have ?

Cheers
Rob


On Apr 9,  7:49am, Scott Brabson wrote:
> Subject: ClipTextures and Filters
> Hello All,
>
> I have a cliptexture that consists of luminance values. When I position
> my viewpoint to look at the horizon it looks great. As I fly toward the
> horizon the texture past level 0 appears to be flickering. I figured it
> was the way the Minification filter was being applied. Looking at the
> man page for MPCliptextures and ClipTextures a method to set the Mag
> filter exists but not for Minification. I created this section of code
> to see if I could set the Minfilter through pfTexture. The filter type
> never changes. It always stays at PFTEX_TRILINEAR.
>
> My Questions:
>
> 1. Why is there no Minfilter option for ClipTextures?
> 2. Is there a way to remove this flickering? Has anyone seen this
> flickering?
> 3. Why is the Minfilter set to trilinear?
>
>
> Thanks,
> Scott Brabson
> DCS Corporation
>
>
> Here is the code sample: Is this correct?
>
> {
> pfTexture * text;
> int type;
>
>    text = (pfTexture *)pfGetMPClipTextureClipTexture(MPClipTex);
>
>    type = pfGetTexFilter(text, PFTEX_MINFILTER);
>
>    if(type == PFTEX_POINT)
> 	cout << "--- Minfilter == POINT" << endl;
>    else if(type == PFTEX_TRILINEAR
> 	cout << "--- Minfilter == TRILINEAR" << endl;
>    else
> 	cout << "---Filter set to: << type << endl;
>
>
>    pfTexFilter(text,PFTEX_MINFILTER,PFTEX_MIPMAP_POINT);
>
>
>    type = pfGetTexFilter(text, PFTEX_MINFILTER);
>
>    if(type == PFTEX_POINT)
> 	cout << "--- Minfilter == POINT" << endl;
>    else if(type == PFTEX_TRILINEAR
> 	cout << "--- Minfilter == TRILINEAR" << endl;
>    else
> 	cout << "---Filter set to: << type << endl;
>
>    //This is always PFTEX_TRILINEAR!!!!
> }
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from Scott Brabson



-- 
________________________________________________________________
Rob Jenkins mailto:robj@sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 10 20:59:16 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA01947 for info-performer-dist@holodeck.engr.sgi.com; Fri, 10 Apr 1998 16:46:08 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA01920 for <info-performer@holodeck.engr.sgi.com>; Fri, 10 Apr 1998 16:45:57 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA10138618
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 10 Apr 1998 16:45:56 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA28201
	for <info-performer@sgi.com>; Fri, 10 Apr 1998 16:45:55 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id QAA13808 for <info-performer@sgi.com>; Fri, 10 Apr 1998 16:56:39 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id XAA10884 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Fri, 10 Apr 1998 23:46:40 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA01889 for info-performer@sgi.com; Fri, 10 Apr 1998 16:46:39 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804101646.ZM1887@logan.engr.multigen.com>
Date: Fri, 10 Apr 1998 16:46:39 -0700
In-Reply-To: "Glenn Waldron" <gwaldron@peril.com>
        "Re: Color?  .flt loader problem" (Apr 10,  8:24am)
References: <005701bd647b$eca911a0$0fedb526@killer.potomacinstitute.com>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: <info-performer@sgi.com>
Subject: Re: Color?  .flt loader problem
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 10,  8:24am, Glenn Waldron wrote:
>Liu Xiaoyan wrote:
>>Sorry, I didn't get what you mean. From the infomation of rld above, it
>>says that my program wants 'sgi2.4' while the DSO for .flt loader is
>>sgi3.0.
>
>This means your program was compiled with Performer 2.0, but you
>have the Performer 2.1 .flt loader.  So, you either need to compile
>under pf2.1, or get a .flt loader for pf2.0.  -g.

To be more specific, Liu is using Performer 2.0.4. The respective R15.4 flt
loader is built with a baseline compatibility wrt 2.0.2, so it'll report
"IVERSION sgi2.2". This should work fine with 2.0.[234] of Performer but not
2.0.[01].

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sat Apr 11 16:05:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA03751 for info-performer-dist@holodeck.engr.sgi.com; Sat, 11 Apr 1998 11:54:32 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA03724 for <info-performer@holodeck.engr.sgi.com>; Sat, 11 Apr 1998 11:54:31 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA10597520
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 11 Apr 1998 11:54:30 -0700 (PDT)
Received: from email.archlab.tuwien.ac.at (email.archlab.tuwien.ac.at [128.130.118.15]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA02375
	for <info-performer@sgi.com>; Sat, 11 Apr 1998 11:54:25 -0700 (PDT)
	mail_from (cwirawan@email.archlab.tuwien.ac.at)
Received: (from cwirawan@localhost)
	by email.archlab.tuwien.ac.at (8.8.8/8.8.8) id UAA17140;
	Sat, 11 Apr 1998 20:55:11 +0200 (MDT)
Date: Sat, 11 Apr 1998 20:55:10 +0200 (MDT)
From: Cahya Wirawan <cwirawan@email.archlab.tuwien.ac.at>
To: Harri Kaimio <harri.kaimio@yle.fi>
cc: info-performer@sgi.com
Subject: Re: Movie file as texture
In-Reply-To: <352CEB10.14CCA43D@yle.fi>
Message-ID: <Pine.SGI.3.91.980411204750.11328D-100000@email.archlab.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O



On Thu, 9 Apr 1998, Harri Kaimio wrote:

> Hi Performers!
> 
> This is not Performer specific, but I wonder if anyone has used a
> JPEG-compressed movie file as a texture map with the old compression
> library. This seems to be easy using dmbuffers, but my application must
> run on 6.2 and they were not available until 6.3 (I think)
> 
> What I have done: I have a separate thread in which I read the JPEG data
> and decompress it using Impact Compression card. I then load the
> uncompressed frames to texture map in draw callback (using
> pfTexture::subload). This works, but it CL uses the old IRIS GL pixel
> format XBGR (although it calls it RGBX!)
> 
> I tried to call
>   _texture->setFormat( PFTEX_INTERNAL_FORMAT, GL_ABGR_EXT );
> when I defined the texture, but I got only a blank texture. Is this the
> right way to set the texel format, or should I do something else? Also,
> is there a fill rate penalty when using GL_ABGR_EXT texel format
> compared to RGBX? I am already fill rate limited so this would be bad.
> 
> I would appreciate any ideas. What I really need is to display an
> 512x512 animated texture map (RGB, 8 bit per component) on High Impact.
> The animation has about 100 frames and must run 25 fps, so I guess that
> storing it uncompressed on disk or in memory is not possible.
> 

Hi, 

I have the same problem with movie texture in performer. it always use
XBGR although I used RGBX, but in my case I just need maximal 256x256
movietexture (RGB,8bit per component), so I just copied the imagebuffer
(from mvRenderMovieToImageBuffer) to imagetexture (convert RGBX to XBGR). 
The result is not so bad for this resolution, but for 512x512 is too slow
with my r10000 impact (reading the moviefile and copying to imagetexture
is in separate process too).

cahya wirawan

cwirawan@email.archlab.tuwien.ac.at

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 13 09:42:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA06800 for info-performer-dist@holodeck.engr.sgi.com; Mon, 13 Apr 1998 07:23:17 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA06774 for <info-performer@holodeck.engr.sgi.com>; Mon, 13 Apr 1998 07:23:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA9388978
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 13 Apr 1998 07:23:14 -0700 (PDT)
Received: from ldsa.com (ldsa.com [192.246.75.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA14792
	for <info-performer@sgi.com>; Mon, 13 Apr 1998 07:23:12 -0700 (PDT)
	mail_from (dheskamp@ldsa.com)
Received: by  ldsa.com (5.x/SMI-SVR4)
	id AA26656; Mon, 13 Apr 1998 10:16:50 -0400
Date: Mon, 13 Apr 1998 10:16:50 -0400
From: dheskamp@ldsa.com (Dave B. Heskamp)
Message-Id: <9804131416.AA26656@ ldsa.com>
Content-Type: text
Apparently-To: info-performer@sgi.com
Status: O

unsubscribe
unsubscribe

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 13 09:42:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA06868 for info-performer-dist@holodeck.engr.sgi.com; Mon, 13 Apr 1998 07:32:41 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA06841 for <info-performer@holodeck.engr.sgi.com>; Mon, 13 Apr 1998 07:32:40 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA10997476
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 13 Apr 1998 07:32:39 -0700 (PDT)
Received: from vista.taccsf.kirtland.af.mil (vista.taccsf.kirtland.af.mil [132.62.150.76]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA17308
	for <info-performer@sgi.com>; Mon, 13 Apr 1998 07:32:37 -0700 (PDT)
	mail_from (suzie@TACCSF.KIRTLAND.AF.MIL)
Received: by VISTA.TACCSF.KIRTLAND.AF.MIL with Internet Mail Service (5.5.1960.3)
	id <2VTD469G>; Mon, 13 Apr 1998 08:32:33 -0600
Message-ID: <214A87629D4FD111931F0060972989BA072E89@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: pfMemory Warning
Date: Mon, 13 Apr 1998 08:32:24 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD66E8.FEE1BEC0"
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD66E8.FEE1BEC0
Content-Type: text/plain

Hello, 

I'm getting a Warning from Perfly: 

  PF Warning/Usage(12):   pfMemory::new() Unable to allocate 32516 bytes
from the heap. 
  PF Warning/Resource:    pfCalloc() error. 
  PF Notice/Assert:       combineLODs() unable to process group (null). 

This happens when I load a .flt model with loader 14.2 on an R10000 O2
with a 6.3 OS.  The file itself was saved as a MultiGen 14.2 model, too.
My first thought was that it was too large to run (9.4MB), so I cut out
some polygons to get the size to about 7.5MB.   It still gave me the
warning, and dumped a core when I tried to run it.  I have another v14.0
.flt file that's 7.8MB, but I get no warnings or problems when I load
it.  So, I tried saving the problem .flt as a v14.0, but that didn't
help.  Then, I took all the subfaces out of the problem .flt file
thinking still that it's a size issue, but that didn't help either.
This is a third party database so I don't know exactly how it was built.
I'm thinking there's something in the file that's not built right, or
not compatible with the version of the loader I'm using.

I'm going to upgrade to Performer 2.2 with loader 15.4 this morning and
see if that helps.  But, until then, has anybody else seen this problem
and have a solution?  

Thanks,
Suzie

------ =_NextPart_001_01BD66E8.FEE1BEC0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>pfMemory Warning</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello, </FONT>
</P>

<P><FONT SIZE=3D2>I'm getting a Warning from Perfly: </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; PF Warning/Usage(12):&nbsp;&nbsp; =
pfMemory::new() Unable to allocate 32516 bytes from the heap. </FONT>
<BR><FONT SIZE=3D2>&nbsp; PF Warning/Resource:&nbsp;&nbsp;&nbsp; =
pfCalloc() error. </FONT>
<BR><FONT SIZE=3D2>&nbsp; PF =
Notice/Assert:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; combineLODs() unable =
to process group (null). </FONT>
</P>

<P><FONT SIZE=3D2>This happens when I load a .flt model with loader =
14.2 on an R10000 O2 with a 6.3 OS.&nbsp; The file itself was saved as =
a MultiGen 14.2 model, too.&nbsp; My first thought was that it was too =
large to run (9.4MB), so I cut out some polygons to get the size to =
about 7.5MB.&nbsp;&nbsp; It still gave me the warning, and dumped a =
core when I tried to run it.&nbsp; I have another v14.0 .flt file =
that's 7.8MB, but I get no warnings or problems when I load it.&nbsp; =
So, I tried saving the problem .flt as a v14.0, but that didn't =
help.&nbsp; Then, I took all the subfaces out of the problem .flt file =
thinking still that it's a size issue, but that didn't help =
either.&nbsp; This is a third party database so I don't know exactly =
how it was built.&nbsp; I'm thinking there's something in the file =
that's not built right, or not compatible with the version of the =
loader I'm using.</FONT></P>

<P><FONT SIZE=3D2>I'm going to upgrade to Performer 2.2 with loader =
15.4 this morning and see if that helps.&nbsp; But, until then, has =
anybody else seen this problem and have a solution?&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Suzie</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD66E8.FEE1BEC0--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 13 12:42:47 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA07702 for info-performer-dist@holodeck.engr.sgi.com; Mon, 13 Apr 1998 12:39:32 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA07675 for <info-performer@holodeck.engr.sgi.com>; Mon, 13 Apr 1998 12:39:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA11315858
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 13 Apr 1998 12:39:31 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA02028
	for <info-performer@sgi.com>; Mon, 13 Apr 1998 12:39:30 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id MAA21992 for <info-performer@sgi.com>; Mon, 13 Apr 1998 12:50:17 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id TAA03434 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Mon, 13 Apr 1998 19:40:19 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA05268 for info-performer@sgi.com; Mon, 13 Apr 1998 12:40:18 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804131240.ZM5266@logan.engr.multigen.com>
Date: Mon, 13 Apr 1998 12:40:18 -0700
In-Reply-To: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
        "pfMemory Warning" (Apr 13,  8:32am)
References: <214A87629D4FD111931F0060972989BA072E89@VISTA.TACCSF.KIRTLAND.AF.MIL>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: pfMemory Warning
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 13,  8:32am, Bemis, Suzie CEI-TACCSF wrote:
>PF Warning/Usage(12):   pfMemory::new() Unable to allocate 32516 bytes
>                          from the heap.
>PF Warning/Resource:    pfCalloc() error.
>PF Notice/Assert:       combineLODs() unable to process group (null).

The loader cannot optimize the LOD's in the scene graph because it is running
out of heap memory.

>This happens when I load a .flt model with loader 14.2 on an R10000 O2
>with a 6.3 OS.  The file itself was saved as a MultiGen 14.2 model, too.
>My first thought was that it was too large to run (9.4MB), so I cut out
>some polygons to get the size to about 7.5MB.

This sounds like a small file to me in either case. How memory does your O2
have?

>It still gave me the warning, and dumped a core when I tried to run it.

Was this before or after you edited the file?
Can you put the original file up for ftp so I can examine it?

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 13 21:43:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id VAA10144 for info-performer-dist@holodeck.engr.sgi.com; Mon, 13 Apr 1998 21:34:04 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id VAA10117 for <info-performer@holodeck.engr.sgi.com>; Mon, 13 Apr 1998 21:34:02 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id VAA11541019
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 13 Apr 1998 21:34:02 -0700 (PDT)
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.3.16]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id VAA21306
	for <info-performer@sgi.com>; Mon, 13 Apr 1998 21:33:59 -0700 (PDT)
	mail_from (wsherman@ncsa.uiuc.edu)
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.3.15])
	by ex1.ncsa.uiuc.edu (8.8.8/8.8.8) with ESMTP id XAA07857
	for <info-performer@sgi.com>; Mon, 13 Apr 1998 23:33:59 -0500 (CDT)
Received: from space.ncsa.uiuc.edu (space.ncsa.uiuc.edu [141.142.4.10])
	by mx1.ncsa.uiuc.edu (8.8.8/8.8.8) with ESMTP id XAA04298;
	Mon, 13 Apr 1998 23:33:58 -0500 (CDT)
From: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
Received: (from wsherman@localhost)
          by space.ncsa.uiuc.edu (8.8.4/8.8.4)
	  id XAA12186; Mon, 13 Apr 1998 23:35:05 -0500 (CDT)
Date: Mon, 13 Apr 1998 23:35:05 -0500 (CDT)
Message-Id: <199804140435.XAA12186@space.ncsa.uiuc.edu>
To: info-performer@sgi.com
Subject: Objects in strings
Cc: wsherman@ncsa.uiuc.edu
Status: O

Performers,

I have a couple of questions.  I'll include the easy one first.

In some Inventor programs I wrote a while back, I often included
ascii descriptions of simple objects directly in the executable,
stored as strings.  The MakeObject() function then converted the
Ascii-Inventor format into a node/graph.

I would like to be able to do this in Performer, but haven't
had any luck finding a similar function.

I found a function: pfdConvertFrom(), which given the arguments
in the man page I thought might be the answer.  But, after figuring
out that the man page had the arguments in the wrong order, I also
figured out that it wanted to convert an Inventor SceneGraph into
Performer, not an Inventor String.

Is there an easy way to do this?

And, thinking for the future, will this be possible in OpenGL++,
or whatever will come out next?  I thought it was a really handy
feature of Inventor.

	Thanks,
	Bill

/*************************************************************************/
/* Bill Sherman  (wsherman@ncsa.uiuc.edu)                                */
/* National Center for Supercomputing Applications                       */
/* University of Illinois at Urbana-Champaign                            */
/*     Og - "You want to do mankind a real service?  Tell funnier jokes" */
/*  Spinner - "but facts don't always reveal the truth"                  */
/*      Robin - "Yeah, but I always figure that's the writers' fault"    */
/*************************************************************************/

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 13 22:03:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id VAA10207 for info-performer-dist@holodeck.engr.sgi.com; Mon, 13 Apr 1998 21:54:34 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id VAA10180 for <info-performer@holodeck.engr.sgi.com>; Mon, 13 Apr 1998 21:54:33 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id VAA11368696
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 13 Apr 1998 21:54:32 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id VAA25435
	for <info-performer@sgi.com>; Mon, 13 Apr 1998 21:54:31 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id VAA11498700;
	Mon, 13 Apr 1998 21:54:31 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA02928; Mon, 13 Apr 1998 21:54:30 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3532EC06.4E3557FB@sgi.com>
Date: Mon, 13 Apr 1998 21:54:30 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
CC: info-performer@sgi.com
Subject: Re: Objects in strings
References: <199804140435.XAA12186@space.ncsa.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

William Sherman -Visualization wrote:
> 
> Performers,
> 
> I have a couple of questions.  I'll include the easy one first.
> 
> In some Inventor programs I wrote a while back, I often included
> ascii descriptions of simple objects directly in the executable,
> stored as strings.  The MakeObject() function then converted the
> Ascii-Inventor format into a node/graph.
> 
> I would like to be able to do this in Performer, but haven't
> had any luck finding a similar function.
> 
> I found a function: pfdConvertFrom(), which given the arguments
> in the man page I thought might be the answer.  But, after figuring
> out that the man page had the arguments in the wrong order, I also
> figured out that it wanted to convert an Inventor SceneGraph into
> Performer, not an Inventor String.
> 
> Is there an easy way to do this?

pfFont, pfString, pfText, pfdLoadFont.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 00:11:05 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA10660 for info-performer-dist@holodeck.engr.sgi.com; Mon, 13 Apr 1998 23:50:47 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id XAA10634 for <info-performer@holodeck.engr.sgi.com>; Mon, 13 Apr 1998 23:50:46 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA11637924
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 13 Apr 1998 23:50:45 -0700 (PDT)
Received: from chopin.kist.re.kr (chopin.kist.re.kr [161.122.61.25]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id XAA17412
	for <info-performer@sgi.com>; Mon, 13 Apr 1998 23:49:37 -0700 (PDT)
	mail_from (minam@chopin.kist.re.kr)
Received: from barber.kist.re.kr by chopin.kist.re.kr via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id QAA13493; Tue, 14 Apr 1998 16:02:00 +1000
Date: Tue, 14 Apr 1998 16:02:00 +1000
From: minam@chopin.kist.re.kr (Park Chang Hun)
Message-Id: <199804140602.QAA13493@chopin.kist.re.kr>
Apparently-To: <info-performer@holodeck.engr.sgi.com>
Status: O

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 01:34:39 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA11148 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 01:17:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id BAA11121 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 01:17:30 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id BAA9826758
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 01:17:30 -0700 (PDT)
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.3.16]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id BAA04035
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 01:17:29 -0700 (PDT)
	mail_from (wsherman@ncsa.uiuc.edu)
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.3.15])
	by ex1.ncsa.uiuc.edu (8.8.8/8.8.8) with ESMTP id DAA14000
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 03:17:28 -0500 (CDT)
Received: from space.ncsa.uiuc.edu (space.ncsa.uiuc.edu [141.142.4.10])
	by mx1.ncsa.uiuc.edu (8.8.8/8.8.8) with ESMTP id DAA11473;
	Tue, 14 Apr 1998 03:17:27 -0500 (CDT)
From: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
Received: (from wsherman@localhost)
          by space.ncsa.uiuc.edu (8.8.4/8.8.4)
	  id DAA13333; Tue, 14 Apr 1998 03:18:34 -0500 (CDT)
Date: Tue, 14 Apr 1998 03:18:34 -0500 (CDT)
Message-Id: <199804140818.DAA13333@space.ncsa.uiuc.edu>
To: info-performer@sgi.com
Subject: Rephrase:  Objects in strings
Cc: wsherman@ncsa.uiuc.edu
Status: O

> Performers,
> 
> I have a couple of questions.  I'll include the easy one first.

Okay, I blew the easy question by not being clear.

The gist of what I am looking for is not the ability to turn
strings into Performer objects, but to turn the objects described
by the strings into Performer objects.

> In some Inventor programs I wrote a while back, I often included
> ascii descriptions of simple objects directly in the executable,
> stored as strings.  The MakeObject() function then converted the
> Ascii-Inventor format into a node/graph.

For example (and I know I should have done this the first time),
if I want to make an object that consists of four cubes arranged
in a square in an alternating black and white sequence, I can
describe it in Inventor's ascii forat as:

static char *plumb_marker_str =
		"Separator {"
		"       Material { }"
		"       DEF plumb_translate Translation { }"
		"       Translation { translation       -0.5 -0.5 0.5 }"
		"       Cube { width 1  height 1  depth 1 }"
		"       Translation { translation       1 0 -1 }"
		"       Cube { width 1  height 1  depth 1 }"
		"       Material { diffuseColor 0 0 0 }"
		"       Translation { translation       0 0 1 }"
		"       Cube { width 1  height 1  depth 1 }"
		"       Translation { translation       -1 0 -1 }"
		"       Cube { width 1  height 1  depth 1 }"
		"}";

Now (in Inventor), if I want to make a node containing the
object described by this string, I do the following:

	SoSeparator     *in_graph;
	in_graph = MakeObject(plumb_marker_str);
	plumb_marker->addChild(in_graph);

> I would like to be able to do this in Performer, but haven't
> had any luck finding a similar function.
> 
> Is there an easy way to do this?
> 
> And, thinking for the future, will this be possible in OpenGL++,
> or whatever will come out next?  I thought it was a really handy
> feature of Inventor.

I hope this is a little clearer than my previous ambiguous phrasing.

	Thanks again,
	Bill

> /*************************************************************************/
> /* Bill Sherman  (wsherman@ncsa.uiuc.edu)                                */
> /* National Center for Supercomputing Applications                       */
> /* University of Illinois at Urbana-Champaign                            */
> /*     Og - "You want to do mankind a real service?  Tell funnier jokes" */
> /*  Spinner - "but facts don't always reveal the truth"                  */
> /*      Robin - "Yeah, but I always figure that's the writers' fault"    */
> /*************************************************************************/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 03:02:22 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA11428 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 02:42:08 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id CAA11387 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 02:42:02 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA11198255
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 02:41:57 -0700 (PDT)
Received: from aba.ihpc.nus.edu.sg (aba.ihpc.nus.edu.sg [137.132.15.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id CAA18250
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 02:41:52 -0700 (PDT)
	mail_from (liuxy@nsrc.nus.edu.sg)
Received: (from smap@localhost)
          by aba.ihpc.nus.edu.sg (8.8.5/8.8.4)
	  id RAA29760 for <info-performer@sgi.com>; Tue, 14 Apr 1998 17:41:47 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma029752; Tue Apr 14 17:41:17 1998
Message-ID: <35332F78.3C36@nsrc.nus.edu.sg>
Date: Tue, 14 Apr 1998 17:42:16 +0800
From: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Organization: National Supercomputing Research Center
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: change of email address & JOB opp
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

Would you please change my email address to liuxy@ihpc.nus.edu.sg

Upon our merge with another research center to form the Institute of
High Performance Computing, Singapore on Apr.1st, there are many job 
positions. Please visit our website at:www.ihpc.nus.edu.sg.

***********************************************************************
Liu Xiaoyan                 National Supercomputing Research Center
Data Visualization Group    http://www.nsrc.nus.edu.sg Tel:(65)7709267
***********************************************************************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 03:59:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA11605 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 03:42:23 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id DAA11578 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 03:42:16 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id DAA11603563
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 03:42:02 -0700 (PDT)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id DAA00805
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 03:41:58 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id MAA29687; Tue, 14 Apr 1998 12:50:34 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma029640; Tue, 14 Apr 98 12:50:24 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id MAA00910;
	Tue, 14 Apr 1998 12:41:34 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804141041.MAA00910@s00sn1.fel.tno.nl>
Subject: Re: Rephrase:  Objects in strings
To: wsherman@ncsa.uiuc.edu (William Sherman -Visualization)
Date: Tue, 14 Apr 1998 12:41:34 +0200 (MET DST)
Cc: info-performer@sgi.com
In-Reply-To: <199804140818.DAA13333@space.ncsa.uiuc.edu> from "William Sherman -Visualization" at Apr 14, 98 03:18:34 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> 
> > Performers,
> > 
> > I have a couple of questions.  I'll include the easy one first.
> 
> Okay, I blew the easy question by not being clear.
> 
> The gist of what I am looking for is not the ability to turn
> strings into Performer objects, but to turn the objects described
> by the strings into Performer objects.
> 
> > In some Inventor programs I wrote a while back, I often included
> > ascii descriptions of simple objects directly in the executable,
> > stored as strings.  The MakeObject() function then converted the
> > Ascii-Inventor format into a node/graph.
> 
> For example (and I know I should have done this the first time),
> if I want to make an object that consists of four cubes arranged
> in a square in an alternating black and white sequence, I can
> describe it in Inventor's ascii forat as:
> 
> static char *plumb_marker_str =
> 		"Separator {"
> 		"       Material { }"
> 		"       DEF plumb_translate Translation { }"
> 		"       Translation { translation       -0.5 -0.5 0.5 }"
> 		"       Cube { width 1  height 1  depth 1 }"
> 		"       Translation { translation       1 0 -1 }"
> 		"       Cube { width 1  height 1  depth 1 }"
> 		"       Material { diffuseColor 0 0 0 }"
> 		"       Translation { translation       0 0 1 }"
> 		"       Cube { width 1  height 1  depth 1 }"
> 		"       Translation { translation       -1 0 -1 }"
> 		"       Cube { width 1  height 1  depth 1 }"
> 		"}";
> 
> Now (in Inventor), if I want to make a node containing the
> object described by this string, I do the following:
> 
> 	SoSeparator     *in_graph;
> 	in_graph = MakeObject(plumb_marker_str);
> 	plumb_marker->addChild(in_graph);
> 
> > I would like to be able to do this in Performer, but haven't
> > had any luck finding a similar function.
> > 
> > Is there an easy way to do this?
> > 
> > And, thinking for the future, will this be possible in OpenGL++,
> > or whatever will come out next?  I thought it was a really handy
> > feature of Inventor.
> 
> I hope this is a little clearer than my previous ambiguous phrasing.
> 
> 	Thanks again,
> 	Bill

You can take a look at the Inventeor loader that comes with performer.
What it does is use Inventor to load the .iv file and then traverses
the inventor scene graph and converts it to Performer. So you can use
the inventor calls to set up a scene graph and use a function from the
performer-inventor loader to make it into a Performer tree.

Mario
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 05:52:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA11848 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 05:28:54 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA11821 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 05:28:47 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA11423399
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 05:28:16 -0700 (PDT)
Received: from sgonyx.ita.es ([193.144.229.14]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA18422
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 05:25:52 -0700 (PDT)
	mail_from (abadia@sgonyx.ita.es)
Received: (from abadia@localhost)
	by sgonyx.ita.es (8.8.8/8.8.8) id OAA25307
	for info-performer@sgi.com; Tue, 14 Apr 1998 14:25:26 +0200 (DST)
From: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>
Message-Id: <9804141425.ZM25305@pandora.ita.es>
Date: Tue, 14 Apr 1998 14:25:26 +0000
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: pfSCS and normals
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hello:

How do pfSCS (scaling) affect normals ?

I have been doing some tests and I have found that Normals suffer
the same transformation than Vertices. This leads to incorrect
illumination when using a non-uniform scaling matrix.

Is there a way to apply one scaling matrix to vertices and
another to normals ?

Any suggestions to solve this inconvenience?

Perhaps manual rescaling (i.e. multiplying each vertex
by a Matrix, and its Normal by another) during load phase?

I want to speed object loading up, because I am doing dynamic
database management.

Thanks!

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 06:33:52 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA11962 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 06:12:35 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA11935 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 06:12:33 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA11483988
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 06:12:33 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA28773
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 06:12:31 -0700 (PDT)
	mail_from (dwilliams@sarnoff.com)
Received: from pike ([130.33.96.3]) by postoffice.sarnoff.com
          (Netscape Messaging Server 3.5)  with SMTP id AAA179C;
          Tue, 14 Apr 1998 09:12:25 -0400
Sender: dcw@sarnoff.com
Message-ID: <35335F5E.41C6@sarnoff.com>
Date: Tue, 14 Apr 1998 09:06:38 -0400
From: Daniel Williams <dwilliams@sarnoff.com>
Organization: Systems & Scientific Software
X-Mailer: Mozilla 3.04GoldC-SGI (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
CC: wsherman@ncsa.uiuc.edu
Subject: Re: Rephrase:  Objects in strings
References: <199804140818.DAA13333@space.ncsa.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

William Sherman wrote:
> 
> The gist of what I am looking for is not the ability to turn
> strings into Performer objects, but to turn the objects described
> by the strings into Performer objects.
> 

    pfdResetBldrGeometry ();
    pfdResetBldrState ();

    SoInteraction::init ();

    SoInput in;
    in.setBuffer (your_string, strlen (your_string));
    SoSeparator* root = SoDB::readAll (&in);
    if (root) {
        root->ref ();
        //
        // manual page has signature wrong
        //
        pfNode* scene_graph = pfdConvertFrom (root, ".iv");
        root->unref ();
        return (scene_graph);
    }
    else
        return (NULL);

--
Daniel Williams, Systems & Scientific Software
Voice: (215) 885-1573 Email: sass@acm.com
Independent Consultant to: Sarnoff Corporation
Voice: (609) 734-2153 Email: dwilliams@sarnoff.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 08:11:59 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA12233 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 08:03:23 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA12206 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 08:03:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA11763115
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 08:03:17 -0700 (PDT)
Received: from news.irisa.fr (news.irisa.fr [131.254.254.15]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id IAA03705
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 08:03:15 -0700 (PDT)
	mail_from (news@news.irisa.fr)
Received: (from news@localhost)
	by news.irisa.fr (8.8.7/8.8.7) id RAA04693;
	Tue, 14 Apr 1998 17:03:11 +0200 (MET DST)
To: info-performer@sgi.com
Path: not-for-mail
From: Alain Chauffaut <Alain.Chauffaut@irisa.fr>
Newsgroups: irisa.listes.info-performer
Subject: rear-view mirror
Date: Tue, 14 Apr 1998 17:03:10 +0200
Organization: Irisa, Rennes (FR)
Lines: 12
Message-ID: <35337AAE.2F2@irisa.fr>
NNTP-Posting-Host: discus.irisa.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Mailer: Mozilla 3.04Gold (X11; I; SunOS 5.5 sun4m)
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by cthulhu.engr.sgi.com id IAA9862149
Status: O

Hello,

I would like to simulate a rear-view mirror with Performer.
Could somebody send me an example of this programmation=20
with the C++ API?

Thank you very much.

--=20
Alain CHAUFFAUT Tel: 02 99 84 72 63 email: Alain.Chauffaut@irisa.fr=20
IRISA/INRIA de Rennes Fax: 02 99 84 71 71 web: http://www.irisa.fr/
"Je m'exprime =E0 titre personnel,et n'engage ni l'Irisa, ni l'Inria"
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 09:39:21 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA12519 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 09:17:34 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA12492 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 09:17:31 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA9946777
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 09:17:30 -0700 (PDT)
Received: from archimedes.vislab.navy.mil (archimedes.chinalake.navy.mil [129.131.31.8]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA04199
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 09:17:28 -0700 (PDT)
	mail_from (jan@archimedes.vislab.navy.mil)
Received: (jan@localhost) by archimedes.vislab.navy.mil (8.7.5/8.x-CL-SOS5.3) id JAA27327 for info-performer@sgi.com; Tue, 14 Apr 1998 09:26:14 -0700 (PDT)
From: Jan Barglowski <jan@archimedes.vislab.navy.mil>
Posted-Date: Tue, 14 Apr 1998 09:26:14 -0700 (PDT)
Message-Id: <199804141626.JAA27327@archimedes.vislab.navy.mil>
Subject: Master/Slave MPClipTextures...
To: info-performer@sgi.com
Date: Tue, 14 Apr 1998 09:26:14 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL24 ME8b]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

Performers:

I have a 3-pipe App using a cliptexture on the terrain.  I've replaced
the clip-center algorithm with my own, but it affects the centering
on all 3 pipes the way I want it to affect only the center pipe.
According to the pfManual, I can "split" the MPCliptextures into 
Master and Slave cliptextures, which share varying degrees of system
resources with each other.  I'd like to use this, but can't seem to
grasp how I should go about it!

First, I only have one pfMPClipTexture -- at least I've only defined
one!  I'm guessing all the pipes share this one from the pfuAddMPClip-
TexturesToPipes() function.  So how can I split off slave MPClipTextures?

I've already tried to use the pfMPClipTexture::setShareMask(0) to 
signify no sharing of the centering, but that doesn't seem to work, 
either.  Interesting that the man page states that only clipcenter
sharing can be enabled/disabled...

If it aids, what I'm doing is shifting the clip center so that it
coincides with the "bottom" of my current FOV.  This has the result
of putting higher res mip-levels (or at least loading them!) so 
that is appears sharper where I'm looking, rather than directly 
underneath me.  Of course, this depends on the channel's viewmat
so I must update the clipcenter based on each channel (I have one
channel per pipe).  Unfortunately, the sharing causes me only to 
set the clipcenter for the center channel, and the other two channels
are getting it's center.

Any hints?  Thanks!

jan

-- 
Jan Anthony Barglowski	              jan@chinalake.navy.mil
Real-time Computer Graphics           http://www1.ridgecrest.ca.us/~jan
Naval Air Warfare Center, China Lake  (760) 927-1057
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 11:10:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA12764 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 10:50:57 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA12738 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 10:50:56 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA11791180
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 10:50:56 -0700 (PDT)
Received: from hydrogen.inbe.net (hydrogen.inbe.net [194.7.1.8]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA27125
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 10:50:52 -0700 (PDT)
	mail_from (dui@dui.be)
Received: from LEXINGTON (Seb@lexington.dui.be [194.7.233.81])
	by hydrogen.inbe.net (8.8.5/8.8.5) with SMTP id TAA06853
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 19:50:49 +0200 (MET DST)
Message-Id: <199804141750.TAA06853@hydrogen.inbe.net>
From: "DUI Sebastien" <dui@dui.be>
To: <info-performer@sgi.com>
Date: Tue, 14 Apr 1998 19:50:47 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by cthulhu.engr.sgi.com id KAA9802324
Status: O

Hi,

Does anyone know if it is possible to launch midi from performer ? I need=
 to
generate some sounds so I need to connect a sampler to it ...
It will run on an Onyx2 (try to run)
Thanks,


DUI S=E9bastien
Manager of DUI Web sprl
Rue du coucou 2b
6040 Jumet
E-mail dui@dui.be
Tel +32 71 701612
Fax +32 71 327725

The death is not a tragedy it is only a step ... Let's DUI Web help you t=
o
cross the gate of the life on earth ...

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 12:16:26 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA13201 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 11:58:39 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA13174 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 11:58:38 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA11808725
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 11:58:37 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA03678
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 11:58:36 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA6972449;
	Tue, 14 Apr 1998 11:58:31 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA01861; Tue, 14 Apr 1998 11:58:31 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3533B1D7.347FD34C@sgi.com>
Date: Tue, 14 Apr 1998 11:58:31 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
CC: info-performer@sgi.com
Subject: Re: Rephrase:  Objects in strings
References: <199804140818.DAA13333@space.ncsa.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

William Sherman -Visualization wrote:
> 
> > Performers,
> >
> > I have a couple of questions.  I'll include the easy one first.
> 
> Okay, I blew the easy question by not being clear.
> 
> The gist of what I am looking for is not the ability to turn
> strings into Performer objects, but to turn the objects described
> by the strings into Performer objects.
> 
> > In some Inventor programs I wrote a while back, I often included
> > ascii descriptions of simple objects directly in the executable,
> > stored as strings.  The MakeObject() function then converted the
> > Ascii-Inventor format into a node/graph.
> 
> For example (and I know I should have done this the first time),
> if I want to make an object that consists of four cubes arranged
> in a square in an alternating black and white sequence, I can
> describe it in Inventor's ascii forat as:
> 
> static char *plumb_marker_str =
>                 "Separator {"
>                 "       Material { }"
>                 "       DEF plumb_translate Translation { }"
>                 "       Translation { translation       -0.5 -0.5 0.5 }"
>                 "       Cube { width 1  height 1  depth 1 }"
>                 "       Translation { translation       1 0 -1 }"
>                 "       Cube { width 1  height 1  depth 1 }"
>                 "       Material { diffuseColor 0 0 0 }"
>                 "       Translation { translation       0 0 1 }"
>                 "       Cube { width 1  height 1  depth 1 }"
>                 "       Translation { translation       -1 0 -1 }"
>                 "       Cube { width 1  height 1  depth 1 }"
>                 "}";
> 
> Now (in Inventor), if I want to make a node containing the
> object described by this string, I do the following:
> 
>         SoSeparator     *in_graph;
>         in_graph = MakeObject(plumb_marker_str);
>         plumb_marker->addChild(in_graph);
> 
> > I would like to be able to do this in Performer, but haven't
> > had any luck finding a similar function.
> >
> > Is there an easy way to do this?
> >
> > And, thinking for the future, will this be possible in OpenGL++,
> > or whatever will come out next?  I thought it was a really handy
> > feature of Inventor.
> 
> I hope this is a little clearer than my previous ambiguous phrasing.
> 

Performer has no equivalent of inventors ascii file format, and only
recently aquired the .pfb format for fast file loading.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 13:05:24 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA13614 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 12:44:12 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA13587 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 12:44:12 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA11912327
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 12:44:11 -0700 (PDT)
Received: from precious.engr.sgi.com ([198.29.106.95]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA21795; Tue, 14 Apr 1998 12:44:10 -0700 (PDT)
	mail_from (nemec@precious.engr.sgi.com)
Received: (from nemec@localhost) by precious.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) id MAA15613; Tue, 14 Apr 1998 12:44:08 -0700 (PDT)
From: "Philip Nemec" <nemec@sgi.com>
Message-Id: <9804141244.ZM15608@sgi.com>
Date: Tue, 14 Apr 1998 12:44:08 -0700
In-Reply-To: Angus Dorbie <dorbie@sgi.com>
        "Re: Rephrase:  Objects in strings" (Apr 14, 11:58am)
References: <199804140818.DAA13333@space.ncsa.uiuc.edu> 
	<3533B1D7.347FD34C@sgi.com>
X-Face: 9V,ca#lqwc0*+J=1BTFu},dPQHvu3exYYjzxg#m+_}Zr5F5%s~n|R(KK
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Angus Dorbie <dorbie@sgi.com>,
        William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
Subject: Re: Rephrase:  Objects in strings
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Well there is actually a .pfa (Performer ASCII) format to accompany the .pfb
(Performer binary) format...  It isn't as easy to read as .iv though...
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 13:20:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA13721 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 13:01:14 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA13694 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 13:01:12 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA11881489
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 13:01:11 -0700 (PDT)
Received: from spiffy.paradigmsim.com (spiffy.paradigmsim.com [206.7.114.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA28802
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 13:01:05 -0700 (PDT)
	mail_from (db@ParadigmSim.com)
Received: from db.paradigmsim.com by spiffy.paradigmsim.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id OAA11810; Tue, 14 Apr 1998 14:54:31 -0500
Message-ID: <3533C0CD.5A50@ParadigmSim.com>
Date: Tue, 14 Apr 1998 15:02:21 -0500
From: Dan Brockway <db@ParadigmSim.com>
Reply-To: db@ParadigmSim.com
Organization: Paradigm Simulation Inc.
X-Mailer: Mozilla 3.01 (Win95; I)
MIME-Version: 1.0
To: lwillis@inreach.com
CC: info-performer@sgi.com
Subject: Re: Constructing pfASD
References: <199803282004.MAA12593@mail.inreach.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Lee Willis wrote:
> 
> Thom DeCarlo wrote:
> >Lee Willis wrote:
> >>
> >> >From: Jonas Andersson <jonasa@cs.umu.se>
> >> >To: info-performer@sgi.com
> >> >Subject: Constructing pfASD
> >> >Date: Friday, March 27, 1998 1:52 AM
> >>
> [snip]
... snip ...
> 
> >It becomes something to be _avoided_! Our
> >applications need to ingest sub-meter elevation post spaced data and we
> >want to smoothly reduce resolution as the viewer moves away from the
> >terrain. This seems to be exactly the opposite of the situation you
> >describe.
> 
> So far I don't understand what the problem is.   The Multigen CAT
> implementation
> of ASD does just that, picks out the most significant points for each LOD,
> working
> from coarsest to finest, injecting new points to each LOD to better
> approximate the
> surface.

If, on the other hand, you have a specific terrain surface at the
highest LOD that correlates with other databases, then MultiGen's CAT is
of no value.

Dan

>
> >> ------------------------------
> >> Lee Willis                        Virtual Landscape Dermatologist
> >>
> >> lwillis@terrex.com           TERREX
> >>
> 
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com

-- 
Dan Brockway                          voice: (972) 960-2301
Paradigm Simulation Inc.              fax:   (972) 960-2303
14900 Landmark Blvd., Suite 400       mailto:db@ParadigmSim.com
Dallas TX 75240                       http://www.ParadigmSim.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 13:32:05 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA13767 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 13:11:31 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA13740 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 13:11:29 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA11946506
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 13:11:28 -0700 (PDT)
Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA03899
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 13:11:26 -0700 (PDT)
	mail_from (mayer@poster.cae.ca)
Received: tid OAA17465; Tue, 14 Apr 1998 14:42:50 -0400
Received: from [142.39.41.10] by poster.cae.ca (AIX 3.2/UCB 5.64/4.03)
          id AA29120; Tue, 14 Apr 1998 14:37:44 -0400
Received: from christine.cae.ca by christine.cae.ca via SMTP (950413.SGI.8.6.12/930416.SGI)
	for <info-performer@sgi.com> id OAA04564; Tue, 14 Apr 1998 14:42:00 -0400
Sender: mayer@poster.cae.ca
Message-Id: <3533ADF5.446B@cae.ca>
Date: Tue, 14 Apr 1998 14:41:57 -0400
From: Sylvain Mayer <mayer@poster.cae.ca>
Organization: CAE Electronics Ltd
X-Mailer: Mozilla 3.01SC-SGI (X11; I; IRIX 6.2 IP22)
Mime-Version: 1.0
To: info-performer@sgi.com
Subject: Re: rear-view mirror
References: <35337AAE.2F2@irisa.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Alain Chauffaut wrote:
> 
> Hello,
> 
> I would like to simulate a rear-view mirror with Performer.
> 

Hi,

all you need to do is create a new channel with different parameters
from your main channel (the rear channel can be attached to your main
channel and they will share attributes like scene and so on).  They have
to have different viewport and of course you want to have an offset to
look behind.

This should be something like your starting point:

// create both channels
chans[MAIN_CHANNEL] = new pfChannel(pipe);
chans[REAR_CHANNEL] = new pfChannel(pipe);
chans[MAIN_CHANNEL]->attach(chans[REAR_CHANNEL]);

// you don't want to share the view
uint share = chans[MAIN_CHANNEL]->getShare();
share &= ~PFCHAN_VIEW;
chans[MAIN_CHANNEL]->setShare(share);

// attach the scene only to the first channel
chans[MAIN_CHANNEL]->setScene(scene);

// rear channel will look behind and be drawn in the upper right corner
offset.xyz.set(0.0f, 0.0f, 0.0f);
offset.hpr.set(180.0f, 0.0f, 0.0f);
chans[REAR_CHANNEL]->setViewOffsets(offset.xyz, offset.hpr);
chans[REAR_CHANNEL]->setViewport(0.65f, 1.0f, 0.65f, 1.0f);

-- 

Sylvain Mayer, 3D Graphics Developer
Visual Database Tools
CAE Electronics Ltd. (http://www.cae.ca)
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 14:02:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA14092 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 13:44:34 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA14065 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 13:44:28 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA11895650
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 13:44:28 -0700 (PDT)
Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA17587
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 13:44:25 -0700 (PDT)
	mail_from (rejeanc@cae.ca)
Received: from itemsd.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03)
          id AA07328; Tue, 14 Apr 1998 15:19:45 -0400
Received: by itemsd.cae.ca (951211.SGI.8.6.12.PATCH1502/930416.SGI)
	for info-performer@sgi.com id NAA17673; Mon, 13 Apr 1998 13:56:48 -0400
From: "Rejean Chartrand" <rejeanc@cae.ca>
Message-Id: <9804131356.ZM17671@itemsd.cae.ca>
Date: Mon, 13 Apr 1998 13:56:47 -0400
X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail)
To: info-performer@sgi.com
Subject: Loading of Costumized OpenFlight files ...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi,

   I would like to know how the OpenFlight loader deals with files that
contains customized beads. Through the MultiGen Data API, new type of beads
can be created and existing ones can be enhanced, defining this way a new
data dictionary.

   I was told that the OpenFlight loader does not use the MultiGen Data API, so
how does it know about new bead types and specially how to interpret them (does
it throw them out or what) ?

Thanks in advance !

Rejean Chartrand.
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 14:02:25 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA14130 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 13:47:32 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA14103 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 13:47:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA11936129
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 13:47:32 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id NAA18934
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 13:47:31 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA11666684;
	Tue, 14 Apr 1998 13:47:30 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA04005; Tue, 14 Apr 1998 13:47:30 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3533CB61.A4E3C999@sgi.com>
Date: Tue, 14 Apr 1998 13:47:29 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Javier Abadia Miranda <abadia@sgonyx.ita.es>
CC: info-performer@sgi.com
Subject: Re: pfSCS and normals
References: <9804141425.ZM25305@pandora.ita.es>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Javier Abadia Miranda wrote:
> 
> Hello:
> 
> How do pfSCS (scaling) affect normals ?
> 
> I have been doing some tests and I have found that Normals suffer
> the same transformation than Vertices. This leads to incorrect
> illumination when using a non-uniform scaling matrix.
> 
> Is there a way to apply one scaling matrix to vertices and
> another to normals ?
> 
> Any suggestions to solve this inconvenience?
> 
> Perhaps manual rescaling (i.e. multiplying each vertex
> by a Matrix, and its Normal by another) during load phase?
> 
> I want to speed object loading up, because I am doing dynamic
> database management.
> 
> Thanks!

The transformation is correct for lighting purposes but for
this to work normals are treated differently. If you scale a
sphere to be an almost flat elipsoid then rather than also
scaling the normals to be flat they should infact scale to
remain perpendicular to the surface. This is a different
transformation. It is the inverse matrix which is used to
transform the normal vector.

To avoid this you'd have to traverse your geoset data manually
and apply the desired transformation to the attributes.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 15:44:22 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA14686 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 15:21:47 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA14659 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 15:21:46 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA11904430
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 15:21:45 -0700 (PDT)
Received: from mail.inreach.com (mail.inreach.com [209.142.0.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA28245
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 15:21:44 -0700 (PDT)
	mail_from (lwillis@inreach.com)
Received: from get (209-142-17-171.oak.inreach.net [209.142.17.171]) by mail.inreach.com (8.8.8/8.8.6/(InReach)) with ESMTP id PAA23356; Tue, 14 Apr 1998 15:17:19 -0700 (PDT)
Message-Id: <199804142217.PAA23356@mail.inreach.com>
Reply-To: <lwillis@inreach.com>
From: "Lee Willis" <lwillis@inreach.com>
To: <db@ParadigmSim.com>
Cc: <info-performer@sgi.com>
Subject: Re: Constructing pfASD
Date: Tue, 14 Apr 1998 15:17:03 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1162
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Status: O

----------
> From: Dan Brockway <db@ParadigmSim.com>
> Lee Willis wrote:

> > So far I don't understand what the problem is.   The Multigen CAT
> > implementation
> > of ASD does just that, picks out the most significant points for each
LOD,
> > working
> > from coarsest to finest, injecting new points to each LOD to better
> > approximate the
> > surface.
> 
> If, on the other hand, you have a specific terrain surface at the
> highest LOD that correlates with other databases, then MultiGen's CAT is
> of no value.

No argument.  But the problem goes deeper than that.  
If you have a specific terrain surface at the highest LOD 
that correlates with other databases, ***ASD*** is of no value.
(unless you're database happens to be a regular grid)

You cannot construct an ASD from an arbitrary triangular mesh.  
It just aint doable.  

------------------------------
Lee Willis                        Virtual Landscape Dermatologist          
      
lwillis@terrex.com           TERREX


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 16:09:32 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA14891 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 16:03:29 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA14864 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 16:03:28 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA10993386
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 16:03:28 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA15415
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 16:03:24 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id QAA02413 for <info-performer@sgi.com>; Tue, 14 Apr 1998 16:14:11 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id XAA03976 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Tue, 14 Apr 1998 23:04:14 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA03662 for info-performer@sgi.com; Tue, 14 Apr 1998 16:04:13 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804141604.ZM3660@logan.engr.multigen.com>
Date: Tue, 14 Apr 1998 16:04:13 -0700
In-Reply-To: "Rejean Chartrand" <rejeanc@cae.ca>
        "Loading of Costumized OpenFlight files ..." (Apr 13,  1:56pm)
References: <9804131356.ZM17671@itemsd.cae.ca>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Re: Loading of Costumized OpenFlight files ...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 13,  1:56pm, Rejean Chartrand wrote:
>I would like to know how the OpenFlight loader deals with files that
>contains customized beads.

It skips extension records, just as it skips any other records it doesn't
process.

>I was told that the OpenFlight loader does not use the MultiGen Data API,

Correct. The loader is a separate code base that has been codeveloped and
shared between SGI and MGI since before Performer 1.0.

>so how does it know about new bead types and specially how to interpret them
>(does it throw them out or what) ?

It currently "throws them out" as you say.

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 16:09:32 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA14845 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 16:00:09 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA14818 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 16:00:08 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA10767517
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 16:00:07 -0700 (PDT)
Received: from mhub3.tc.umn.edu (mhub3.tc.umn.edu [128.101.131.53]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA13711
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 16:00:04 -0700 (PDT)
	mail_from (klinge@reality.psych.umn.edu)
Received: from reality.psych.umn.edu by mhub3.tc.umn.edu; Tue, 14 Apr 98 18:00:02 -0500
From: James Klinge <klinge@reality.psych.umn.edu>
Message-Id: <199804142255.RAA11745@reality.psych.umn.edu>
Received: by reality.psych.umn.edu; Tue, 14 Apr 1998 17:55:58 -0500
Subject: pfdLoadFile trouble
To: info-performer@sgi.com
Date: Tue, 14 Apr 1998 17:55:58 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Status: O

I just installed 2.2 and am having trouble loading files of type
.medit or .rxs.  I originally got messages that said I needed a newer
version of libMedit, so I built the latest versions and now I get this:

=> warn  pfdLoadFile() - Unable to load file /usr2/simulations/models/misc/isuzu.medit because of problem finding pfdLoadFile_medit

I compiled and placed libpfmedit_ogl.so in /usr/lib/libpfdb and also
made an N32 version and put it in /usr/lib32/libpfdb

I cp'ed these files to libpfmedit.so in both of those directories, too.

nm libpfmedit_ogl.so | grep pfdLoadFile_medit
shows that this function is in fact in this file.  How do I get a
working loader for Medit or .rxs for perf 2.2?

Thanks,
Jim.
-- 
James Klinge    klinge@reality.psych.umn.edu  -  Human Factors Research Lab 
voice:(612)626-7521   fax:(612)625-8867       -  University of Minnesota
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 16:09:32 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA14789 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 15:56:46 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA14762 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 15:56:45 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA11379249
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 15:56:45 -0700 (PDT)
Received: from hell.engr.sgi.com ([150.166.37.67]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id PAA12480
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 15:56:44 -0700 (PDT)
	mail_from (hatch@hell.engr.sgi.com)
Received: (from hatch@localhost) by hell.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA10471; Tue, 14 Apr 1998 15:56:28 -0700
Date: Tue, 14 Apr 1998 15:56:28 -0700
From: hatch@hell.engr.sgi.com (Don Hatch)
Message-Id: <9804141556.ZM10469@hell.engr.sgi.com>
In-Reply-To: Jan Barglowski <jan@archimedes.vislab.navy.mil>
        "Master/Slave MPClipTextures..." (Apr 14,  9:26am)
References: <199804141626.JAA27327@archimedes.vislab.navy.mil>
X-Face: /7QDEc=iPrsQG=j>iQo4F||T'ys-t--1bb9IJ9qo~4|i0nB|OG%gK}I3J2{/u*-q.I8=OSv/&K}V(pw:~5aIV!Y4:y+Vk#AAX)|i'B-jHf+r(?U'"B'9"D|<-(/1PD32tUN
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Jan Barglowski <jan@archimedes.vislab.navy.mil>, info-performer@sgi.com
Subject: Re: Master/Slave MPClipTextures...
Cc: tomcat@hell.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 14,  9:26am, Jan Barglowski wrote:
> Subject: Master/Slave MPClipTextures...
> Performers:
> 
> I have a 3-pipe App using a cliptexture on the terrain.  I've replaced
> the clip-center algorithm with my own, but it affects the centering
> on all 3 pipes the way I want it to affect only the center pipe.
> According to the pfManual, I can "split" the MPCliptextures into 
> Master and Slave cliptextures, which share varying degrees of system
> resources with each other.  I'd like to use this, but can't seem to
> grasp how I should go about it!
> 
> First, I only have one pfMPClipTexture -- at least I've only defined
> one!  I'm guessing all the pipes share this one from the pfuAddMPClip-
> TexturesToPipes() function.  So how can I split off slave MPClipTextures?
> 
> I've already tried to use the pfMPClipTexture::setShareMask(0) to 
> signify no sharing of the centering, but that doesn't seem to work, 
> either.  Interesting that the man page states that only clipcenter
> sharing can be enabled/disabled...
> 
> If it aids, what I'm doing is shifting the clip center so that it
> coincides with the "bottom" of my current FOV.  This has the result
> of putting higher res mip-levels (or at least loading them!) so 
> that is appears sharper where I'm looking, rather than directly 
> underneath me.  Of course, this depends on the channel's viewmat
> so I must update the clipcenter based on each channel (I have one
> channel per pipe).  Unfortunately, the sharing causes me only to 
> set the clipcenter for the center channel, and the other two channels
> are getting it's center.
> 
> Any hints?  Thanks!
> 
> jan

Sorry, you gotta have the same clip center on all pipes.
Theoretically OpenGL and the hardware is capable of supporting
independent centers (the different pipes' textures are independent
OpenGL objects in independent OpenGL contexts)
but the way it's implemented in Performer
is that they all share the same memory caching structures
(pfImageCaches and pfImageTiles)
and the pfImageCache structure is not smart enough to maintain coverage of
more than one rectangular texture region at once, which is what you would need.

You *might* be able to hack around this by actually defining
three independent clip textures that don't know about each other;
this will probably triple your memory usage as well
as your required disk bandwidth (if it works at all).

Don

-- 
Don Hatch  hatch@sgi.com  (415) 933-5150  Silicon Graphics, Inc.
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 17:00:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA15546 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 16:39:52 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA15519 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 16:39:52 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA11309666
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 16:39:51 -0700 (PDT)
Received: from hell.engr.sgi.com ([150.166.37.67]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA01203
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 16:39:50 -0700 (PDT)
	mail_from (hatch@hell.engr.sgi.com)
Received: (from hatch@localhost) by hell.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA10770; Tue, 14 Apr 1998 16:39:34 -0700
Date: Tue, 14 Apr 1998 16:39:34 -0700
From: hatch@hell.engr.sgi.com (Don Hatch)
Message-Id: <9804141639.ZM10768@hell.engr.sgi.com>
In-Reply-To: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>
        "pfSCS and normals" (Apr 14,  2:25pm)
References: <9804141425.ZM25305@pandora.ita.es>
X-Face: /7QDEc=iPrsQG=j>iQo4F||T'ys-t--1bb9IJ9qo~4|i0nB|OG%gK}I3J2{/u*-q.I8=OSv/&K}V(pw:~5aIV!Y4:y+Vk#AAX)|i'B-jHf+r(?U'"B'9"D|<-(/1PD32tUN
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>, info-performer@sgi.com
Subject: Re: pfSCS and normals
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 14,  2:25pm, Javier Abadia Miranda wrote:
> Subject: pfSCS and normals
> Hello:
> 
> How do pfSCS (scaling) affect normals ?
> 
> I have been doing some tests and I have found that Normals suffer
> the same transformation than Vertices. This leads to incorrect
> illumination when using a non-uniform scaling matrix.
> 
> Is there a way to apply one scaling matrix to vertices and
> another to normals ?
> 
> Any suggestions to solve this inconvenience?

OpenGL properly transforms the normals by the transpose
of the inverse of the matrix used for the vertices.
I think the issue is whether glEnable(GL_NORMALIZE) is called--
if not, the intensity of the lighting will be scaled wrongly
(this is true even for uniform scaling).

What version of Performer are you using?
Performer 2.2 properly tracks non-unit scales
in the scene graph and enables or disables GL_NORMALIZE appropriately.

Performer 2.0 had GL_NORMALIZE enabled all the time
(with a performance penalty).
I think Performer 2.1 never enabled it, but I'm not sure.

> 
> Perhaps manual rescaling (i.e. multiplying each vertex
> by a Matrix, and its Normal by another) during load phase?
> 
> I want to speed object loading up, because I am doing dynamic
> database management.

Yes, you could do that... multiply the normals by
the transpose of the inverse of the SCS matrix, and then renormalize the
resulting vectors to unit length.
Avoiding scales in the scene graph lets OpenGL go in a faster mode
(more precisely, it allows Performer to glDisable(GL_NORMALIZE)).

Don

-- 
Don Hatch  hatch@sgi.com  (415) 933-5150  Silicon Graphics, Inc.
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 14 18:47:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA15982 for info-performer-dist@holodeck.engr.sgi.com; Tue, 14 Apr 1998 18:21:15 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA15955 for <info-performer@holodeck.engr.sgi.com>; Tue, 14 Apr 1998 18:21:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA9849237
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 14 Apr 1998 18:21:13 -0700 (PDT)
Received: from mail.ucsd.edu (ucsd.ucsd.edu [132.239.1.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id SAA01975
	for <info-performer@sgi.com>; Tue, 14 Apr 1998 18:21:12 -0700 (PDT)
	mail_from (sbrown@nestor.ucsd.edu)
From: sbrown@nestor.ucsd.edu
Received: from nestor.ucsd.edu (nestor.ucsd.edu [132.239.126.4]) by mail.ucsd.edu; id SAA06527
	sendmail 8.8.5/UCSD8.3 via SMTP
	Tue, 14 Apr 1998 18:21:10 -0700 (PDT) for <@mail.UCSD.EDU:info-performer@sgi.com>
Received: from localhost (sbrown@localhost) by nestor.ucsd.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA23258 for <info-performer@sgi.com>; Tue, 14 Apr 1998 18:06:20 -0700
Date: Tue, 14 Apr 1998 18:06:20 -0700 (PDT)
To: info-performer@sgi.com
Subject: trouble
Message-ID: <Pine.SGI.3.95.980414180443.23249C-100000@nestor.ucsd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hi,

We've got a problem that we can't figure out how to approach debugging.

We are running a C application with Performer 2.1 on a single CPU R10K Onyx RE2.

Our program will run fine for a while then it dies, with this message:

WARNING: Process [Playhouse.DSO] pid 1767 killed: process or stack limit exceeded

We have no intentional recursions going on.

Below are the messages generated when running through dbx and gdb.

Any suggestions would be greatly appreciated!

Thanks,

Sheldon Brown
sgbrown@ucsd.edu

==> dbx

Process  1767 (Playhouse.DSO) stopped on signal SIGSEGV: Segmentation violation (default) at [pfGroup::nb_clean(int):139 +0x10,0x5d5b5c84]
         Source (of ../../../lib/libpf/pfGroup.C) not available for Process  1767

==> gdb


gdb Playhouse.DSO core

From guest  Wed Apr 15 07:23:05 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA18240 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 07:01:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA18213 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 07:01:34 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA10576691
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 07:01:33 -0700 (PDT)
Received: from gatekeeper.rayva.org (gatekeeper.rayva.org [204.254.244.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA09662
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 07:01:31 -0700 (PDT)
	mail_from (trdecarlo@tasc.com)
Received: (from root@localhost) by gatekeeper.rayva.org (8.8.7/8.6.12) id KAA01005; Wed, 15 Apr 1998 10:00:27 -0400 (EDT)
Received: from jpsds14e(192.168.5.103) by gatekeeper via smap (V2.0)
	id xma001003; Wed, 15 Apr 98 10:00:26 -0400
Received: from tasc.com ([192.168.8.210]) by jpsds14e.rayva.org (8.6.12/8.6.12) with ESMTP id KAA22271; Wed, 15 Apr 1998 10:01:32 -0400
Message-ID: <3534BDD6.B7D52BF3@tasc.com>
Date: Wed, 15 Apr 1998 10:01:58 -0400
From: Thom DeCarlo <trdecarlo@tasc.com>
Reply-To: trdecarlo@tasc.com
Organization: TASC, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: db@ParadigmSim.com
CC: lwillis@inreach.com, info-performer@sgi.com
Subject: Re: Constructing pfASD
References: <199803282004.MAA12593@mail.inreach.com> <3533C0CD.5A50@ParadigmSim.com>
Content-Type: multipart/alternative; boundary="------------1E1C17FAE16A8B25DCF14258"
Status: O


--------------1E1C17FAE16A8B25DCF14258
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Dan Brockway wrote:

> Lee Willis wrote:
>
>> Thom DeCarlo wrote:
>>
>> > Lee Willis wrote:
>> >
>> >>  From: Jonas Andersson <jonasa@cs.umu.se>
>> >>  To: info-performer@sgi.com
>> >>  Subject: Constructing pfASD
>> >>  Date: Friday, March 27, 1998 1:52 AM
>> >>
>> >>  [snip]
>> >
>> > ... snip ...
>> >
>> > It becomes something to be avoided! Our applications need to ingest
>> > sub-meter elevation post spaced data and we want to smoothly reduce
>> > resolution as the viewer moves away from the terrain. This seems to be
>> > exactly the opposite of the situation you describe.
>>
>> So far I don't understand what the problem is. The Multigen CAT
>> implementation of ASD does just that, picks out the most significant points
>> for each LOD, working from coarsest to finest, injecting new points to each
>> LOD to better approximate the surface.
>
> If, on the other hand, you have a specific terrain surface at the highest LOD
> that correlates with other databases, then MultiGen's CAT is of no value.

YES! This is exactly the point I was trying to make. We have a variety of
terrain sets, with post spacings ranging from 100m to 1m. What I really need is
to have our LODs morph between the different datasets. And yes, I recognise that
there will be correlation issues to be resolved. For this issue, let's assume
they are handled in the preprocessing stages.

Thom


>  Dan
>
>> ------------------------------
>> Lee Willis                        Virtual Landscape Dermatologist
>>
>> lwillis@terrex.com          TERREX
>
> --
> Dan Brockway                          voice: (972) 960-2301
> Paradigm Simulation Inc.              fax:   (972) 960-2303
> 14900 Landmark Blvd., Suite 400       mailto:db@ParadigmSim.com
> Dallas TX 75240                       http://www.ParadigmSim.com


  ------------------------------------------------------------------------
          Thom DeCarlo                  Off site contact info
          TASC                          JPSD/IEC, US Army TEC
          12100 Sunset Hills Rd.        7701 Telegraph Rd., Bldg. 2592
          Reston, VA 20190              Alexandria, VA 22315
          phone: 703/834-5000           phone: 703/428-9001, -7060, or
                                        -7034
          fax:   703/318-7900           fax:   703/428-7054
          mailto:trdecarlo@tasc.com     mailto:tdecarlo@rayva.org
  ------------------------------------------------------------------------
            The goal of program development is to make sure there is
                   at least one right way to use the software.
            The goal of product development is to make sure there is
                        no wrong way to use the software.

--------------1E1C17FAE16A8B25DCF14258
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
&nbsp;

<P>Dan Brockway wrote:
<BLOCKQUOTE TYPE=CITE>Lee Willis wrote:
<BLOCKQUOTE TYPE=CITE>Thom DeCarlo wrote:
<BLOCKQUOTE TYPE=CITE>Lee Willis wrote:
<BLOCKQUOTE TYPE=CITE>From: Jonas Andersson &lt;jonasa@cs.umu.se>
<BR>To: info-performer@sgi.com
<BR>Subject: Constructing pfASD
<BR>Date: Friday, March 27, 1998 1:52 AM

<P>[snip]</BLOCKQUOTE>
... snip ...

<P>It becomes something to be <U>avoided</U>! Our applications need to
ingest sub-meter elevation post spaced data and we want to smoothly reduce
resolution as the viewer moves away from the terrain. This seems to be
exactly the opposite of the situation you describe.</BLOCKQUOTE>
So far I don't understand what the problem is. The Multigen CAT implementation
of ASD does just that, picks out the most significant points for each LOD,
working from coarsest to finest, injecting new points to each LOD to better
approximate the surface.</BLOCKQUOTE>
If, on the other hand, you have a specific terrain surface at the highest
LOD that correlates with other databases, then MultiGen's CAT is of no
value.</BLOCKQUOTE>
YES! This is exactly the point I was trying to make. We have a variety
of terrain sets, with post spacings ranging from 100m to 1m. What I really
need is to have our LODs morph between the different datasets. And yes,
I recognise that there will be correlation issues to be resolved. For this
issue, let's assume they are handled in the preprocessing stages.

<P>Thom
<BR>&nbsp;
<BLOCKQUOTE TYPE=CITE>&nbsp;Dan
<BLOCKQUOTE TYPE=CITE>------------------------------
<BR>Lee Willis&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Virtual Landscape Dermatologist

<P>lwillis@terrex.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TERREX</BLOCKQUOTE>
--
<BR>Dan Brockway&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
voice: (972) 960-2301
<BR>Paradigm Simulation Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
fax:&nbsp;&nbsp; (972) 960-2303
<BR>14900 Landmark Blvd., Suite 400&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<A HREF="mailto:db@ParadigmSim.com">mailto:db@ParadigmSim.com</A>
<BR>Dallas TX 75240&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<A HREF="http://www.ParadigmSim.com">http://www.ParadigmSim.com</A></BLOCKQUOTE>
&nbsp;
<HR WIDTH="100%">
<CENTER><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 COLS=2 WIDTH="75%" BGCOLOR="#FFFFFF" >
<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>Thom DeCarlo</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>Off site contact info</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>TASC</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>JPSD/IEC, US Army TEC</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>12100 Sunset Hills Rd.</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>7701 Telegraph Rd., Bldg.
2592</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>Reston, VA 20190</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>Alexandria, VA 22315</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>phone: 703/834-5000</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>phone: 703/428-9001, -7060,
or -7034</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>fax:&nbsp;&nbsp; 703/318-7900</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>fax:&nbsp;&nbsp; 703/428-7054</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1><A HREF="mailto:trdecarlo@tasc.com">mailto:trdecarlo@tasc.com</A></FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1><A HREF="mailto:tdecarlo@rayva.org">mailto:tdecarlo@rayva.org</A></FONT></FONT></TD>
</TR>
</TABLE></CENTER>

<HR WIDTH="100%">
<CENTER>The goal of program development is to make sure there is</CENTER>

<CENTER>at least one right way to use the software.</CENTER>

<CENTER>The goal of product development is to make sure there is</CENTER>

<CENTER>no wrong way to use the software.</CENTER>
</HTML>

--------------1E1C17FAE16A8B25DCF14258--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 07:39:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA18317 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 07:25:35 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA18290 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 07:25:30 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA12171505
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 07:25:30 -0700 (PDT)
Received: from cavalier.cambridge.com (mail.cambridge.com [208.148.185.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA17131
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 07:25:28 -0700 (PDT)
	mail_from (mcmillan@cambridge.com)
Received: by cavalier.cambridge.com (951211.SGI.8.6.12.PATCH1042/940406.SGI)
	for <info-performer@sgi.com> id KAA04671; Wed, 15 Apr 1998 10:20:10 -0400
Received: from ds9(192.9.200.40) by cavalier via smap (3.1)
	id xma004664; Wed, 15 Apr 98 10:20:01 -0400
Received: from photon.cambridge.com by ds9.cambridge.com (4.1/SMI-4.1-SWS)
	id AA02881; Wed, 15 Apr 98 10:19:59 EDT
Received: from photon by photon.cambridge.com (940816.SGI.8.6.9/SMI-4.1-rbj)
	id KAA01741; Wed, 15 Apr 1998 10:20:00 -0400
Sender: mcmillan@cambridge.com
Message-Id: <3534C20F.2781@cambridge.com>
Date: Wed, 15 Apr 1998 10:19:59 -0400
From: Scott McMillan <mcmillan@cambridge.com>
Organization: Cambridge Research Associates
X-Mailer: Mozilla 3.01 (X11; I; IRIX 5.3 IP12)
Mime-Version: 1.0
To: info-performer@sgi.com
Subject: Compiling -mips3 -n32 with MIPSpro7.2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

I know this is a bit outside the scope of Performer but I am
trying to compile a Performer program...

I just installed the new 7.2 MIPSpro C++ compiler (you know,
the one that requires a license now :-0 ) on an R5K O2, installed
the April edition of the recommended patchset plus all of the
applicable patches for the compiler.

I want to compile the application with '-mips3 -n32' so that I
can run the app on an R4x00 platform too.  When it links, I get
the following message:

ld32: WARNING 158: Expecting MIPS3 objects: /usr/lib32/crt1.o is MIPS4.

The resulting executable is MIPS4 which will only run on systems
with R5K, R8K, and R10K cpus.

In /usr/lib32, crt1.o is a link to mips4/crt1.o, and there
exists a mips3/crt1.o.  Is there a way to get the new linker
to understand the meaning of the -mips3 option and link the
appropriate object?  Is there a known workaround, short of
changing the links?

Thanks in advance,
scott

-- 
Scott McMillan                   mailto:mcmillan@cambridge.com
Cambridge Research Associates    Ministry of Silly Walks
1430 Spring Hill Road, Ste. 200  Voice: (703) 790-0505 x7235
McLean, VA 22102                 Fax:   (703) 790-0370
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 07:39:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA18287 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 07:23:51 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA18260 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 07:23:50 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA12212131
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 07:23:49 -0700 (PDT)
Received: from gatekeeper.rayva.org (gatekeeper.rayva.org [204.254.244.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA16616
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 07:23:48 -0700 (PDT)
	mail_from (trdecarlo@tasc.com)
Received: (from root@localhost) by gatekeeper.rayva.org (8.8.7/8.6.12) id KAA01125; Wed, 15 Apr 1998 10:23:29 -0400 (EDT)
Received: from jpsds14e(192.168.5.103) by gatekeeper via smap (V2.0)
	id xma001121; Wed, 15 Apr 98 10:23:26 -0400
Received: from tasc.com ([192.168.8.210]) by jpsds14e.rayva.org (8.6.12/8.6.12) with ESMTP id KAA22451; Wed, 15 Apr 1998 10:24:32 -0400
Message-ID: <3534C33B.D38B4DD0@tasc.com>
Date: Wed, 15 Apr 1998 10:24:59 -0400
From: Thom DeCarlo <trdecarlo@tasc.com>
Reply-To: trdecarlo@tasc.com
Organization: TASC, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: lwillis@inreach.com
CC: db@ParadigmSim.com, info-performer@sgi.com
Subject: Re: Constructing pfASD
References: <199804142217.PAA23356@mail.inreach.com>
Content-Type: multipart/alternative; boundary="------------B5CC285EA035DDEDC87FAD9B"
Status: O


--------------B5CC285EA035DDEDC87FAD9B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lee Willis wrote:

> From: Dan Brockway <db@ParadigmSim.com>
>
>> Lee Willis wrote:
>>
>> > So far I don't understand what the problem is.   The Multigen CAT
>> > implementation of ASD does just that, picks out the most significant
>> > points for each LOD, working from coarsest to finest, injecting new
>> > points to each LOD to better approximate the surface.
>>
>> If, on the other hand, you have a specific terrain surface at the highest
>> LOD that correlates with other databases, then MultiGen's CAT is of no
>> value.
>
> No argument. But the problem goes deeper than that. If you have a specific
> terrain surface at the highest LOD that correlates with other databases,
> ***ASD*** is of no value. (unless you're database happens to be a regular
> grid)
>
> You cannot construct an ASD from an arbitrary triangular mesh. It just aint
> doable.
>

I'm sure you will correct me if I am wrong, but since we are talking about
starting from the raw source (DTED type data), we do have a regular grid. The
triangular mesh needn't be generated until much later in the process. It seems
to me that there should be a straight-forward, though time-consuming, process
that looks at each point in the highest resolution set, finds the nearest
point in the next lower resolution set, and identifies that as the "morph to"
point.Since you say this is hard, there must be something I am missing.

> ------------------------------
> Lee Willis                        Virtual Landscape Dermatologist
>
> lwillis@terrex.com           TERREX


  ------------------------------------------------------------------------
          Thom DeCarlo                 Off site contact info
          TASC                         JPSD/IEC, US Army TEC
          12100 Sunset Hills Rd.       7701 Telegraph Rd., Bldg.
                                       2592
          Reston, VA 20190             Alexandria, VA 22315
          phone: 703/834-5000          phone: 703/428-9001, -7060,
                                       or -7034
          fax:   703/318-7900          fax:   703/428-7054
          mailto:trdecarlo@tasc.com    mailto:tdecarlo@rayva.org
  ------------------------------------------------------------------------
           The goal of program development is to make sure there is
                  at least one right way to use the software.
           The goal of product development is to make sure there is
                       no wrong way to use the software.

--------------B5CC285EA035DDEDC87FAD9B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>


<P>Lee Willis wrote:
<BLOCKQUOTE TYPE=CITE>From: Dan Brockway &lt;db@ParadigmSim.com>
<BLOCKQUOTE TYPE=CITE>Lee Willis wrote:
<BLOCKQUOTE TYPE=CITE>So far I don't understand what the problem is.&nbsp;&nbsp;
The Multigen CAT implementation of ASD does just that, picks out the most
significant points for each LOD, working from coarsest to finest, injecting
new points to each LOD to better approximate the surface.</BLOCKQUOTE>
If, on the other hand, you have a specific terrain surface at the highest
LOD that correlates with other databases, then MultiGen's CAT is of no
value.</BLOCKQUOTE>
No argument. But the problem goes deeper than that. If you have a specific
terrain surface at the highest LOD that correlates with other databases,
***ASD*** is of no value. (unless you're database happens to be a regular
grid)

<P>You cannot construct an ASD from an arbitrary triangular mesh. It just
aint doable.
<BR>&nbsp;</BLOCKQUOTE>
I'm sure you will correct me if I am wrong, but since we are talking about
starting from the raw source (DTED type data), we do have a regular grid.
The triangular mesh needn't be generated until much later in the process.
It seems to me that there should be a straight-forward, though time-consuming,
process that looks at each point in the highest resolution set, finds the
nearest point in the next lower resolution set, and identifies that as
the "morph to" point.Since you say this is hard, there must be something
I am missing.
<BLOCKQUOTE TYPE=CITE>

<P>------------------------------
<BR>Lee Willis&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Virtual Landscape Dermatologist

<P>lwillis@terrex.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TERREX</BLOCKQUOTE>
&nbsp;
<HR WIDTH="100%">
<CENTER><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 COLS=2 WIDTH="75%" BGCOLOR="#FFFFFF" >
<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>Thom DeCarlo</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>Off site contact info</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>TASC</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>JPSD/IEC, US Army TEC</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>12100 Sunset Hills Rd.</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>7701 Telegraph Rd., Bldg.
2592</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>Reston, VA 20190</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>Alexandria, VA 22315</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>phone: 703/834-5000</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>phone: 703/428-9001, -7060,
or -7034</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>fax:&nbsp;&nbsp; 703/318-7900</FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1>fax:&nbsp;&nbsp; 703/428-7054</FONT></FONT></TD>
</TR>

<TR>
<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1><A HREF="mailto:trdecarlo@tasc.com">mailto:trdecarlo@tasc.com</A></FONT></FONT></TD>

<TD><FONT FACE="Calligraph421 BT"><FONT SIZE=-1><A HREF="mailto:tdecarlo@rayva.org">mailto:tdecarlo@rayva.org</A></FONT></FONT></TD>
</TR>
</TABLE></CENTER>

<HR WIDTH="100%">
<CENTER>The goal of program development is to make sure there is</CENTER>

<CENTER>at least one right way to use the software.</CENTER>

<CENTER>The goal of product development is to make sure there is</CENTER>

<CENTER>no wrong way to use the software.</CENTER>
</HTML>

--------------B5CC285EA035DDEDC87FAD9B--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 08:46:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA18744 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 08:33:46 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA18717 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 08:33:44 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA11555018
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 08:33:44 -0700 (PDT)
Received: from mail.inreach.com ([209.142.0.209]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id IAA12747
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 08:33:43 -0700 (PDT)
	mail_from (lwillis@inreach.com)
Received: from get (209-142-17-200.oak.inreach.net [209.142.17.200]) by mail.inreach.com (8.8.8/8.8.6/(InReach)) with ESMTP id IAA13710; Wed, 15 Apr 1998 08:28:54 -0700 (PDT)
Message-Id: <199804151528.IAA13710@mail.inreach.com>
Reply-To: <lwillis@inreach.com>
From: "Lee Willis" <lwillis@inreach.com>
To: <trdecarlo@tasc.com>
Cc: <db@ParadigmSim.com>, <info-performer@sgi.com>
Subject: Re: Constructing pfASD
Date: Wed, 15 Apr 1998 08:28:48 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1162
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Status: O

----------
 From: Thom DeCarlo <trdecarlo@tasc.com>
>> Lee Willis wrote:
>> From: Dan Brockway <db@ParadigmSim.com>
>>
>>> If, on the other hand, you have a specific terrain surface at the
highest
>>> LOD that correlates with other databases, then MultiGen's CAT is of no
>>> value.
>>
>> No argument. But the problem goes deeper than that. If you have a
specific
>> terrain surface at the highest LOD that correlates with other databases,
>> ***ASD*** is of no value. (unless you're database happens to be a
regular
>> grid)
>>
>> You cannot construct an ASD from an arbitrary triangular mesh. It just
aint
>> doable.
>>
>
>I'm sure you will correct me if I am wrong, but since we are talking about
>starting from the raw source (DTED type data), we do have a regular grid.
The
>triangular mesh needn't be generated until much later in the process. It
seems
>to me that there should be a straight-forward, though time-consuming,
process
>that looks at each point in the highest resolution set, finds the nearest
>point in the next lower resolution set, and identifies that as the "morph
to"
>point.Since you say this is hard, there must be something I am missing.

You and Dan are talking about different scenarios.

Dan is talking about having a preconstructed polygonal database at the best
LOD,
and then trying to derive coarser LODs from that set of polygons -- can't
be done.

You're talking about starting from elevation data -- that *can* be done. 
Multigen CAT
does it, or you can write you're own. 

In very broad strokes, here's how:

1) construct a tesselation to be your base (coarsest) LOD.  This can be
something as
 simple as two triangles to form a rectangle, or you can use standard
terrain algorithms
 (e.g. Delaunay) to construct an irregular mesh.

2) For each subsequen LOD:

2a)	Using the previous LOD as a base, choose at most one new point to split
each 
	existing edge.  You'll need to decide how to choose a new point.  You can
use
	something simple like 'worst vertical error within the neighborhood of the
edge'.
	(i.e. compare the polygons to your elevation grid, pick the elevation
point that falls
	furthest off the polygonal surface)

	More complicated algorithms are of course also possible.  (e.g. ones which
may
	weight some points more than others)

2b)	Re-tesselate

----

You'll notice that this algorithm doesn't start with all the points and
choose which ones to throw out.
It starts with a few points and then decides which new points to add.  This
is what I mean by doing
it 'top-down' rather than 'bottom-up'.  It's an insertion algorithm rather
than a decimation algorithm.

------------------------------
Lee Willis                        Virtual Landscape Dermatologist          
      
lwillis@terrex.com           TERREX


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 09:14:52 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA18792 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 08:57:25 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA18765 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 08:57:24 -0700
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id IAA10834; Wed, 15 Apr 1998 08:57:19 -0700 (PDT)
Date: Wed, 15 Apr 1998 08:57:19 -0700 (PDT)
Message-Id: <199804151557.IAA10834@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: Scott McMillan <mcmillan@cambridge.com>
cc: info-performer@puget.engr.sgi.com
Subject: Compiling -mips3 -n32 with MIPSpro7.2
In-Reply-To: <3534C20F.2781@cambridge.com>
References: <3534C20F.2781@cambridge.com>
Status: O


Scott McMillan writes:
 > I know this is a bit outside the scope of Performer but I am
 > trying to compile a Performer program...
 > 
 > I just installed the new 7.2 MIPSpro C++ compiler (you know,
 > the one that requires a license now :-0 ) on an R5K O2, installed
 > the April edition of the recommended patchset plus all of the
 > applicable patches for the compiler.
 > 
 > I want to compile the application with '-mips3 -n32' so that I
 > can run the app on an R4x00 platform too.  When it links, I get
 > the following message:
 > 
 > ld32: WARNING 158: Expecting MIPS3 objects: /usr/lib32/crt1.o is MIPS4.
 > 
 > The resulting executable is MIPS4 which will only run on systems
 > with R5K, R8K, and R10K cpus.
 > 
 > In /usr/lib32, crt1.o is a link to mips4/crt1.o, and there
 > exists a mips3/crt1.o.  Is there a way to get the new linker
 > to understand the meaning of the -mips3 option and link the
 > appropriate object?  Is there a known workaround, short of
 > changing the links?
 > 
 > Thanks in advance,
 > scott
 > 

Adding the "-L /usr/lib32/mips3" to the link step of the compilation 
should make it take all the mips3 libraries and crt1.o (and crtn.o, as
if it matters).  

But I don't know what the ramifications of doing this are.  Will 
the resulting program always work correctly?  I don't know.  I'll
check on it and get back to you.

------------------------------------------------------------------------
Jay L Gischer        +  "I see great things in baseball.  It's our game.
Advanced Graphics    +  It will repair our losses and be a blessing to
Software             +  us."
Silicon Graphics     +    -Walt Whitman
(415) 390-4277       +    
gischer@sgi.com      +  "A life has no meaning except in the impact it
                     +  has on other lives"
                     +    -Jackie Robinson

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 10:01:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA19112 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 09:44:36 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA19085 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 09:44:34 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA11417904
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 09:44:33 -0700 (PDT)
Received: from spiffy.paradigmsim.com (spiffy.paradigmsim.com [206.7.114.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA15064
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 09:44:31 -0700 (PDT)
	mail_from (db@ParadigmSim.com)
Received: from db.paradigmsim.com by spiffy.paradigmsim.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id LAA08316; Wed, 15 Apr 1998 11:37:51 -0500
Message-ID: <3534E455.1075@ParadigmSim.com>
Date: Wed, 15 Apr 1998 11:46:14 -0500
From: Dan Brockway <db@ParadigmSim.com>
Reply-To: db@ParadigmSim.com
Organization: Paradigm Simulation Inc.
X-Mailer: Mozilla 3.01 (Win95; I)
MIME-Version: 1.0
To: lwillis@inreach.com
CC: trdecarlo@tasc.com, info-performer@sgi.com
Subject: Re: Constructing pfASD
References: <199804151528.IAA13710@mail.inreach.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Lee Willis wrote:
> 
> ----------
>  From: Thom DeCarlo <trdecarlo@tasc.com>
> >> Lee Willis wrote:
> >> From: Dan Brockway <db@ParadigmSim.com>
> >>
> >>> If, on the other hand, you have a specific terrain surface at the
> highest
> >>> LOD that correlates with other databases, then MultiGen's CAT is of no
> >>> value.
> >>
> >> No argument. But the problem goes deeper than that. If you have a
> specific
> >> terrain surface at the highest LOD that correlates with other databases,
> >> ***ASD*** is of no value. (unless you're database happens to be a
> regular
> >> grid)
> >>
> >> You cannot construct an ASD from an arbitrary triangular mesh. It just
> aint
> >> doable.
> >>
> >
> >I'm sure you will correct me if I am wrong, but since we are talking about
> >starting from the raw source (DTED type data), we do have a regular grid.
> The
> >triangular mesh needn't be generated until much later in the process. It
> seems
> >to me that there should be a straight-forward, though time-consuming,
> process
> >that looks at each point in the highest resolution set, finds the nearest
> >point in the next lower resolution set, and identifies that as the "morph
> to"
> >point.Since you say this is hard, there must be something I am missing.
> 
> You and Dan are talking about different scenarios.
> 
> Dan is talking about having a preconstructed polygonal database at the best
> LOD,
> and then trying to derive coarser LODs from that set of polygons -- can't
> be done.
> 
> You're talking about starting from elevation data -- that *can* be done.
> Multigen CAT
> does it, or you can write you're own.
> 
> In very broad strokes, here's how:
> 
> 1) construct a tesselation to be your base (coarsest) LOD.  This can be
> something as
>  simple as two triangles to form a rectangle, or you can use standard
> terrain algorithms
>  (e.g. Delaunay) to construct an irregular mesh.
> 
> 2) For each subsequen LOD:
> 
> 2a)     Using the previous LOD as a base, choose at most one new point to split
> each
>         existing edge.  You'll need to decide how to choose a new point.  You can
> use
>         something simple like 'worst vertical error within the neighborhood of the
> edge'.
>         (i.e. compare the polygons to your elevation grid, pick the elevation
> point that falls
>         furthest off the polygonal surface)
> 
>         More complicated algorithms are of course also possible.  (e.g. ones which
> may
>         weight some points more than others)
> 
> 2b)     Re-tesselate
> 
> ----
> 
> You'll notice that this algorithm doesn't start with all the points and
> choose which ones to throw out.
> It starts with a few points and then decides which new points to add.  This
> is what I mean by doing
> it 'top-down' rather than 'bottom-up'.  It's an insertion algorithm rather
> than a decimation algorithm.

So, if one modified this algorithm to insert only points from the source
TIN instead of from the source DEM, one could arrive at the source TIN!
This may not be straight forward, but possible.

Dan


> 
> ------------------------------
> Lee Willis                        Virtual Landscape Dermatologist
> 
> lwillis@terrex.com           TERREX
> 
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com

-- 
Dan Brockway                          voice: (972) 960-2301
Paradigm Simulation Inc.              fax:   (972) 960-2303
14900 Landmark Blvd., Suite 400       mailto:db@ParadigmSim.com
Dallas TX 75240                       http://www.ParadigmSim.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 12:02:06 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA19420 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 11:44:25 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA19393 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 11:44:23 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA12264881
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 11:44:22 -0700 (PDT)
Received: from oxe.cs.umu.se (oxe.cs.umu.se [130.239.40.14]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA18287
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 11:44:20 -0700 (PDT)
	mail_from (jonasa@cs.umu.se)
Received: from jewel.cs.umu.se (rfc1413 says jonasa@jewel.cs.umu.se [130.239.40.136]) by oxe.cs.umu.se (8.8.8/8.8.8) with ESMTP id UAA22565; Wed, 15 Apr 1998 20:44:17 +0200 (MET DST)
Received: from localhost (rfc1413 says jonasa@localhost) by jewel.cs.umu.se (8.8.7/8.8.7) with ESMTP id SAA08162; Wed, 15 Apr 1998 18:44:11 GMT
X-Authentication-Warning: jewel.cs.umu.se: jonasa owned process doing -bs
Date: Wed, 15 Apr 1998 20:44:11 +0200 (MDT)
From: Jonas Andersson <jonasa@cs.umu.se>
To: Dan Brockway <db@ParadigmSim.com>
cc: lwillis@inreach.com, trdecarlo@tasc.com, info-performer@sgi.com
Subject: Re: Constructing pfASD
In-Reply-To: <3534E455.1075@ParadigmSim.com>
Message-ID: <Pine.SGI.3.95.980415203211.7510B-100000@jewel.cs.umu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by cthulhu.engr.sgi.com id LAA12273898
Status: O

On Wed, 15 Apr 1998, Dan Brockway wrote:

> Lee Willis wrote:
> >=20
> > ----------
> >  From: Thom DeCarlo <trdecarlo@tasc.com>
> > >> Lee Willis wrote:
> > >> From: Dan Brockway <db@ParadigmSim.com>
> > >>
> > >>> If, on the other hand, you have a specific terrain surface at the
> > highest
> > >>> LOD that correlates with other databases, then MultiGen's CAT is =
of no
> > >>> value.
> > >>
> > >> No argument. But the problem goes deeper than that. If you have a
> > specific
> > >> terrain surface at the highest LOD that correlates with other data=
bases,
> > >> ***ASD*** is of no value. (unless you're database happens to be a
> > regular
> > >> grid)
> > >>
> > >> You cannot construct an ASD from an arbitrary triangular mesh. It =
just
> > aint
> > >> doable.
> > >>
> > >
> > >I'm sure you will correct me if I am wrong, but since we are talking=
 about
> > >starting from the raw source (DTED type data), we do have a regular =
grid.
> > The
> > >triangular mesh needn't be generated until much later in the process=
. It
> > seems
> > >to me that there should be a straight-forward, though time-consuming=
,
> > process
> > >that looks at each point in the highest resolution set, finds the ne=
arest
> > >point in the next lower resolution set, and identifies that as the "=
morph
> > to"
> > >point.Since you say this is hard, there must be something I am missi=
ng.
> >=20
> > You and Dan are talking about different scenarios.
> >=20
> > Dan is talking about having a preconstructed polygonal database at th=
e best
> > LOD,
> > and then trying to derive coarser LODs from that set of polygons -- c=
an't
> > be done.
> >=20
> > You're talking about starting from elevation data -- that *can* be do=
ne.
> > Multigen CAT
> > does it, or you can write you're own.
> >=20
> > In very broad strokes, here's how:
> >=20
> > 1) construct a tesselation to be your base (coarsest) LOD.  This can =
be
> > something as
> >  simple as two triangles to form a rectangle, or you can use standard
> > terrain algorithms
> >  (e.g. Delaunay) to construct an irregular mesh.
> >=20
> > 2) For each subsequen LOD:
> >=20
> > 2a)     Using the previous LOD as a base, choose at most one new poin=
t to split
> > each
> >         existing edge.  You'll need to decide how to choose a new poi=
nt.  You can
> > use
> >         something simple like 'worst vertical error within the neighb=
orhood of the
> > edge'.
> >         (i.e. compare the polygons to your elevation grid, pick the e=
levation
> > point that falls
> >         furthest off the polygonal surface)
> >=20
> >         More complicated algorithms are of course also possible.  (e.=
g. ones which
> > may
> >         weight some points more than others)
> >=20
> > 2b)     Re-tesselate
> >=20
> > ----
> >=20
> > You'll notice that this algorithm doesn't start with all the points a=
nd
> > choose which ones to throw out.
> > It starts with a few points and then decides which new points to add.=
  This
> > is what I mean by doing
> > it 'top-down' rather than 'bottom-up'.  It's an insertion algorithm r=
ather
> > than a decimation algorithm.
>=20
> So, if one modified this algorithm to insert only points from the sourc=
e
> TIN instead of from the source DEM, one could arrive at the source TIN!
> This may not be straight forward, but possible.

By doing this it is clear that the vertices in your source TIN would
exist. You could arrive at the source TIN, but most likely you won=B4t.
If one could ensure that the edges were the same then we would arrive at
the source TIN, but is it possible to ensure that?

That, I think, is the problem.

>=20
> Dan
>=20
>=20
> >=20
> > ------------------------------
> > Lee Willis                        Virtual Landscape Dermatologist
> >=20
> > lwillis@terrex.com           TERREX
> >=20
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
> >             Submissions:  info-performer@sgi.com
> >         Admin. requests:  info-performer-request@sgi.com
>=20
> --=20
> Dan Brockway                          voice: (972) 960-2301
> Paradigm Simulation Inc.              fax:   (972) 960-2303
> 14900 Landmark Blvd., Suite 400       mailto:db@ParadigmSim.com
> Dallas TX 75240                       http://www.ParadigmSim.com
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>=20

TTFN
  Jonas

_________________________________________________________________________=
_______
Jonas Andersson			jonasa@cs.umu.se, http://www.cs.umu.se/~jonasa

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 14:25:08 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA19749 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 14:12:02 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA19722 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 14:12:01 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA9298267
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 14:12:00 -0700 (PDT)
Received: from lobster.bu.edu (LOBSTER.BU.EDU [128.197.160.43]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA20242
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 14:11:56 -0700 (PDT)
	mail_from (ebrisson@lobster.bu.edu)
Received: (from ebrisson@localhost) by lobster.bu.edu (8.8.5/8.7.3) id RAA34336 for info-performer@sgi.com; Wed, 15 Apr 1998 17:11:51 -0400
From: Erik Brisson <ebrisson@lobster.bu.edu>
Message-Id: <199804152111.RAA34336@lobster.bu.edu>
Subject: Rendering/shading seg faults
To: info-performer@sgi.com
Date: Wed, 15 Apr 98 17:11:50 EDT
X-Mailer: ELM [version 2.3 PL11]
Status: O

I have consistently had problems using graphics state commands, such 
as pfEnable(PFEN_LIGHTING) and pfShadeModel(PFSM_GOURARD).  In general,
I have programs which work without problems until I try to use such a
command - and when I simply add one such command I get a Segmentation fault.

I realize this is vague, and I could give the specifics of hardware and
performer versions, but it has happened on several different platforms,
and I believe several versions as well, so I am suspicious that there is
something which I am doing in my program which is a problem. 

So I just want to ask if there is a caveat as to when such functions are known
to cause problems?

Thanks,
Erik Brisson
ebrisson@bu.edu


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 15:31:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA20153 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 15:19:54 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA20126 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 15:19:51 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA12303025
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 15:19:50 -0700 (PDT)
Received: from ns1.arlut.utexas.edu (ns1.arlut.utexas.edu [129.116.212.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA19087
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 15:19:49 -0700 (PDT)
	mail_from (cpurvis@arlut.utexas.edu)
Received: from mail-firewall.arlut.utexas.edu (ns1.arlut.utexas.edu [129.116.212.1])
	by ns1.arlut.utexas.edu (8.8.5/8.8.5) with ESMTP id RAA22002
	for <@arlut.utexas.edu:info-performer@sgi.com>; Wed, 15 Apr 1998 17:19:47 -0500 (CDT)
Received: from chagos (chagos.arlut.utexas.edu [129.116.176.57])
	by mail-firewall.arlut.utexas.edu (8.8.5/8.8.5) with SMTP id RAA21994
	for <@ns1.arlut.utexas.edu:info-performer@sgi.com>; Wed, 15 Apr 1998 17:19:44 -0500 (CDT)
Received: by chagos (940816.SGI.8.6.9/940406.SGI.AUTO)
	for info-performer@sgi.com id RAA23731; Wed, 15 Apr 1998 17:19:44 -0500
From: "Chris Purvis" <cpurvis@arlut.utexas.edu>
Message-Id: <9804151719.ZM23729@chagos.arlut.utexas.edu>
Date: Wed, 15 Apr 1998 17:19:38 -0500
X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail)
To: info-performer@sgi.com
Subject: please remove from list
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

please remove me from this mailing list,

Thanks,
Chris Purvis

-- 
Chris Purvis
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 16:20:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA20469 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 16:01:12 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA20442 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 16:01:11 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA12171584
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 16:01:10 -0700 (PDT)
Received: from vista.taccsf.kirtland.af.mil (vista.taccsf.kirtland.af.mil [132.62.150.76]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id QAA05769
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 16:01:08 -0700 (PDT)
	mail_from (Sorroche@TACCSF.KIRTLAND.AF.MIL)
Received: by VISTA.TACCSF.KIRTLAND.AF.MIL with Internet Mail Service (5.5.1960.3)
	id <291FLXB3>; Wed, 15 Apr 1998 17:01:03 -0600
Message-ID: <214A87629D4FD111931F0060972989BA240688@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Missile Trails
Date: Wed, 15 Apr 1998 17:01:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD68C2.5CE1E4B0"
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD68C2.5CE1E4B0
Content-Type: text/plain

People;

	I'm using PFUSMOKES_MISSILE to draw missile trails, with the
following code:

migs[entity].smoke = pfuNewSmoke(); 
pfuSmokeOrigin(migs[entity].smoke, model_coord.xyz, 2);
pfuSmokeType(migs[entity].smoke, PFUSMOKE_MISSILE); 
pfuSmokeDuration(migs[entity].smoke, 5);
pfuSmokeMode(migs[entity].smoke, PFUSMOKE_START);  

It looks like two missiles are fired, one after the other, and the color
is the same as explosions, even when I use pfuSmokeColor.  Also, I get a
warning: too many pfuSmokes.  Any suggestions? Thanks.

Joe

------ =_NextPart_001_01BD68C2.5CE1E4B0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>Missile Trails</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">People;</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I'm using PFUSMOKES_MISSILE to draw missile trails, with =
the following code:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">migs[entity].smoke =3D pfuNewSmoke(); =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">pfuSmokeOrigin(migs[entity].smoke, =
model_coord.xyz, 2);</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">pfuSmokeType(migs[entity].smoke, =
PFUSMOKE_MISSILE); </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">pfuSmokeDuration(migs[entity].smoke, =
5);</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">pfuSmokeMode(migs[entity].smoke, =
PFUSMOKE_START);&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It looks like two missiles are fired, =
one after the other, and the color is the same as explosions, even when =
I use pfuSmokeColor.&nbsp; Also, I get a warning: too many =
pfuSmokes.&nbsp; Any suggestions? Thanks.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Joe</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD68C2.5CE1E4B0--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 16:39:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA20529 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 16:28:47 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA20502 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 16:28:46 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA9356567
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 16:28:45 -0700 (PDT)
Received: from mail-gw6.pacbell.net (mail-gw6.pacbell.net [206.13.28.41]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id QAA16904
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 16:28:43 -0700 (PDT)
	mail_from (sjg@terrex.com)
Received: from terrex.com (ppp-206-170-24-53.sntc01.pacbell.net [206.170.24.53]) by mail-gw6.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id QAA28270 for <info-performer@sgi.com>; Wed, 15 Apr 1998 16:28:39 -0700 (PDT)
Message-ID: <3535429B.61E2090E@terrex.com>
Date: Wed, 15 Apr 1998 16:28:27 -0700
From: Steve Gifford <sjg@terrex.com>
Reply-To: sjg@terrex.com
X-Mailer: Mozilla 4.03 [en] (WinNT; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Constructing pfASD
References: <199804151528.IAA13710@mail.inreach.com> <3534E455.1075@ParadigmSim.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Dan Brockway wrote:
> 
> Lee Willis wrote:
> >
> > ----------
> >  From: Thom DeCarlo <trdecarlo@tasc.com>
> > >> Lee Willis wrote:
> > >> From: Dan Brockway <db@ParadigmSim.com>
> > >>
> > >>> If, on the other hand, you have a specific terrain surface at the
> > highest
> > >>> LOD that correlates with other databases, then MultiGen's CAT is of no
> > >>> value.
> > >>
> > >> No argument. But the problem goes deeper than that. If you have a
> > specific
> > >> terrain surface at the highest LOD that correlates with other databases,
> > >> ***ASD*** is of no value. (unless you're database happens to be a
> > regular
> > >> grid)
> > >>
> > >> You cannot construct an ASD from an arbitrary triangular mesh. It just
> > aint
> > >> doable.
> > >>
> > >
> > >I'm sure you will correct me if I am wrong, but since we are talking about
> > >starting from the raw source (DTED type data), we do have a regular grid.
> > The
> > >triangular mesh needn't be generated until much later in the process. It
> > seems
> > >to me that there should be a straight-forward, though time-consuming,
> > process
> > >that looks at each point in the highest resolution set, finds the nearest
> > >point in the next lower resolution set, and identifies that as the "morph
> > to"
> > >point.Since you say this is hard, there must be something I am missing.
> >
> > You and Dan are talking about different scenarios.
> >
> > Dan is talking about having a preconstructed polygonal database at the best
> > LOD,
> > and then trying to derive coarser LODs from that set of polygons -- can't
> > be done.
> >
> > You're talking about starting from elevation data -- that *can* be done.
> > Multigen CAT
> > does it, or you can write you're own.
> >
> > In very broad strokes, here's how:
> >
> > 1) construct a tesselation to be your base (coarsest) LOD.  This can be
> > something as
> >  simple as two triangles to form a rectangle, or you can use standard
> > terrain algorithms
> >  (e.g. Delaunay) to construct an irregular mesh.
> >
> > 2) For each subsequen LOD:
> >
> > 2a)     Using the previous LOD as a base, choose at most one new point to split
> > each
> >         existing edge.  You'll need to decide how to choose a new point.  You can
> > use
> >         something simple like 'worst vertical error within the neighborhood of the
> > edge'.
> >         (i.e. compare the polygons to your elevation grid, pick the elevation
> > point that falls
> >         furthest off the polygonal surface)
> >
> >         More complicated algorithms are of course also possible.  (e.g. ones which
> > may
> >         weight some points more than others)
> >
> > 2b)     Re-tesselate
> >
> > ----
> >
> > You'll notice that this algorithm doesn't start with all the points and
> > choose which ones to throw out.
> > It starts with a few points and then decides which new points to add.  This
> > is what I mean by doing
> > it 'top-down' rather than 'bottom-up'.  It's an insertion algorithm rather
> > than a decimation algorithm.
> 
> So, if one modified this algorithm to insert only points from the source
> TIN instead of from the source DEM, one could arrive at the source TIN!
> This may not be straight forward, but possible.

You'd arrive at another TIN with the same set of points, but not
necessarily the same set of edges.  For the application where the source
TIN must be matched exactly this still wouldn't do it.

-Steve Gifford
 Terrex Inc.
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 18:24:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA20969 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 18:17:40 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA20942 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 18:17:29 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA11523362
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 18:17:26 -0700 (PDT)
Received: from vista.taccsf.kirtland.af.mil (vista.taccsf.kirtland.af.mil [132.62.150.76]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id SAA05304
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 18:17:23 -0700 (PDT)
	mail_from (suzie@TACCSF.KIRTLAND.AF.MIL)
Received: by VISTA.TACCSF.KIRTLAND.AF.MIL with Internet Mail Service (5.5.1960.3)
	id <291FLXCD>; Wed, 15 Apr 1998 19:17:21 -0600
Message-ID: <214A87629D4FD111931F0060972989BA072E93@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Performer Process State
Date: Wed, 15 Apr 1998 19:17:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD68D5.674185C0"
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD68D5.674185C0
Content-Type: text/plain

Hi,

Does anyone know if the following debug/information is available only
with Performer 2.2?  I'm running 2.0 on a 5.3 OS and would like it if
this information was available with a command option.  The -n 6 option
doesn't provide it.

----------- Performer Process State --------
Proc: APP       pid:18222
Proc: ISECT     pid:18222
Proc: DBASE     pid:18222
Proc: CLOCK     pid:18223
Proc: COMPUTE   pid:18222
Proc: SYNC      pid:0
Pipe Proc: CULL Pipes:1
        Proc: CULL Pipe:0       pid:0
Pipe Proc: DRAW Pipes:1
        Proc: DRAW Pipe:0       pid:0
Pipe Proc: LPOINT       Pipes:1
        Proc: LPOINT Pipe:0     pid:0
-------------------------------------------

Also, how can you tell which pids are the CULL and DRAW processes?

Thank you,
Suzie

------ =_NextPart_001_01BD68D5.674185C0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>Performer Process State</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Does anyone know if the following debug/information =
is available only with Performer 2.2?&nbsp; I'm running 2.0 on a 5.3 OS =
and would like it if this information was available with a command =
option.&nbsp; The -n 6 option doesn't provide it.</FONT></P>

<P><FONT SIZE=3D2>----------- Performer Process State --------</FONT>
<BR><FONT SIZE=3D2>Proc: APP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
pid:18222</FONT>
<BR><FONT SIZE=3D2>Proc: ISECT&nbsp;&nbsp;&nbsp;&nbsp; pid:18222</FONT>
<BR><FONT SIZE=3D2>Proc: DBASE&nbsp;&nbsp;&nbsp;&nbsp; pid:18222</FONT>
<BR><FONT SIZE=3D2>Proc: CLOCK&nbsp;&nbsp;&nbsp;&nbsp; pid:18223</FONT>
<BR><FONT SIZE=3D2>Proc: COMPUTE&nbsp;&nbsp; pid:18222</FONT>
<BR><FONT SIZE=3D2>Proc: SYNC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
pid:0</FONT>
<BR><FONT SIZE=3D2>Pipe Proc: CULL Pipes:1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Proc: =
CULL Pipe:0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pid:0</FONT>
<BR><FONT SIZE=3D2>Pipe Proc: DRAW Pipes:1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Proc: =
DRAW Pipe:0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pid:0</FONT>
<BR><FONT SIZE=3D2>Pipe Proc: =
LPOINT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pipes:1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Proc: =
LPOINT Pipe:0&nbsp;&nbsp;&nbsp;&nbsp; pid:0</FONT>
<BR><FONT SIZE=3D2>-------------------------------------------</FONT>
</P>

<P><FONT SIZE=3D2>Also, how can you tell which pids are the CULL and =
DRAW processes?</FONT>
</P>

<P><FONT SIZE=3D2>Thank you,</FONT>
<BR><FONT SIZE=3D2>Suzie</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD68D5.674185C0--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 15 19:44:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA21227 for info-performer-dist@holodeck.engr.sgi.com; Wed, 15 Apr 1998 19:31:26 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id TAA21200 for <info-performer@holodeck.engr.sgi.com>; Wed, 15 Apr 1998 19:31:24 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id TAA11361305
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 15 Apr 1998 19:31:24 -0700 (PDT)
Received: from email.bigsky.net (email.bigsky.net [206.252.225.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id TAA26058
	for <info-performer@sgi.com>; Wed, 15 Apr 1998 19:31:22 -0700 (PDT)
	mail_from (aphilp@bigsky.net)
Received: from bigsky.net (imodem133.capella.bigsky.net [206.252.227.133])
          by email.bigsky.net (8.8.8/8.8.4) with ESMTP
	  id UAA23167 for <info-performer@sgi.com>; Wed, 15 Apr 1998 20:32:33 -0600 (MDT)
Message-ID: <35356D27.6FEE4B37@bigsky.net>
Date: Wed, 15 Apr 1998 20:29:59 -0600
From: Alex Philp <aphilp@bigsky.net>
Reply-To: aphilp@bigsky.net
Organization: The School of Forestry, The University of Montana
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

please remove me from this mailing list,

Thanks,
Alex Philp

--

Alex Philp
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

--
********************************************************************************************

James Alexander Philp
Research Assistant
School of Forestry
The University of Montana
Missoula, Montana  59812
Work Phone:   (406) 240-0580
Facsimile: (406) 273-3085 Facsimile
E-mail:  aphilp@bigsky.net

NASA GLOBE Program
Education Assistant
http://www.globe.gov

Emphases: Landscape Ecology/Visualization, Cultural/Historical
Geography, Environmental Education/Policy

Ph.D. Research:
"A Landscape History of the Lubrecht Experimental Forest and Adjacent
Lands, Blackfoot Watershed, Montana:
500 Years of Change in the Forest Mosaic as a Result of Cultural and
Biophysical Processes"

********************************************************************************************



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 00:59:45 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA21920 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 00:49:24 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id AAA21893 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 00:49:23 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA2507601
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 00:49:23 -0700 (PDT)
Received: from cupid.dt.nchc.gov.tw (cupid.dt.nchc.gov.tw [140.110.33.240]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id AAA27622
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 00:48:29 -0700 (PDT)
	mail_from (c00chu00@nchc.gov.tw)
Received: from nchc.gov.tw (elc044.dt.nchc.gov.tw [140.110.12.28])
	by cupid.dt.nchc.gov.tw (8.8.5/8.8.5) with ESMTP id PAA16397
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 15:49:42 +0800 (CST)
Received: (from c00chu00@localhost)
	by nchc.gov.tw (8.8.5/8.8.5) id PAA00882
	for info-performer@sgi.com; Thu, 16 Apr 1998 15:49:35 +0800 (CST)
From: Sam Chu <c00chu00@nchc.gov.tw>
Message-Id: <199804160749.PAA00882@nchc.gov.tw>
Subject: spotlight
To: info-performer@sgi.com
Date: Thu, 16 Apr 1998 15:49:35 +0800 (CST)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O


Dear Performers:

  I use perfly source codes to test function of SpotLight.
I set tod=0(time of day)and add a second light by "perfly 
-l 0,0,1000,1,1,1 town.flt"

  Or so I change the source code:

    {
	pfLightSource *lamp = pfNewLSource();

	pfLSourcePos(lamp,
	     ViewState->lampXYZ[i][0],  /* = 0 */
	     ViewState->lampXYZ[i][1],  /* = 0 */
	     ViewState->lampXYZ[i][2],  /* = 1000 */
	     1.0f); /* I change infinite light to local light here*/

        /* I add the following two lines for spotlight */
        pfSpotLSourceDir(lamp, 0.0f, 0.0f, -1.0f);
        pfSpotLSourceCone(lamp, 1.0f, 15.0f);

	/* set light source color */
	pfLSourceColor(lamp,PFLT_DIFFUSE,
		       ViewState->lampRGB[i][0]  /* =1 */,
		       ViewState->lampRGB[i][1],  /* =1 */
		       ViewState->lampRGB[i][2]);  /* =1 */

        pfLSourceOn(lamp);

	/* add lamp to scene */
	pfAddChild(scene, lamp);
     }

     but it did not have any spotlight effect. Did I do anything wrong?
     Should the spotlight be local light?

     Thank you for your answer.


Sam Chu 
National Center for High-Performance Computing 
Scientific Visualization Lab  Email: c00chu00@nchc.gov.tw 
Tel: (886)35-776085 Ext 248   Fax  : (886)35-773538
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 00:59:46 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA21949 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 00:51:25 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id AAA21922 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 00:51:22 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA12341308
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 00:51:18 -0700 (PDT)
Received: from mail.inreach.com (mail.inreach.com [209.142.0.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id AAA28267
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 00:51:16 -0700 (PDT)
	mail_from (lwillis@inreach.com)
Received: from get (209-142-17-7.oak.inreach.net [209.142.17.7]) by mail.inreach.com (8.8.8/8.8.6/(InReach)) with ESMTP id AAA15110; Thu, 16 Apr 1998 00:46:41 -0700 (PDT)
Message-Id: <199804160746.AAA15110@mail.inreach.com>
Reply-To: <lwillis@inreach.com>
From: "Lee Willis" <lwillis@inreach.com>
To: <db@ParadigmSim.com>
Cc: <trdecarlo@tasc.com>, <info-performer@sgi.com>
Subject: Re: Constructing pfASD
Date: Thu, 16 Apr 1998 00:47:30 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1162
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Status: O

> > Dan is talking about having a preconstructed polygonal database at the
best
> > LOD,
> > and then trying to derive coarser LODs from that set of polygons --
can't
> > be done.
> > 
> > You're talking about starting from elevation data -- that *can* be
done.
> > Multigen CAT
> > does it, or you can write you're own.
> > 
> > In very broad strokes, here's how:

[algorithm snipped]
 
> So, if one modified this algorithm to insert only points from the source
> TIN instead of from the source DEM, one could arrive at the source TIN!
> This may not be straight forward, but possible.

As others pointed out -- a TIN is more than sum of all it's points.  You
also
must have all the same edges connected to the same points.  This cannot
be guaranteed with an arbitrary mesh.


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 01:42:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA22170 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 01:33:13 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id BAA22143 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 01:33:12 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id BAA12566930
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 01:33:11 -0700 (PDT)
Received: from post.mail.demon.net (post-10.mail.demon.net [194.217.242.39]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id BAA06890
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 01:33:09 -0700 (PDT)
	mail_from (gordon@apollo13.demon.co.uk)
Received: from apollo13.demon.co.uk ([158.152.181.251]) by post.mail.demon.net
           id aa1003535; 16 Apr 98 8:24 GMT
From: Gordon Tomlinson <gordon@apollo13.demon.co.uk>
To: Sam Chu <c00chu00@nchc.gov.tw>
Cc: info-performer@sgi.com
Subject: Re: spotlight
Date: Thu, 16 Apr 1998 08:25:18 GMT
Reply-To: gordon@apollo13.demon.co.uk
Message-ID: <3537bfb0.7326645@post.demon.co.uk>
References: <199804160749.PAA00882@nchc.gov.tw>
In-Reply-To: <199804160749.PAA00882@nchc.gov.tw>
X-Mailer: Forte Agent 1.5/32.450
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Status: O

Hi

What's the geometry you are trying to illuminate?

 if the cone is falling within a polygon you will not
see an effect, you need quite afine mesh if it is
a floor/wall etc ...

TTFN

>
>Dear Performers:
>
>  I use perfly source codes to test function of SpotLight.
>I set tod=3D0(time of day)and add a second light by "perfly=20
>-l 0,0,1000,1,1,1 town.flt"
>
>  Or so I change the source code:
>
>    {
>	pfLightSource *lamp =3D pfNewLSource();
>
>	pfLSourcePos(lamp,
>	     ViewState->lampXYZ[i][0],  /* =3D 0 */
>	     ViewState->lampXYZ[i][1],  /* =3D 0 */
>	     ViewState->lampXYZ[i][2],  /* =3D 1000 */
>	     1.0f); /* I change infinite light to local light here*/
>
>        /* I add the following two lines for spotlight */
>        pfSpotLSourceDir(lamp, 0.0f, 0.0f, -1.0f);
>        pfSpotLSourceCone(lamp, 1.0f, 15.0f);
>
>	/* set light source color */
>	pfLSourceColor(lamp,PFLT_DIFFUSE,
>		       ViewState->lampRGB[i][0]  /* =3D1 */,
>		       ViewState->lampRGB[i][1],  /* =3D1 */
>		       ViewState->lampRGB[i][2]);  /* =3D1 */
>
>        pfLSourceOn(lamp);
>
>	/* add lamp to scene */
>	pfAddChild(scene, lamp);
>     }
>
>     but it did not have any spotlight effect. Did I do anything wrong?
>     Should the spotlight be local light?
>
>     Thank you for your answer.
>
>
>Sam Chu=20
>National Center for High-Performance Computing=20
>Scientific Visualization Lab  Email: c00chu00@nchc.gov.tw=20
>Tel: (886)35-776085 Ext 248   Fax  : (886)35-773538
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>            Submissions:  info-performer@sgi.com
>        Admin. requests:  info-performer-request@sgi.com

Gordon Tomlinson   =20
System Manager
PERA VR
Technology Centre
Nottingham Road
Melton Mowbray
Leicestershire
LE13 0PB
U.K.
***************************************************************
Tel:	01664 501 501=20
=46ax:	01664 501 553
Email: 	gordon@apollo13.demon.co.uk
Email: 	gordon_tomlinson@peragroup.com
WWW:	http://www.apollo13.demon.co.uk
***************************************************************
NOTE: ALL views, opinions, Comments etc are solely personal and
DO NOT in any way reflect the opinion or view of my employers=20
***************************************************************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 02:28:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA22392 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 02:12:29 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id CAA22365 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 02:12:24 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA11040213
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 02:12:23 -0700 (PDT)
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.3.16]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id CAA14663
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 02:12:22 -0700 (PDT)
	mail_from (wsherman@ncsa.uiuc.edu)
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.3.15])
	by ex1.ncsa.uiuc.edu (8.8.8/8.8.8) with ESMTP id EAA04593
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 04:12:20 -0500 (CDT)
Received: from space.ncsa.uiuc.edu (space.ncsa.uiuc.edu [141.142.4.10])
	by mx1.ncsa.uiuc.edu (8.8.8/8.8.8) with ESMTP id EAA21436;
	Thu, 16 Apr 1998 04:12:19 -0500 (CDT)
From: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
Received: (from wsherman@localhost)
          by space.ncsa.uiuc.edu (8.8.4/8.8.4)
	  id EAA02588; Thu, 16 Apr 1998 04:13:27 -0500 (CDT)
Date: Thu, 16 Apr 1998 04:13:27 -0500 (CDT)
Message-Id: <199804160913.EAA02588@space.ncsa.uiuc.edu>
To: info-performer@sgi.com
Subject: Trying to run pre 2.2 apps on a 2.2 machine -- something's wrong
Cc: slevy@ncsa.uiuc.edu, wsherman@ncsa.uiuc.edu
Status: O


Performers,

[Okay, after my recent posting of the "easy" question -- which
I figured would be easy because I expected the answer to be "No,
can't be done" -- I'm now sending my "hard" question with lots
of information.  Perhaps it's too much, but seems to be a serious
problem with trying to operate in an environment with applications
compiled with different versions of Performer, and I would guess
that there are others in the same predicament.]


After a couple of recent upgrades on one of our Onyxes, I have a
question regarding the way to get older Performer applications
to continue to run:  What is the way to get older Performer
applications to continue to run?

Here are some details:

Our Onyx's overall system was upgraded to a special R10K version
of IRIX 6.2 in February.  Things seemed so be okay following that.
Not long afterward, Performer 2.2 was installed (prior to this
installation, it had Performer 2.1, with comptatibility modules
for 1.2 and 2.0 apps).  I'm pretty sure all the apps we were
running were some flabor of 2.0 or 2.1 (is there a string that
is embedded in the executable that would give specific information?).

After 2.2 was installed, many applications simply failed to work,
or work properly (ie. some just crashed, others came up, but with
all the objects missing, or severely deformed).  The deformed objects
were mostly (if not entirely) Inventor objects.

I've heard that there is a missing loader for Inventor objects
under 2.2, but since these are pre-2.2 apps, I don't understand
why they would begin to fail.  But that does seem to be related
to the problem.  Many of the following errors are reported for
one particular application:

! PF Warning/Usage:              pfAddChild: Bad child 0x0.
! PF Warning:                    pfdFindConverterDSO() - Could not load DSO for extension "iv20"
! PF Warning:                    pfdFindConverterDSO() - Could not load DSO for extension "iv"
! PF Warning:                    pfdLoadFile() - Unable to load file sun.wrl because of problem finding pfdLoadFile_wrl


Looking at the installed products, I found:

! I  performer_eoe.compatO32.performer1_2  02/12/98  Performer1.2 Compatibility DSOs (o32)
! I  performer_eoe.compatO32.performer2_0  02/12/98  Performer2.0.5 [2.0-2.0.4] Compatibility DSOs (o32)
! I  performer_eoe.compatO32.performer2_1  02/12/98  Performer2.1.3 [2.1-2.1.2] Compatibility DSOs (o32)

among others.  Though I did notice that there are compat.sw{32,64},
listings for performer2_0_1, but not 2.1.


Probably the most interesting thing is what we found in /usr/lib.
For all the performer so libraries, there are multiple versions
ending in .2 .3 and .4.  Presumably the ".4" files are for Performer
2.2 (there are no ".4" libraries on our other Oynx that does not
have 2.2 installed).  However, examing the usage dates (ls -lu) in
/usr/lib/libpfdb indicates that running per 2.2 applications accesses
the ".4" files, and not the others.  Further, the access comes via
softlinks that point to a file that ends in just ".so" and links
to the ".so.4" version.

So apparently, all our performer applications are using whatever
are the generic default shared libraries on a given machine,
regardless of which version they were compiled with.  I was under
the impression that the backward compatibility products would
handle this appropriately.

Anyway, as a partial solution, we made some new subdirectories
in /usr/lib containing a list of all the shared object libraries,
and linking to either ".2", ".3" or ".4" files -- ie. one directory
links to all the ".2" files, etc.  Then by setting the LD_LIBRARY_PATH
environment variable to one of these directorys and running the
applications, they now work -- almost.  The objects are all of the
correct shape, and texture maps seem to work properly (except for
transparency), but objects that are colored by other means (ie.
material specifications) just show up as grey.


>From another recent message to info-performer, I gather there is
a compile flag that allows one to specify specifically which
shared objects will be used at run-time.  However, while this
may help for a couple of cases, we also run applications sent
to us by other parties, and which we cannot compile locally.


... [time passes]

After some more research, we find that the dsos for the same library
are actually different on each of the two machines.

Looking at just the main libpf_ogl library on each of two machines, where
the one running 2.1 works, and the one with 2.2 has problems running older
applicaitons:

machine_at_2.1% showfiles | grep usr/lib/libpf_ogl.so
l     0     0 patchSG0001696.performer_eoe_sw.ogl_performer   usr/lib/libpf_ogl.so
l     0     0 performer_eoe.sw.ogl_performer   usr/lib/libpf_ogl.so
f  5701 3936408 patchSG0001696.performer_eoe_sw.ogl_performer   usr/lib/libpf_ogl.so.2
f 63401 3931792 performer_compat.sw.performer2_0_1   usr/lib/libpf_ogl.so.2
f 28704 4536640 performer_eoe.sw.ogl_performer   usr/lib/libpf_ogl.so.3

[where usr/lib/libpf_ogl.so links to usr/lib/libpf_ogl.so.3]

and:

machine_at_2.2% showfiles | grep usr/lib/libpf_ogl.so
l     0     0 performer_eoe.swO32.ogl_performer   usr/lib/libpf_ogl.so
f 52895 3931792 performer_compat.sw.performer2_0_1   usr/lib/libpf_ogl.so.2
f 28670 3941708 performer_eoe.compatO32.performer2_0   usr/lib/libpf_ogl.so.2
f 49284 4550080 performer_eoe.compatO32.performer2_1   usr/lib/libpf_ogl.so.3
f 59247 6661200 performer_eoe.swO32.ogl_performer   usr/lib/libpf_ogl.so.4

[where usr/lib/libpf_ogl.so links to usr/lib/libpf_ogl.so.4]

In these two cases, both machines are Onyx1s with R10K cpus and two IRs.


Also, I guess I haven't quite figured out the syntax for LD_LIBRARY_PATH,
because when I do something like:

% setenv LD_LIBRARY_PATH /usr/lib/libpf_ogl3_pic:/usr/lib/libpfdbso3

before running my app, and then do an "ls -u on these directories and
on /usr/lib, it indicates that the libraries in /usr/lib were accessed
instead -- with the resultant incorrect rendering (grey objects and no
transparency).


And just to state it explicitly, yes some of the problems go away when
the applications are recompiled in 2.2, but that's not an acceptable
solution.  For one thing, we don't have the source to all the apps
we run, and for another thing, we've only upgraded one machine to
2.2 thus far, and except for evaluating 2.2, most of the time, apps
will be compiled on 2.1 or earlier so they can run on a range of
machines.


Please help.

	Thanks,
	Bill

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 03:05:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA22494 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 02:44:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id CAA22467 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 02:44:30 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA11858909
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 02:44:30 -0700 (PDT)
Received: from cupid.dt.nchc.gov.tw (cupid.dt.nchc.gov.tw [140.110.33.240]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id CAA20370
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 02:43:17 -0700 (PDT)
	mail_from (c00chu00@nchc.gov.tw)
Received: from nchc.gov.tw (elc044.dt.nchc.gov.tw [140.110.12.28])
	by cupid.dt.nchc.gov.tw (8.8.5/8.8.5) with ESMTP id PAA16397
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 15:49:42 +0800 (CST)
Received: (from c00chu00@localhost)
	by nchc.gov.tw (8.8.5/8.8.5) id PAA00882
	for info-performer@sgi.com; Thu, 16 Apr 1998 15:49:35 +0800 (CST)
From: Sam Chu <c00chu00@nchc.gov.tw>
Message-Id: <199804160749.PAA00882@nchc.gov.tw>
Subject: spotlight
To: info-performer@sgi.com
Date: Thu, 16 Apr 1998 15:49:35 +0800 (CST)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O


Dear Performers:

  I use perfly source codes to test function of SpotLight.
I set tod=0(time of day)and add a second light by "perfly 
-l 0,0,1000,1,1,1 town.flt"

  Or so I change the source code:

    {
	pfLightSource *lamp = pfNewLSource();

	pfLSourcePos(lamp,
	     ViewState->lampXYZ[i][0],  /* = 0 */
	     ViewState->lampXYZ[i][1],  /* = 0 */
	     ViewState->lampXYZ[i][2],  /* = 1000 */
	     1.0f); /* I change infinite light to local light here*/

        /* I add the following two lines for spotlight */
        pfSpotLSourceDir(lamp, 0.0f, 0.0f, -1.0f);
        pfSpotLSourceCone(lamp, 1.0f, 15.0f);

	/* set light source color */
	pfLSourceColor(lamp,PFLT_DIFFUSE,
		       ViewState->lampRGB[i][0]  /* =1 */,
		       ViewState->lampRGB[i][1],  /* =1 */
		       ViewState->lampRGB[i][2]);  /* =1 */

        pfLSourceOn(lamp);

	/* add lamp to scene */
	pfAddChild(scene, lamp);
     }

     but it did not have any spotlight effect. Did I do anything wrong?
     Should the spotlight be local light?

     Thank you for your answer.


Sam Chu 
National Center for High-Performance Computing 
Scientific Visualization Lab  Email: c00chu00@nchc.gov.tw 
Tel: (886)35-776085 Ext 248   Fax  : (886)35-773538
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 03:23:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA22594 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 03:02:52 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id DAA22567 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 03:02:51 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id DAA11100391
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 03:02:51 -0700 (PDT)
Received: from rose.engr.sgi.com ([150.166.37.6]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id DAA24009
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 03:02:50 -0700 (PDT)
	mail_from (src@rose.engr.sgi.com)
Received: (from src@localhost) by rose.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA25612; Thu, 16 Apr 1998 03:02:49 -0700
Date: Thu, 16 Apr 1998 03:02:49 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9804160302.ZM25610@rose.engr.sgi.com>
In-Reply-To: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
        "Trying to run pre 2.2 apps on a 2.2 machine -- something's wrong" (Apr 16,  4:13am)
References: <199804160913.EAA02588@space.ncsa.uiuc.edu>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>,
        info-performer@sgi.com
Subject: Re: Trying to run pre 2.2 apps on a 2.2 machine -- something's wrong
Cc: slevy@ncsa.uiuc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

+>---- On Apr 16,  4:13am, William Sherman -Visualization wrote:
> Subject: Trying to run pre 2.2 apps on a 2.2 machine -- something's wrong
->From guest@holodeck  Thu Apr 16 02:29:16 1998
->

Bill,

The short of if is that I think there is probably a simple explanation
to the behavior that you are seeing and hopefully a little info on
how DSOs work will help you clear it up.  Otherwise, you should call
the TAC for help.

Executables will use the version of performer libs that they are
marked with for that lib.  
% elfdump -L on an executable shows you the libraries by that program
and their needed version numbers.
Unless compiled with special flags, only the major part of the number 
matters.  This major number is what is appended to the library name.
At runtime, rld will look for libname.so.# where # is that major number.
The default libname.so links _only_ matter for the development 
environment and determine what you by default compile against.



->After a couple of recent upgrades on one of our Onyxes, I have a
->question regarding the way to get older Performer applications
->to continue to run:  What is the way to get older Performer
->applications to continue to run?

The compat libs for previous versions include the versioned libs 
and old programs will automatically find them.

->After 2.2 was installed, many applications simply failed to work,
->or work properly (ie. some just crashed, others came up, but with
->all the objects missing, or severely deformed).  The deformed objects
->were mostly (if not entirely) Inventor objects.

There could be a lot to chase here so I won't make guesses - one thing
at a time.  Depending on what you were running before, it is possible
that we linked against a newer version of Inventor or some other library
that has now tickled something.  Or, could be something entirely 
_else_ - read on below.
Again, focus on resolving one thing at a time and don't assume it is 
all related.

->I've heard that there is a missing loader for Inventor objects
->under 2.2, but since these are pre-2.2 apps, I don't understand

What ????  I haven't!  :-)

->why they would begin to fail.  But that does seem to be related
->to the problem.  Many of the following errors are reported for
->one particular application:
->
->! PF Warning/Usage:              pfAddChild: Bad child 0x0.

This is not good but could be a result of some other failure - like
a file didn't load and the app didn't deal with that failure in a graceful
way and this was the result.

->! PF Warning:                    pfdFindConverterDSO() - Could not load DSO for extension "iv20"
->! PF Warning:                    pfdFindConverterDSO() - Could not load DSO for extension "iv"

This sez it couldn't load the DSO but it could be that the DSO is there but
not some other library that it needs.  We don't get enough back from rld
to tell the difference for our print message.  This could be that you need
to upgrade your verion of IL, IFL, or Inventor.  To debug this,
setenv PFLD_LIBRARY_PATH .
setenv PFNFYLEVEL 9
run your app and you should get more verbose info.
My guess though is that we compiled against a newer version of some lib for
loeading textures that you don't have.
You can also run elfdump -L on any lib.so.# to see what libs it requires.
Different loaders have different requirements.  We only put reqs on stuff
that does ship with IRIX, but that doesn't guarantee that you have it
installed on your system.


->! PF Warning:                    pfdLoadFile() - Unable to load file sun.wrl because of problem finding pfdLoadFile_wrl
->
->Looking at the installed products, I found:
->

This was a separate and known problem and the wrl loader is new in 2.2.
The trouble is that this loader fails becuase of a file it is looking for
in /usr/lib/ and the file is actually in /usr/lib/libpfdb/.perfLoader.wrl.
Link that into your /usr/lib to fix that specific issue.

->! I  performer_eoe.compatO32.performer1_2  02/12/98  Performer1.2 Compatibility DSOs (o32)
->! I  performer_eoe.compatO32.performer2_0  02/12/98  Performer2.0.5 [2.0-2.0.4] Compatibility DSOs (o32)
->! I  performer_eoe.compatO32.performer2_1  02/12/98  Performer2.1.3 [2.1-2.1.2] Compatibility DSOs (o32)
->
->among others.  Though I did notice that there are compat.sw{32,64},
->listings for performer2_0_1, but not 2.1.

They are included in the CD so for some reason they were not installed.

->
->Probably the most interesting thing is what we found in /usr/lib.
->For all the performer so libraries, there are multiple versions
->ending in .2 .3 and .4.  Presumably the ".4" files are for Performer
->2.2 (there are no ".4" libraries on our other Oynx that does not

Yes.

->have 2.2 installed).  However, examing the usage dates (ls -lu) in
->/usr/lib/libpfdb indicates that running per 2.2 applications accesses
->the ".4" files, and not the others.  Further, the access comes via
->softlinks that point to a file that ends in just ".so" and links
->to the ".so.4" version.
->
->So apparently, all our performer applications are using whatever
->are the generic default shared libraries on a given machine,

Definitely not - but hopefully from the above this is clear now.

->regardless of which version they were compiled with.  I was under
->the impression that the backward compatibility products would
->handle this appropriately.
->
->Anyway, as a partial solution, we made some new subdirectories
->in /usr/lib containing a list of all the shared object libraries,
->and linking to either ".2", ".3" or ".4" files -- ie. one directory
->links to all the ".2" files, etc.  Then by setting the LD_LIBRARY_PATH
->environment variable to one of these directorys and running the
->applications, they now work -- almost.  The objects are all of the
->correct shape, and texture maps seem to work properly (except for
->transparency), but objects that are colored by other means (ie.
->material specifications) just show up as grey.

I can't quite tell what you fixed here but don't mix your run-time version 
problems with what cause causing objects to have bad shape.
A pfApp compiled with a lib.so.2 lib will
allways use a .2 lib or else it won't run at all.  
What could cause bogus problems is if you have some object files of an app
compiled against one version of Performer and some object files 
compiled against another.  The versioning only gets done at the final
link.  Different versions of Performer are NOT binary compatible 
(which is why we did all of the versioning).  So, if you mixed 
compiles of object files of anything that included any Performer
header file, I'd expect you to see the garbage you describe.
At this point, I am guessing that this is what really happened to you.
So, you don't need separate directories for your run-time execution,
you need them for your compiles.  However, do NOT start messing
with the links and directory structure because then future installs
will break you.  If you need to be able to compile against different
versions of Performer, install them into different roots with the inst -r 
option and when you compile set your $PFROOT to the right top level pfDir.
Note, this is NOT necessary for running the apps, just compiling.

If you have been doing a lot of potentially confused mixed compiles
on different machines with different versions without totally clobbering
before switching machines and versions, then at this point you probably can't 
trust anything and should totally clobber and rebuild against one
clean version of Performer.

Again, I think that there should be a fairly straightforward 
set of explainations to the problems you are having so if things
do not quickly become clear, please call the TAC to have someone
help walk you through things.

Good luck!
src.

-- 
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src@sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 08:40:20 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA23276 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 08:22:11 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA23249 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 08:22:10 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA12688430
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 08:22:09 -0700 (PDT)
Received: from jota.rrk-berlin.de (jota.rrk-berlin.de [194.94.4.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id IAA12270
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 08:21:46 -0700 (PDT)
	mail_from (mueller_m@rrk-berlin.de)
Received: from onyx.rrk-berlin.de by jota.rrk-berlin.de (5.65v3.2/1.1.10.5/12Dec97-0614PM)
	id AA02573; Thu, 16 Apr 1998 17:22:12 +0200
Sender: markm@rrk-berlin.de
Message-Id: <3536A0C6.4C9C85B8@rrk-berlin.de>
Date: Thu, 16 Apr 1998 17:22:30 -0700
From: Mark Mueller <mueller_m@rrk-berlin.de>
Organization: SRU OP2000
X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX64 6.2 IP19)
Mime-Version: 1.0
To: "info-performer@sgi.com" <info-performer@sgi.com>
Subject: Stereo Grabbing Application needed !
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi,

is it possible to make a performer application have stereo display on
two pipes ? We have
an SGI Onyx with three pipes and two Sirius Boards for frame Grabbing.
Now I want a 3D Scene
(in Inventor format for example) to be displayed seperately for the left
eye and for the right eye on two
pipes. We then can grab these two images and display it with a shutter
projector and shutter glasses.

I saw that Perfly can understand Inventor Format. I think, that I just
need to open a second window on another display and display the same
scene with a little offset from the same viewpoint.
I'm a newbie to Performer. Has someone sample code or hints for me ?

Thanx in Advance,

Mark Mueller

--
----------------------------------------------------------------
Mark Mueller                     /Robert-Roessle-Klinik am
phone; ++49-30-9417-1632         /Max-Delbrueck-Centrum
fax:   ++49-30-9406-3405         /Surgical Research Unit OP 2000
email: mueller_m@rrk-berlin.de   /Lindenberger Weg 80
http://www.rrk-berlin.de/op2000  /D-13122 Berlin
----------------------------------------------------------------



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 10:07:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA23509 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 09:53:05 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA23482 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 09:53:04 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA12748316
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 09:53:04 -0700 (PDT)
Received: from physics.ucla.edu (physics.ucla.edu [128.97.23.13]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA21140
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 09:53:03 -0700 (PDT)
	mail_from (mitchell@physics.ucla.edu)
Received: from raman by physics.ucla.edu (SMI-8.6/SMI-SVR4)
	id JAA15970; Thu, 16 Apr 1998 09:52:59 -0700
Received: from localhost by raman (SMI-8.6/SMI-SVR4)
	id JAA14209; Thu, 16 Apr 1998 09:52:59 -0700
Date: Thu, 16 Apr 1998 09:52:59 -0700 (PDT)
From: Chris Mitchell <mitchell@physics.ucla.edu>
To: info-performer@sgi.com
Subject: A bzillion errors
Message-ID: <Pine.GSO.3.96.980416094055.14184A-100000@raman>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


Hi pfFolks --

	We just got a two-processor Octane MXE, and 
I'm trying to port my old performer 2.1 apps from our
Indigo2.  In trying to compile the sample C++ code, I get

% make bench
Linking with motif libraries. setenv PFDOMOTIF 0 to turn off.

making IrisGL DSO version of bench.igldso
Linking with motif libraries. setenv PFDOMOTIF 0 to turn off.
`bench.dsocmd' is up to date.
making symbolic links to DSO versions
        ln -s OPT.N32.IRISGL/bench.dsocmd bench ;
        /usr/bin/CC        -DN32 -DIRIX6_5   -I/usr/include -fullwarn     -nostdinc -I/usr/include/CC -I/usr/include -mips3 -n32 -O  -MDupdate Makedepend -c bench.C
"bench.C", line 729: remark(1174): variable "iv" was declared but never
          referenced
      pfVec3 iv(-1.0f,-1.0f,-1.0f);
             ^

"bench.C", line 1265: warning(1552): variable "have_obj" was set but never used
        static int have_obj = 0;
                   ^

"bench.C": Warning: Olimit was exceeded on function main; will not optimize.
        To optimize use -OPT:Olimit=0 (off) or -OPT:Olimit=2238
"bench.C": Warning: To override Olimit for all functions in file, use -OPT:Olimit=2238
        /usr/bin/cc     -DN32 -DIRIX6_5   -I/usr/include -fullwarn  -nostdinc -I/usr/include -mips3 -n32 -O  -MDupdate Makedepend -woff 1685,515,608,658,799,803,852,1048,1233,1499 bench.o   -mips3 -n32 -quickstart_info -nostdlib -L/usr/lib32/mips3 -L/usr/
lib32     -o bench
ld32: ERROR 33: Unresolved text symbol "pf_indexUpdatable__8pfBufferCGPC11pfUpdatable" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "setAttr__8pfGeoSetGiT1PvPUs" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "getFlux__6pfFluxSGPv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "getCurData__6pfFluxGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "getGState__8pfGeoSetCGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "getAttr__10pfGeoStateCGi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "setFilter__9pfTextureGiT1" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "getImage__9pfTextureCGPPUiPiN32" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "getPrimType__8pfGeoSetCGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "getAttrBind__8pfGeoSetCGi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "getAttrLists__8pfGeoSetCGiPPvPPUs" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "setNumPrims__8pfGeoSetGi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfNotify" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "setDetail__9pfTextureGiP9pfTexture" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "setFormat__9pfTextureGiT1" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuInitTraverser" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuTraverse" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__nwa__GUi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfFilePath" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfNotifyLevel" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfInit" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfGetTime" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfGetSharedArena" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "calloc__8pfMemorySGUiT1Pv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfMultiprocess" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfdInitConverter" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfConfig" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuLockDownProc" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuLockDownApp" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__nw__11pfUpdatableSGUi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__ct__7pfSceneGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfdLoadFile" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfTransparency" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuTravCreatePackedAttrs" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfdMakeShared" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfdMakeSharedScene" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuMakeTexList" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfGetPipe" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfFrameRate" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfPhase" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__ct__12pfPipeWindowGP6pfPipe" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_config__12pfPipeWindowGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setFBConfigId__12pfPipeWindowGi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfStageConfigFunc" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__ct__9pfChannelGP6pfPipe" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_attach__9pfChannelGP9pfChannel" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setViewport__9pfChannelGfN31" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setTravFunc__9pfChannelGiPGP9pfChannelPv_v" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setScene__9pfChannelGP7pfScene" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setNearFar__9pfChannelGfT1" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_getFStats__9pfChannelGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setClass__12pfFrameStatsGUii" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setAttr__12pfFrameStatsGif" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__ct__10pfEarthSkyGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setMode__10pfEarthSkyGiT1" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setAttr__10pfEarthSkyGif" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setColor__10pfEarthSkyGifN32" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setESky__9pfChannelGP10pfEarthSky" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setFOV__9pfChannelGfT1" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuTravCalcBBox" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setView__9pfChannelGR6pfVec3T1" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfSync" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "cosf" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "sinf" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfFrame" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuFreeAllCPUs" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfGetFrameCount" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_mQuery__12pfFrameStatsGPUiPvi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "sqrtf" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfGetFrameRate" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_drawStats__9pfChannelGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfExit" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuLockDownDraw" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_open__12pfPipeWindowGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfGetCurWSConnection" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "XSelectInput" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "XMapWindow" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "XFlush" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "glDrawBuffer" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfDisable" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfOverride" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfCullFace" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "malloc__8pfMemorySGUiPv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__nw__8pfObjectSGUi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__ct__9pfTextureGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "setImage__9pfTextureGPUiiN32" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "apply__9pfTextureGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__ct__8pfTexEnvGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "apply__8pfTexEnvGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__ct__7pfLightGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuLockDownCull" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfCull" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfuDownloadTexList" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "on__7pfLightGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_clear__9pfChannelGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "glCallList" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "pfDraw" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "isOfType__8pfMemorySGPCvP6pfType" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "setDrawMode__8pfGeoSetGiT1" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_getChild__7pfGroupCGi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_getSize__12pfPipeWindowGPiT1" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "XEventsQueued" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "XNextEvent" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "glNewList" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "glEndList" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setOriginSize__12pfPipeWindowGiN31" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "XLookupString" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "swapBuffers__8pfWindowGv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "__dl__8pfMemorySGPv" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setSwapFunc__6pfPipeGPGP6pfPipeP12pfPipeWindow_v" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setName__12pfPipeWindowGPCc" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setMode__12pfPipeWindowGiT1" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setWinType__12pfPipeWindowGUi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_setConfigFunc__12pfPipeWindowGPGP12pfPipeWindow_v" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved text symbol "nb_flatten__6pfNodeGi" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved data symbol "classType__7pfGeode" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved data symbol "_pfCurrentBuffer" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved data symbol "classType__8pfMemory" -- 1st referenced by bench.o.
ld32: ERROR 33: Unresolved data symbol "classType__7pfGroup" -- 1st referenced by bench.o.
ld32: INFO 152: Output file removed because of error.
*** Error code 2
smake: Error: 1 error




Any ideas?




Chris Mitchell
UCLA Physics Department
LAPD Plasma Lab
310-206-1772
chrism@ucla.edu

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 10:44:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA23631 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 10:25:02 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA23600 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 10:25:00 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA12797764
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 10:24:59 -0700 (PDT)
Received: from quid.engr.sgi.com ([130.62.52.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id KAA04390
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 10:24:58 -0700 (PDT)
	mail_from (robj@quid.engr.sgi.com)
Received: (from robj@localhost) by quid.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA08778; Thu, 16 Apr 1998 10:24:57 -0700
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9804161024.ZM8776@quid.engr.sgi.com>
Date: Thu, 16 Apr 1998 10:24:57 -0700
In-Reply-To: Chris Mitchell <mitchell@physics.ucla.edu>
        "A bzillion errors" (Apr 16,  9:52am)
References: <Pine.GSO.3.96.980416094055.14184A-100000@raman>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Chris Mitchell <mitchell@physics.ucla.edu>, info-performer@sgi.com
Subject: Re: A bzillion errors
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 16,  9:52am, Chris Mitchell wrote:
> Subject: A bzillion errors
>
> Hi pfFolks --
>
> 	We just got a two-processor Octane MXE, and
> I'm trying to port my old performer 2.1 apps from our
> Indigo2.  In trying to compile the sample C++ code, I get
>

Chris

What version of performer do you have on the OCTANE ? If it's 2.1 then this
compile is trying to do IrisGL and 2.1 only has OpenGL libs...

Whatever version you have try 'make clobber' and 'make clean' then compile,
also try compiling opengl to see how that goes, you ought to use opengl on the
OCTANE anyway.

If you not sure on the version do versions | grep -i performer and make sure
you don't have something obviously screwy like eoe from one version and dev
from another, if it doesn't look right do versions remove of all performer and
then reinstall a clean pf 2.2.

Cheers
Rob

> % make bench
> Linking with motif libraries. setenv PFDOMOTIF 0 to turn off.
>
> making IrisGL DSO version of bench.igldso
> Linking with motif libraries. setenv PFDOMOTIF 0 to turn off.
> `bench.dsocmd' is up to date.
> making symbolic links to DSO versions
>         ln -s OPT.N32.IRISGL/bench.dsocmd bench ;
>         /usr/bin/CC        -DN32 -DIRIX6_5   -I/usr/include -fullwarn
    -nostdinc -I/usr/include/CC -I/usr/include -mips3 -n32 -O  -MDupdate
Makedepend -c bench.C
> "bench.C", line 729: remark(1174): variable "iv" was declared but never
>           referenced
>       pfVec3 iv(-1.0f,-1.0f,-1.0f);
>              ^
>
> "bench.C", line 1265: warning(1552): variable "have_obj" was set but never
used
>         static int have_obj = 0;
>                    ^
>
> "bench.C": Warning: Olimit was exceeded on function main; will not optimize.
>         To optimize use -OPT:Olimit=0 (off) or -OPT:Olimit=2238
> "bench.C": Warning: To override Olimit for all functions in file, use
-OPT:Olimit=2238
>         /usr/bin/cc     -DN32 -DIRIX6_5   -I/usr/include -fullwarn  -nostdinc
-I/usr/include -mips3 -n32 -O  -MDupdate Makedepend -woff
1685,515,608,658,799,803,852,1048,1233,1499 bench.o   -mips3 -n32
-quickstart_info -nostdlib -L/usr/lib32/mips3 -L/usr/
> lib32     -o bench
> ld32: ERROR 33: Unresolved text symbol
"pf_indexUpdatable__8pfBufferCGPC11pfUpdatable" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "setAttr__8pfGeoSetGiT1PvPUs" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "getFlux__6pfFluxSGPv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "getCurData__6pfFluxGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "getGState__8pfGeoSetCGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "getAttr__10pfGeoStateCGi" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "setFilter__9pfTextureGiT1" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "getImage__9pfTextureCGPPUiPiN32" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "getPrimType__8pfGeoSetCGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "getAttrBind__8pfGeoSetCGi" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "getAttrLists__8pfGeoSetCGiPPvPPUs" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "setNumPrims__8pfGeoSetGi" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfNotify" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "setDetail__9pfTextureGiP9pfTexture"
-- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "setFormat__9pfTextureGiT1" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuInitTraverser" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuTraverse" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "__nwa__GUi" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfFilePath" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfNotifyLevel" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfInit" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfGetTime" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfGetSharedArena" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "calloc__8pfMemorySGUiT1Pv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfMultiprocess" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfdInitConverter" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfConfig" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuLockDownProc" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuLockDownApp" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "__nw__11pfUpdatableSGUi" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "__ct__7pfSceneGv" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfdLoadFile" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfTransparency" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuTravCreatePackedAttrs" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfdMakeShared" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfdMakeSharedScene" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuMakeTexList" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfGetPipe" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfFrameRate" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfPhase" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "__ct__12pfPipeWindowGP6pfPipe" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_config__12pfPipeWindowGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setFBConfigId__12pfPipeWindowGi"
-- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfStageConfigFunc" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "__ct__9pfChannelGP6pfPipe" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_attach__9pfChannelGP9pfChannel" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setViewport__9pfChannelGfN31" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol
"nb_setTravFunc__9pfChannelGiPGP9pfChannelPv_v" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setScene__9pfChannelGP7pfScene" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setNearFar__9pfChannelGfT1" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_getFStats__9pfChannelGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setClass__12pfFrameStatsGUii" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setAttr__12pfFrameStatsGif" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "__ct__10pfEarthSkyGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setMode__10pfEarthSkyGiT1" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setAttr__10pfEarthSkyGif" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setColor__10pfEarthSkyGifN32" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setESky__9pfChannelGP10pfEarthSky"
-- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setFOV__9pfChannelGfT1" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuTravCalcBBox" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setView__9pfChannelGR6pfVec3T1" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfSync" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "cosf" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "sinf" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfFrame" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuFreeAllCPUs" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfGetFrameCount" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_mQuery__12pfFrameStatsGPUiPvi" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "sqrtf" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfGetFrameRate" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_drawStats__9pfChannelGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfExit" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuLockDownDraw" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_open__12pfPipeWindowGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfGetCurWSConnection" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "XSelectInput" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "XMapWindow" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "XFlush" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "glDrawBuffer" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfDisable" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfOverride" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfCullFace" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "malloc__8pfMemorySGUiPv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "__nw__8pfObjectSGUi" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "__ct__9pfTextureGv" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "setImage__9pfTextureGPUiiN32" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "apply__9pfTextureGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "__ct__8pfTexEnvGv" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "apply__8pfTexEnvGv" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "__ct__7pfLightGv" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuLockDownCull" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfCull" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfuDownloadTexList" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved text symbol "on__7pfLightGv" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_clear__9pfChannelGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "glCallList" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "pfDraw" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "isOfType__8pfMemorySGPCvP6pfType" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "setDrawMode__8pfGeoSetGiT1" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_getChild__7pfGroupCGi" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_getSize__12pfPipeWindowGPiT1" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "XEventsQueued" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "XNextEvent" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "glNewList" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "glEndList" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol
"nb_setOriginSize__12pfPipeWindowGiN31" -- 1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "XLookupString" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "swapBuffers__8pfWindowGv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "__dl__8pfMemorySGPv" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol
"nb_setSwapFunc__6pfPipeGPGP6pfPipeP12pfPipeWindow_v" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setName__12pfPipeWindowGPCc" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setMode__12pfPipeWindowGiT1" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_setWinType__12pfPipeWindowGUi" --
1st referenced by bench.o.
> ld32: ERROR 33: Unresolved text symbol
"nb_setConfigFunc__12pfPipeWindowGPGP12pfPipeWindow_v" -- 1st referenced by
bench.o.
> ld32: ERROR 33: Unresolved text symbol "nb_flatten__6pfNodeGi" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved data symbol "classType__7pfGeode" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved data symbol "_pfCurrentBuffer" -- 1st referenced
by bench.o.
> ld32: ERROR 33: Unresolved data symbol "classType__8pfMemory" -- 1st
referenced by bench.o.
> ld32: ERROR 33: Unresolved data symbol "classType__7pfGroup" -- 1st
referenced by bench.o.
> ld32: INFO 152: Output file removed because of error.
> *** Error code 2
> smake: Error: 1 error
>
>
>
>
> Any ideas?
>
>
>
>
> Chris Mitchell
> UCLA Physics Department
> LAPD Plasma Lab
> 310-206-1772
> chrism@ucla.edu
>
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from Chris Mitchell



-- 
________________________________________________________________
Rob Jenkins mailto:robj@sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 11:12:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA23785 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 10:55:01 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA23758 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 10:55:00 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA12747501
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 10:54:59 -0700 (PDT)
Received: from physics.ucla.edu (physics.ucla.edu [128.97.23.13]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id KAA16899
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 10:54:58 -0700 (PDT)
	mail_from (mitchell@physics.ucla.edu)
Received: from raman by physics.ucla.edu (SMI-8.6/SMI-SVR4)
	id KAA17416; Thu, 16 Apr 1998 10:54:56 -0700
Received: from localhost by raman (SMI-8.6/SMI-SVR4)
	id KAA14612; Thu, 16 Apr 1998 10:54:56 -0700
Date: Thu, 16 Apr 1998 10:54:55 -0700 (PDT)
From: Chris Mitchell <mitchell@physics.ucla.edu>
To: info-performer@sgi.com
Subject: Re: A bzillion errors
In-Reply-To: <9804161339.ZM20894@burkina>
Message-ID: <Pine.GSO.3.96.980416105211.14603A-100000@raman>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

> >         /usr/bin/cc     -DN32 -DIRIX6_5   -I/usr/include -fullwarn
>  -nostdinc -I/usr/include -mips3 -n32 -O  -MDupdate Makedepend -woff
> 1685,515,608,658,799,803,852,1048,1233,1499 bench.o   -mips3 -n32
> -quickstart_info -nostdlib -L/usr/lib32/mips3 -L/usr/
> > lib32     -o bench
> > ld32: ERROR 33: Unresolved text symbol
> 
> Looks like you're missing a few libraries in the link line in the Makefile.
> 
> You need to add at least these (for IRIS GL, right?):
> 	-lpf_igl
> 	-lgl
> 	-lX11
> 	-lm
> 
> Amit

Thanks to everyone for responding.  Scott said something like this
too.  I thought that Performer 2.2's makefiles would have the necessary
libraries referenced... guess not.



Chris Mitchell
UCLA Physics Department
LAPD Plasma Lab
310-206-1772
chrism@ucla.edu

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 11:48:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA24026 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 11:26:22 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA23999 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 11:26:21 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA12818722
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 11:26:20 -0700 (PDT)
Received: from kronos (kronos.gup.uni-linz.ac.at [140.78.104.11]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA00745
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 11:26:15 -0700 (PDT)
	mail_from (pachler@marvin.gup.uni-linz.ac.at)
Received: from localhost (pachler@localhost) by kronos (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id UAA02263 for <info-performer@sgi.com>; Thu, 16 Apr 1998 20:26:29 +0200
Date: Thu, 16 Apr 1998 20:26:28 +0200 (CEST)
From: Uwe Pachler <pachler@marvin.gup.uni-linz.ac.at>
X-Sender: pachler@kronos
To: info-performer@sgi.com
Subject: intersection traversal and pfPaths
Message-ID: <Pine.SGI.3.96.980416201443.2255B-100000@kronos>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hi Folks!

What I need from my intersection traversal is not only the node where the
intersection occurred, but also the intersection path. Nothing more easy
than that, I thought, took a look into the manual, and then used 
pfQueryHit(hits[0][0], PFQHIT_PATH, &path);
But I only got an empty path, although the intersection occured and the
node is deeply buried in the scene graph (and I start intersecting at the
scene root).
Here's what I do (the code prints <some> debug info ;-):

	pfHit** hits[1]; 
	pfSegSet iSegs; 
	iSegs.mode = PFTRAV_IS_GSET; 
	pfCopyVec3(iSegs.segs[0].pos, handPosition->pos); 
	pfCopyVec3(iSegs.segs[0].dir, handPosition->dir); 
	iSegs.segs[0].length = handPosition->length; 
	iSegs.userData = NULL; 
	iSegs.activeMask = 0x01; 
	iSegs.isectMask = VRCONTROLABLE_ISECT_MASK; 
	iSegs.bound = NULL; 
	iSegs.discFunc = NULL; 

	if (pfNodeIsectSegs(root, &iSegs, hits) != 0) 
		{
		pfPath* path; 

		pfQueryHit(hits[0][0], PFQHIT_PATH, &path); 

		// this returns zero; and therefore the path seems to be
		//empty...
		int pathLength = pfGetNum(path);
		  

		pfNode* hitNode; 
		
		// returns a valid hitNode
		pfQueryHit(hits[0][0], PFQHIT_NODE, &hitNode);
		}


Maybe someone has some hints for me ;-). Thanx in advance,

	Uwe Pachler

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 12:07:02 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA24203 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 11:48:23 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA24176 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 11:48:21 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA12717816
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 11:48:19 -0700 (PDT)
Received: from challenge (challenge.silicon.cl [200.29.42.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA09215
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 11:48:14 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Thu, 16 Apr 1998 15:47:30 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma017507; Thu, 16 Apr 98 15:44:10 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA03060; Thu, 16 Apr 1998 14:46:54 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA12900; Thu, 16 Apr 1998 14:58:31 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9804161458.ZM12898@krusty>
Date: Thu, 16 Apr 1998 14:58:31 -0400
In-Reply-To: Mark Mueller <mueller_m@rrk-berlin.de>
        "Stereo Grabbing Application needed !" (Apr 16,  5:22pm)
References: <3536A0C6.4C9C85B8@rrk-berlin.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Mark Mueller <mueller_m@rrk-berlin.de>
Subject: Re: Stereo Grabbing Application needed !
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 16,  5:22pm, Mark Mueller wrote:
> Subject: Stereo Grabbing Application needed !
> Hi,
>
> is it possible to make a performer application have stereo display on
> two pipes ? We have
> an SGI Onyx with three pipes and two Sirius Boards for frame Grabbing.
> Now I want a 3D Scene
> (in Inventor format for example) to be displayed seperately for the left
> eye and for the right eye on two
> pipes. We then can grab these two images and display it with a shutter
> projector and shutter glasses.
>
> I saw that Perfly can understand Inventor Format. I think, that I just
> need to open a second window on another display and display the same
> scene with a little offset from the same viewpoint.
> I'm a newbie to Performer. Has someone sample code or hints for me ?
>
> Thanx in Advance,
>
> Mark Mueller
>
> --
> ----------------------------------------------------------------
> Mark Mueller                     /Robert-Roessle-Klinik am
> phone; ++49-30-9417-1632         /Max-Delbrueck-Centrum
> fax:   ++49-30-9406-3405         /Surgical Research Unit OP 2000
> email: mueller_m@rrk-berlin.de   /Lindenberger Weg 80
> http://www.rrk-berlin.de/op2000  /D-13122 Berlin
> ----------------------------------------------------------------
>
>
>
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>
>-- End of excerpt from Mark Mueller
I would think this is possible in hypothetical terms, that is, if you know both
pipes are started at the exact same time, and consistenly and continuosly
render the scene at the exact same rate I guess it could be done, but I would
think you need to add some kind of sync between the two pipes. Why don't just
use quad-buffers (assuming the Sirius can work at 120Hz, and you wanna do 60Hz
 which I don't really know)



-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Andres Bello 2777, Of. 602
E-mail: asaez@silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 105       Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 16 12:32:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA24304 for info-performer-dist@holodeck.engr.sgi.com; Thu, 16 Apr 1998 12:08:23 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA24277 for <info-performer@holodeck.engr.sgi.com>; Thu, 16 Apr 1998 12:08:22 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA10523364
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 16 Apr 1998 12:08:21 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA17410
	for <info-performer@sgi.com>; Thu, 16 Apr 1998 12:08:20 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA10912378
	for <@cthulhu.engr.sgi.com:info-performer@sgi.com>;
	Thu, 16 Apr 1998 12:08:20 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA06487 for <info-performer@sgi.com>; Thu, 16 Apr 1998 12:08:20 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35365723.D396A54C@sgi.com>
Date: Thu, 16 Apr 1998 12:08:19 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Unsubscribing from info-performer
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Every email that's sent out on this list has an administration address
appended.

Please use that address if you need to unsubscribe, otherwise it may not
happen if the list administrator misses your post.

Cheers,Angus.
-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 17 03:14:39 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA27535 for info-performer-dist@holodeck.engr.sgi.com; Fri, 17 Apr 1998 02:58:17 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id CAA27508 for <info-performer@holodeck.engr.sgi.com>; Fri, 17 Apr 1998 02:58:15 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA12007776
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 17 Apr 1998 02:58:15 -0700 (PDT)
Received: from cupid.dt.nchc.gov.tw (cupid.dt.nchc.gov.tw [140.110.33.240]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id CAA10870
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 02:49:18 -0700 (PDT)
	mail_from (c00chu00@nchc.gov.tw)
Received: from nchc.gov.tw (elc044.dt.nchc.gov.tw [140.110.12.28])
	by cupid.dt.nchc.gov.tw (8.8.5/8.8.5) with ESMTP id RAA29703;
	Fri, 17 Apr 1998 17:49:13 +0800 (CST)
Received: (from c00chu00@localhost)
	by nchc.gov.tw (8.8.5/8.8.5) id RAA01093;
	Fri, 17 Apr 1998 17:49:00 +0800 (CST)
From: Sam Chu <c00chu00@nchc.gov.tw>
Message-Id: <199804170949.RAA01093@nchc.gov.tw>
Subject: Re: spotlight
In-Reply-To: <3537bfb0.7326645@post.demon.co.uk> from Gordon Tomlinson at "Apr 16, 98 08:25:18 am"
To: gordon@apollo13.demon.co.uk
Date: Fri, 17 Apr 1998 17:48:59 +0800 (CST)
Cc: info-performer@sgi.com
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by cthulhu.engr.sgi.com id CAA12873244
Status: O

Dear Mr. Tomlinson:   =20

  I use town demo file. Beside the terrain geometry there are
lots of house. So I think it won't just falling within a polygon.
  Or so I make a terrain which 10*10 m per polygon, but the effect
is just the same.
  I saw the source code "shadows.c" under ~/pguide which very like
what I want to simulate, but did I need a projected texture to=20
simulate a spotlight?


> Hi
>=20
> What's the geometry you are trying to illuminate?
>=20
>  if the cone is falling within a polygon you will not
> see an effect, you need quite afine mesh if it is
> a floor/wall etc ...
>=20
> TTFN
>=20
> >
> >Dear Performers:
> >
> >  I use perfly source codes to test function of SpotLight.
> >I set tod=3D0(time of day)and add a second light by "perfly=20
> >-l 0,0,1000,1,1,1 town.flt"
> >
> >  Or so I change the source code:
> >
> >    {
> >	pfLightSource *lamp =3D pfNewLSource();
> >
> >	pfLSourcePos(lamp,
> >	     ViewState->lampXYZ[i][0],  /* =3D 0 */
> >	     ViewState->lampXYZ[i][1],  /* =3D 0 */
> >	     ViewState->lampXYZ[i][2],  /* =3D 1000 */
> >	     1.0f); /* I change infinite light to local light here*/
> >
> >        /* I add the following two lines for spotlight */
> >        pfSpotLSourceDir(lamp, 0.0f, 0.0f, -1.0f);
> >        pfSpotLSourceCone(lamp, 1.0f, 15.0f);
> >
> >	/* set light source color */
> >	pfLSourceColor(lamp,PFLT_DIFFUSE,
> >		       ViewState->lampRGB[i][0]  /* =3D1 */,
> >		       ViewState->lampRGB[i][1],  /* =3D1 */
> >		       ViewState->lampRGB[i][2]);  /* =3D1 */
> >
> >        pfLSourceOn(lamp);
> >
> >	/* add lamp to scene */
> >	pfAddChild(scene, lamp);
> >     }
> >
> >     but it did not have any spotlight effect. Did I do anything wrong=
?
> >     Should the spotlight be local light?
> >
> >     Thank you for your answer.
> >
> >
> >Sam Chu=20
> >National Center for High-Performance Computing=20
> >Scientific Visualization Lab  Email: c00chu00@nchc.gov.tw=20
> >Tel: (886)35-776085 Ext 248   Fax  : (886)35-773538
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
> >            Submissions:  info-performer@sgi.com
> >        Admin. requests:  info-performer-request@sgi.com
>=20
> Gordon Tomlinson   =20
> System Manager
> PERA VR
> Technology Centre
> Nottingham Road
> Melton Mowbray
> Leicestershire
> LE13 0PB
> U.K.
> ***************************************************************
> Tel:	01664 501 501=20
> Fax:	01664 501 553
> Email: 	gordon@apollo13.demon.co.uk
> Email: 	gordon_tomlinson@peragroup.com
> WWW:	http://www.apollo13.demon.co.uk
> ***************************************************************
> NOTE: ALL views, opinions, Comments etc are solely personal and
> DO NOT in any way reflect the opinion or view of my employers=20
> ***************************************************************
> =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>=20


Sam Chu=20
National Center for High-Performance Computing=20
Scientific Visualization Lab  Email: c00chu00@nchc.gov.tw=20
Tel: (886)35-776085 Ext 248   Fax  : (886)35-773538
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 17 03:49:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA27607 for info-performer-dist@holodeck.engr.sgi.com; Fri, 17 Apr 1998 03:34:30 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id DAA27580 for <info-performer@holodeck.engr.sgi.com>; Fri, 17 Apr 1998 03:34:28 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id DAA13069481
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 17 Apr 1998 03:34:28 -0700 (PDT)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id DAA21196
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 03:34:26 -0700 (PDT)
	mail_from (gordon@apollo13.demon.co.uk)
Received: from apollo13.demon.co.uk ([158.152.181.251]) by post.mail.demon.net
           id aa2025525; 17 Apr 98 10:19 GMT
From: Gordon Tomlinson <gordon@apollo13.demon.co.uk>
To: Sam Chu <c00chu00@nchc.gov.tw>
Cc: info-performer@sgi.com
Subject: Re: spotlight
Date: Fri, 17 Apr 1998 10:19:52 GMT
Reply-To: gordon@apollo13.demon.co.uk
Message-ID: <35372a0a.65064507@post.demon.co.uk>
References: <199804170949.RAA01093@nchc.gov.tw>
In-Reply-To: <199804170949.RAA01093@nchc.gov.tw>
X-Mailer: Forte Agent 1.5/32.450
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Status: O

Hi Sam


>Dear Mr. Tomlinson:   =20

It's Gordon please :-)

>
>  I use town demo file. Beside the terrain geometry there are
>lots of house. So I think it won't just falling within a polygon.
>  Or so I make a terrain which 10*10 m per polygon, but the effect
>is just the same.
>  I saw the source code "shadows.c" under ~/pguide which very like
>what I want to simulate, but did I need a projected texture to=20
>simulate a spotlight?
>
>

Apologies I missed the use of projected texture spot ;-(

Ok. What version of Perfomer are you using ??

If it is Pre 2.2 then there is a perfomer bug ( no patch that I am aware =
of ,
I believe it has been fixed in 2.2, but I have not had time to check :-( =
 )
 that prevents Projected spots from correctly working in multi process =
mode..
( APP, CULL, DRAW etc )

Are running in MP mode is so try running it in single mode and see if it =
works,


I have some code that I used to create a  torch effect, that I will dig =
out
and send to you over the weekend if you require it ( let me know ), the =
code works
for perfomer 2.1 in SP mode or and I seem to remember that it also worked
by having the Cull and Draw in the same mode.


TTFN


Gordon Tomlinson   =20
System Manager
PERA VR
Technology Centre
Nottingham Road
Melton Mowbray
Leicestershire
LE13 0PB
U.K.
***************************************************************
Tel:	01664 501 501=20
=46ax:	01664 501 553
Email: 	gordon@apollo13.demon.co.uk
Email: 	gordon_tomlinson@peragroup.com
WWW:	http://www.apollo13.demon.co.uk
***************************************************************
NOTE: ALL views, opinions, Comments etc are solely personal and
DO NOT in any way reflect the opinion or view of my employers=20
***************************************************************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 17 03:49:12 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA27686 for info-performer-dist@holodeck.engr.sgi.com; Fri, 17 Apr 1998 03:41:13 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id DAA27659 for <info-performer@holodeck.engr.sgi.com>; Fri, 17 Apr 1998 03:41:08 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id DAA13046480
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 17 Apr 1998 03:41:08 -0700 (PDT)
Received: from vision.ee.ethz.ch (goomba-biwi-front.ethz.ch [129.132.47.49]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id DAA22179
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 03:41:06 -0700 (PDT)
	mail_from (vmeier@vision.ee.ethz.ch)
Received: from peridot.ethz.ch (vmeier@peridot [129.132.47.210])
	by vision.ee.ethz.ch (8.8.5/8.8.5) with ESMTP id MAA17974
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 12:41:03 +0200 (MET DST)
Received: (from vmeier@localhost)
	by peridot.ethz.ch (8.8.5/8.8.5) id MAA14219
	for info-performer@sgi.com; Fri, 17 Apr 1998 12:41:01 +0200 (MET_DST)
From: "Volker Meier" <vmeier@vision.ee.ethz.ch>
Message-Id: <9804171241.ZM14217@peridot>
Date: Fri, 17 Apr 1998 12:41:01 +0000
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Problems running Performer remote
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Dear Performers,

I have some trouble running a Performer application remote. The server
machine is an Onyx2-InfiniteReality with Performer 2.2 installed. The client
is an Octane. The application was compiled with the -n32 option and uses the
OpenGL library. The problem is that during the downloading of the texture
maps the application hangs in the _select() function call. The call stack is
given below:

cvd> where
   0    _select(<stripped>) ["select.s":12, 0x0fac4e68]         <------------
   1    _XWaitForReadable(<stripped>) ["XlibInt.c":487, 0x0f60e9d8]
   2    _XRead(<stripped>) ["XlibInt.c":1114, 0x0f60f4a0]
   3    _XReply(<stripped>) ["XlibInt.c":1876, 0x0f610460]
   4    __glx_GenTexturesEXT(<stripped>) ["g_vendorpriv.c":173, 0x0d9e1cac]
   5    _pfNewTexName(<stripped>) ["pfState.C":678, 0x5b19f874]
   6    pfTexture::pr_format() ["pfTexture.C":3081, 0x5b1c44e8]
   7    pfTexture::pr_apply() ["pfTexture.C":4508, 0x5b1c3d9c]
   8    pfTexture::apply() ["pfTexture.C":2409, 0x5b1c2388]
   9    pfApplyTex(<stripped>) ["cTexture.C":782, 0x5b20cf94]
  10    pfuDownloadTexList(<stripped>) ["tex.c":671, 0x5cb0e684]    <---------
  11    DrawChannelCallback(channel = 0x6ffdf90, <no name> = 0x0)
["callbacks.cc":62, 0x1000ad60]
  12    pfChannel::pf_callDrawFunc() ["pfChannel.C":2194, 0x5b0a8104]
  13    doDraw() ["pfProcess.C":6200, 0x5b0e8320]
  14    appCullDraw() ["pfProcess.C":3948, 0x5b0e3ec0]
  15    pfFrame() ["pfProcess.C":4400, 0x5b0e4fcc]
  16    Simulate(lasso_cfg = 0x7ffd9b58, config = 0x7ffd99d8, err = 0x5fdf84d4,
ix = 0x0) ["simulation.cc":602, 0x1004ff30]
  17    main(argc = 1, argv = 0x7fff2f34) ["main.cc":137, 0x1006c1fc]
  18    __start(<stripped>) ["crt1text.s":166, 0x1000a968]

The problem does not occur if the client is an O2, so I assume it has something
to do with the rendering hardware of the Octane. Especially the
__glx_GenTexturesEXT() function call looks suspect to me. The glxinfo of the
Octane looks as follows:

---- glxinfo turmaline (Octane) ----
display: :0.0
server glx vendor string: SGI
server glx version string: 1.2 Irix 6.4
server glx extensions (GLX_):
    EXT_import_context, EXT_visual_info, EXT_visual_rating,
    SGI_make_current_read, SGI_swap_control, SGI_video_sync, SGIS_multisample,
    SGIX_fbconfig, SGIX_pbuffer, SGIX_swap_barrier, SGIX_swap_group,
    SGIX_video_resize, SGIX_video_source.
client glx version 1.1
client glx extensions (GLX_):
    EXT_import_context, EXT_visual_info, EXT_visual_rating,
    SGI_make_current_read, SGI_swap_control, SGI_video_sync, SGIS_multisample,
    SGIX_fbconfig, SGIX_pbuffer, SGIX_swap_barrier, SGIX_swap_group,
    SGIX_video_resize, SGIX_video_source.
OpenGL vendor string: SGI
OpenGL renderer string: IMPACT/2/2/4
OpenGL version string: 1.1 Irix 6.4
OpenGL extensions (GL_):
    EXT_abgr, EXT_blend_color, EXT_blend_logic_op, EXT_blend_minmax,
    EXT_blend_subtract, EXT_convolution, EXT_copy_texture, EXT_histogram,
    EXT_packed_pixels, EXT_polygon_offset, EXT_subtexture, EXT_texture,
    EXT_texture3D, EXT_texture_object, EXT_vertex_array, SGI_color_matrix,
    SGI_color_table, SGI_texture_color_table, SGIS_texture_filter4,
    SGIS_detail_texture, SGIS_texture_border_clamp, SGIS_texture_select,
    SGIS_texture_lod, SGIX_pixel_texture, SGIX_texture_multi_buffer.

The glxinfo of the server (remote) of the server is given below:

---- glxinfo server (Onyx2) ----
display: turmaline:0
server glx vendor string: SGI
server glx version string: 1.2 Irix 6.4
server glx extensions (GLX_):
    EXT_import_context, EXT_visual_info, EXT_visual_rating,
    SGI_make_current_read, SGI_swap_control, SGI_video_sync, SGIS_multisample,
    SGIX_fbconfig, SGIX_pbuffer, SGIX_swap_barrier, SGIX_swap_group,
    SGIX_video_resize, SGIX_video_source.
client glx version 1.1
client glx extensions (GLX_):
    EXT_import_context, EXT_visual_info, EXT_visual_rating,
    SGI_make_current_read, SGI_swap_control, SGI_video_sync, SGIS_multisample,
    SGIX_fbconfig, SGIX_pbuffer, SGIX_swap_barrier, SGIX_swap_group,
    SGIX_video_resize, SGIX_video_source.
OpenGL vendor string: SGI
OpenGL renderer string: IMPACT/2/2/4
OpenGL version string: 1.1 Irix 6.4
OpenGL extensions (GL_):
    EXT_abgr, EXT_blend_color, EXT_blend_logic_op, EXT_blend_minmax,
    EXT_blend_subtract, EXT_convolution, EXT_copy_texture, EXT_histogram,
    EXT_packed_pixels, EXT_polygon_offset, EXT_subtexture, EXT_texture,
    EXT_texture3D, EXT_texture_object, EXT_vertex_array, SGI_color_matrix,
    SGI_color_table, SGI_texture_color_table, SGIS_texture_filter4,
    SGIS_detail_texture, SGIS_texture_select, SGIS_texture_lod,
    SGIX_pixel_texture.

Any idea whats wrong?


Another problem is that when using secure shell I get the following X error
message:

X Error of failed request:  BadValue (integer parameter out of range for
operation)
  Major opcode of failed request:  150 (SGI-VIDEO-CONTROL)
  Minor opcode of failed request:  17 ()
  Value in failed request:  0x23
  Serial number of failed request:  58
  Current serial number in output stream:  58

I could solve the problem by setting the DISPLAY environment variable manually
to the display of the client. Is this the proper solution ?


Thanks for any help,

-Volker Meier

-- 
                            _____
                           |_____| ?
                         __|_____|/_
                         \\  - -  //
                          (  @ @  )         
------------------------oOOo-(_)-oOOo-------------------------------------

Volker Meier                            
Communications Technology Laboratory    Phone:  +41 -- (0)1 - 632 5008
ETH-Zentrum                             Fax:    +41 -- (0)1 - 632 1199
CH-8092 Zurich                          Email:  vmeier@vision.ee.ethz.ch  
Switzerland                      Oooo
                         oooO    (   )              
-------------------------(   )----) /-------------------------------------
                          \ (    (_/
                           \_)
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 17 06:43:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA28154 for info-performer-dist@holodeck.engr.sgi.com; Fri, 17 Apr 1998 06:21:10 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA28127 for <info-performer@holodeck.engr.sgi.com>; Fri, 17 Apr 1998 06:21:09 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA13142299
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 17 Apr 1998 06:21:08 -0700 (PDT)
Received: from imtsg14.epfl.ch (imtsg14.epfl.ch [128.178.157.50]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id GAA23262
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 06:21:06 -0700 (PDT)
	mail_from (ogeorg@imtsg14.epfl.ch)
Received: from imtsg12.epfl.ch (imtsg12.epfl.ch [128.178.157.40]) by imtsg14.epfl.ch (950413.SGI.8.6.12/8.6.12) with ESMTP id PAA27868; Fri, 17 Apr 1998 15:20:59 +0200
Received: (ogeorg@localhost) by imtsg12.epfl.ch (950413.SGI.8.6.12/8.6.11) id PAA20767; Fri, 17 Apr 1998 15:20:58 +0200
From: "Olivier Georg" <ogeorg@imtsg14.epfl.ch>
Message-Id: <9804171520.ZM20765@imtsg12.epfl.ch>
Date: Fri, 17 Apr 1998 15:20:58 -0600
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Attenuation of lights
Cc: ogeorg@imtsg14.epfl.ch
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi pfAll,

I am a bit confused with the attenuation of lights.  It can be set for both
a pfLightSource (in which case I suppose the three components depend on
the source) and a pfLightModel (since it is specified for a pfGeoState,
itself attached to a pfGeoSet, I can also suppose the components depend
on the object which is enlighted).  So... which version is correct ?

Olivier

-- 
---------------------------------------------------------------------
| Olivier Georg       \__  e-mail:    olivier.georg@epfl.ch         |
| Ch. de Montelly 43c    \__  home:   http://imtsg7.epfl.ch/~ogeorg |
| 1007 Lausanne/Switzerland \__  tel: +41 21 693 58 50 (work)       |
-------------------------------\__    +41 21 626 51 79 (private)    |
|   Heb Deh Hag Heb Warhoaz       \__--------------------------------
|   Hirio Ne Dalv Ket C'Hoaz         \__       ________    __o      |
|     ( Sans hier et sans demain )      \__      _____   _`\<,_     |
|     ( Aujourd'hui ne vaut rien )         \__      ___ (_)/ (_)    |
|               "Kinnig", Per Jakez Helias    \                     |
---------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 17 11:45:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA28946 for info-performer-dist@holodeck.engr.sgi.com; Fri, 17 Apr 1998 11:25:43 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA28919 for <info-performer@holodeck.engr.sgi.com>; Fri, 17 Apr 1998 11:25:42 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA13164202
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 17 Apr 1998 11:25:41 -0700 (PDT)
Received: from rose.engr.sgi.com ([150.166.37.6]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA17917
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 11:25:40 -0700 (PDT)
	mail_from (src@rose.engr.sgi.com)
Received: (from src@localhost) by rose.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA01600; Fri, 17 Apr 1998 11:25:35 -0700
Date: Fri, 17 Apr 1998 11:25:35 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9804171125.ZM1598@rose.engr.sgi.com>
In-Reply-To: "Olivier Georg" <ogeorg@imtsg14.epfl.ch>
        "Attenuation of lights" (Apr 17,  3:20pm)
References: <9804171520.ZM20765@imtsg12.epfl.ch>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: "Olivier Georg" <ogeorg@imtsg14.epfl.ch>, info-performer@sgi.com
Subject: Re: Attenuation of lights
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.19804171125.ZM1598.engr.sgi.com"
Status: O

--
--PART-BOUNDARY=.19804171125.ZM1598.engr.sgi.com
Content-Type: text/plain; charset=us-ascii

+>---- On Apr 17,  3:20pm, Olivier Georg wrote:
> Subject: Attenuation of lights
->
->Hi pfAll,
->
->I am a bit confused with the attenuation of lights.  It can be set for both
->a pfLightSource (in which case I suppose the three components depend on
->the source) and a pfLightModel (since it is specified for a pfGeoState,
->itself attached to a pfGeoSet, I can also suppose the components depend
->on the object which is enlighted).  So... which version is correct ?

This one is actually in the pfMan pagees on pfLightModel and pfLight so I 
have to bragg :-)

Attenuation on the light model is done only in IRIS GL operation. 
OpenGL light attenuation is done per-light.

Per-light attenuation is only available in OpenGL. 
IRIS GL light attenuation is done on the light model.

We even have a pfQueryFeature token so you can tell at run-time which
one you've got: PFQFTR_LIGHT_ATTENUATION.

src.




-- 
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src@sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@

--PART-BOUNDARY=.19804171125.ZM1598.engr.sgi.com
Content-Description: Message from "Olivier Georg" <ogeorg@imtsg14.epfl.ch>
Content-Type: message/rfc822

Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by rose.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA01014 for <src@rose.engr.sgi.com>; Fri, 17 Apr 1998 06:43:47 -0700
Received: from holodeck.engr.sgi.com (holodeck.engr.sgi.com [150.166.37.78])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via SMTP id GAA13021132;
	Fri, 17 Apr 1998 06:43:45 -0700 (PDT)
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA28154 for info-performer-dist@holodeck.engr.sgi.com; Fri, 17 Apr 1998 06:21:10 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA28127 for <info-performer@holodeck.engr.sgi.com>; Fri, 17 Apr 1998 06:21:09 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA13142299
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 17 Apr 1998 06:21:08 -0700 (PDT)
Received: from imtsg14.epfl.ch (imtsg14.epfl.ch [128.178.157.50]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id GAA23262
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 06:21:06 -0700 (PDT)
	mail_from (ogeorg@imtsg14.epfl.ch)
Received: from imtsg12.epfl.ch (imtsg12.epfl.ch [128.178.157.40]) by imtsg14.epfl.ch (950413.SGI.8.6.12/8.6.12) with ESMTP id PAA27868; Fri, 17 Apr 1998 15:20:59 +0200
Received: (ogeorg@localhost) by imtsg12.epfl.ch (950413.SGI.8.6.12/8.6.11) id PAA20767; Fri, 17 Apr 1998 15:20:58 +0200
From: "Olivier Georg" <ogeorg@imtsg14.epfl.ch>
Message-Id: <9804171520.ZM20765@imtsg12.epfl.ch>
Date: Fri, 17 Apr 1998 15:20:58 -0600
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Attenuation of lights
Cc: ogeorg@imtsg14.epfl.ch
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi pfAll,

I am a bit confused with the attenuation of lights.  It can be set for both
a pfLightSource (in which case I suppose the three components depend on
the source) and a pfLightModel (since it is specified for a pfGeoState,
itself attached to a pfGeoSet, I can also suppose the components depend
on the object which is enlighted).  So... which version is correct ?

Olivier

-- 
---------------------------------------------------------------------
| Olivier Georg       \__  e-mail:    olivier.georg@epfl.ch         |
| Ch. de Montelly 43c    \__  home:   http://imtsg7.epfl.ch/~ogeorg |
| 1007 Lausanne/Switzerland \__  tel: +41 21 693 58 50 (work)       |
-------------------------------\__    +41 21 626 51 79 (private)    |
|   Heb Deh Hag Heb Warhoaz       \__--------------------------------
|   Hirio Ne Dalv Ket C'Hoaz         \__       ________    __o      |
|     ( Sans hier et sans demain )      \__      _____   _`\<,_     |
|     ( Aujourd'hui ne vaut rien )         \__      ___ (_)/ (_)    |
|               "Kinnig", Per Jakez Helias    \                     |
---------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com


--PART-BOUNDARY=.19804171125.ZM1598.engr.sgi.com--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 17 12:02:36 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA29013 for info-performer-dist@holodeck.engr.sgi.com; Fri, 17 Apr 1998 11:46:38 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA28982 for <info-performer@holodeck.engr.sgi.com>; Fri, 17 Apr 1998 11:46:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA13273143
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 17 Apr 1998 11:46:35 -0700 (PDT)
Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA25888
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 11:46:34 -0700 (PDT)
	mail_from (Karin.Lee@PSS.Boeing.com)
Received: from xch-pssbh-01.ca.boeing.com ([192.42.211.28])
	by mailgate2.boeing.com (8.8.5/8.8.5) with ESMTP id LAA03613
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 11:46:31 -0700 (PDT)
Received: by xch-pssbh-01.ca.boeing.com with Internet Mail Service (5.0.1458.49)
	id <2RMDBBV0>; Fri, 17 Apr 1998 11:46:43 -0700
Message-ID: <71D105274EA7D011905700805FFECA591EBA63@xch-sea-10.ca.boeing.com>
From: "Lee, Karin S" <Karin.Lee@PSS.Boeing.com>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: 5551 Clipmap Textures
Date: Fri, 17 Apr 1998 11:46:33 -0700
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Status: O

> Hi.
> 
> This is probably a very simple question.
> 
> We have quite a number of clipmaps in 5551 format.  Supposedly, 
> that means there's 2 bytes per texel: 5 R, 5 G, 5 B, 1 A.  
> We need these textures in another format, preferably SGI RGB 
> or TIFF.
> 
> Does anyone know of a tool that is capable of converting 5551 
> images?  We located to5551 and viewtile (a viewer) on the SGI, 
> but nothing else.  I'm a novice when it comes to texture 
> formats and the C programming language, and I do not want 
> to do something that's already been done, so writing my own tool 
> is my very last resort. 
> 
> Any help would be appreciated.
> 
> -Karin
> 
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 17 14:55:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA29691 for info-performer-dist@holodeck.engr.sgi.com; Fri, 17 Apr 1998 14:39:30 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA29664 for <info-performer@holodeck.engr.sgi.com>; Fri, 17 Apr 1998 14:39:28 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA13203159
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 17 Apr 1998 14:39:28 -0700 (PDT)
Received: from hell.engr.sgi.com ([150.166.37.67]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id OAA27237
	for <info-performer@sgi.com>; Fri, 17 Apr 1998 14:39:27 -0700 (PDT)
	mail_from (hatch@hell.engr.sgi.com)
Received: (from hatch@localhost) by hell.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA21537; Fri, 17 Apr 1998 14:39:07 -0700
Date: Fri, 17 Apr 1998 14:39:07 -0700
From: hatch@hell.engr.sgi.com (Don Hatch)
Message-Id: <9804171439.ZM21535@hell.engr.sgi.com>
In-Reply-To: "Lee, Karin S" <Karin.Lee@PSS.Boeing.com>
        "5551 Clipmap Textures" (Apr 17, 11:46am)
References: <71D105274EA7D011905700805FFECA591EBA63@xch-sea-10.ca.boeing.com>
X-Face: /7QDEc=iPrsQG=j>iQo4F||T'ys-t--1bb9IJ9qo~4|i0nB|OG%gK}I3J2{/u*-q.I8=OSv/&K}V(pw:~5aIV!Y4:y+Vk#AAX)|i'B-jHf+r(?U'"B'9"D|<-(/1PD32tUN
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: "Lee, Karin S" <Karin.Lee@PSS.Boeing.com>,
        "'info-performer@sgi.com
 '" <info-performer@sgi.com>
Subject: Re: 5551 Clipmap Textures
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 17, 11:46am, Lee, Karin S wrote:
> Subject: 5551 Clipmap Textures
> > Hi.
> > 
> > This is probably a very simple question.
> > 
> > We have quite a number of clipmaps in 5551 format.  Supposedly, 
> > that means there's 2 bytes per texel: 5 R, 5 G, 5 B, 1 A.  
> > We need these textures in another format, preferably SGI RGB 
> > or TIFF.
> > 
> > Does anyone know of a tool that is capable of converting 5551 
> > images?  We located to5551 and viewtile (a viewer) on the SGI, 
> > but nothing else.  I'm a novice when it comes to texture 
> > formats and the C programming language, and I do not want 
> > to do something that's already been done, so writing my own tool 
> > is my very last resort. 
> > 
> > Any help would be appreciated.
> > 
> > -Karin

Here's a from5551 program we had lying around...
Don


/*
 * Compile with:
       cc from5551.c -o from5551 -limage
 */
#include "gl/image.h"
#include "malloc.h"
unsigned short rbuf[8192]; 
unsigned short gbuf[8192]; 
unsigned short bbuf[8192]; 

unsigned short packed[8192];

/*
** Convert a 5551 image into rgb format
*/
main(argc,argv)
int argc;
char **argv;
{
    IMAGE *image;
    FILE *input;
    int x, y, xsize, ysize;
    int z, zsize;
    ushort* img;
    if( argc != 5 ) {
	fprintf(stderr,
		"usage: %s inimage.5551 outimage.rgb xsize ysize\n", argv[0]);
	exit(1);
    } 
    if((input=fopen(argv[1],"r")) == NULL ) {
	fprintf(stderr,"%s: can't open input file %s\n", argv[0], argv[1]);
	exit(1);
    }
    if ((image = iopen(argv[2], "w", 1, 3, atoi(argv[3]), atoi(argv[4]), 3)) == NULL) {
	fprintf(stderr,"%s: can't open output file %s\n", argv[0], argv[2]);
	exit(2);
    }
    
    xsize = atoi(argv[3]);
    ysize = atoi(argv[4]);
    zsize = 3;
    img = (ushort*)malloc(2*xsize*ysize);
    if (fread(img, 2, xsize*ysize, input) != xsize*ysize)
    {
	fprintf(stderr,"%s: couldn't read %d texels from file %s\n", 
		argv[0], xsize*ysize, argv[1]);
	exit(1);
    }
    fclose(input);
    for(y=0; y<ysize; y++)
    {
	for(x=0;x<xsize;x++)
	{
	    /* [r:15..11][g:10..6][b:5..1][a:0] */
	    int r5 = (img[y*xsize + x]>>11)&31;
	    int g5 = (img[y*xsize + x]>>6)&31;
	    int b5 = (img[y*xsize + x]>>1)&31;
	    rbuf[x] = (r5<<3)|(r5>>2);
	    gbuf[x] = (g5<<3)|(g5>>2);
	    bbuf[x] = (b5<<3)|(b5>>2);
	}
	putrow(image,rbuf,y,0);
	putrow(image,gbuf,y,1);
	putrow(image,bbuf,y,2);
    }
    iclose(image);
    exit(0);
}

-- 
Don Hatch  hatch@sgi.com  (415) 933-5150  Silicon Graphics, Inc.
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sat Apr 18 06:55:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA02190 for info-performer-dist@holodeck.engr.sgi.com; Sat, 18 Apr 1998 06:32:41 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA02163 for <info-performer@holodeck.engr.sgi.com>; Sat, 18 Apr 1998 06:32:39 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA12757311
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 18 Apr 1998 06:32:39 -0700 (PDT)
Received: from firewall.fel.tno.nl ([192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA18502
	for <info-performer@sgi.com>; Sat, 18 Apr 1998 06:32:37 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id PAA17877; Sat, 18 Apr 1998 15:41:02 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma017875; Sat, 18 Apr 98 15:40:36 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id PAA15083;
	Sat, 18 Apr 1998 15:31:27 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804181331.PAA15083@s00sn1.fel.tno.nl>
Subject: Re: intersection traversal and pfPaths
To: pachler@marvin.gup.uni-linz.ac.at (Uwe Pachler)
Date: Sat, 18 Apr 1998 15:31:27 +0200 (MET DST)
Cc: info-performer@sgi.com
In-Reply-To: <Pine.SGI.3.96.980416201443.2255B-100000@kronos> from "Uwe Pachler" at Apr 16, 98 08:26:28 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> 
> Hi Folks!
> 
> What I need from my intersection traversal is not only the node where the
> intersection occurred, but also the intersection path. Nothing more easy
> than that, I thought, took a look into the manual, and then used 
> pfQueryHit(hits[0][0], PFQHIT_PATH, &path);
> But I only got an empty path, although the intersection occured and the
> node is deeply buried in the scene graph (and I start intersecting at the
> scene root).
> Here's what I do (the code prints <some> debug info ;-):
> 
> 	pfHit** hits[1]; 
> 	pfSegSet iSegs; 
> 	iSegs.mode = PFTRAV_IS_GSET; 

You must tell the isect function to store the path info
Look in the man page of pfNode.
 	iSegs.mode = PFTRAV_IS_GSET | PFTRAV_IS_PATH; 

> 	pfCopyVec3(iSegs.segs[0].pos, handPosition->pos); 
> 	pfCopyVec3(iSegs.segs[0].dir, handPosition->dir); 
> 	iSegs.segs[0].length = handPosition->length; 
> 	iSegs.userData = NULL; 
> 	iSegs.activeMask = 0x01; 
> 	iSegs.isectMask = VRCONTROLABLE_ISECT_MASK; 
> 	iSegs.bound = NULL; 
> 	iSegs.discFunc = NULL; 
> 
> 	if (pfNodeIsectSegs(root, &iSegs, hits) != 0) 
> 		{
> 		pfPath* path; 
> 
> 		pfQueryHit(hits[0][0], PFQHIT_PATH, &path); 
> 
> 		// this returns zero; and therefore the path seems to be
> 		//empty...
> 		int pathLength = pfGetNum(path);
> 		  
> 
> 		pfNode* hitNode; 
> 		
> 		// returns a valid hitNode
> 		pfQueryHit(hits[0][0], PFQHIT_NODE, &hitNode);
> 		}
> 
> 
> Maybe someone has some hints for me ;-). Thanx in advance,
> 
> 	Uwe Pachler
> 
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
> 

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sat Apr 18 08:38:30 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA02593 for info-performer-dist@holodeck.engr.sgi.com; Sat, 18 Apr 1998 08:20:33 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA02566 for <info-performer@holodeck.engr.sgi.com>; Sat, 18 Apr 1998 08:20:28 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA12448481
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 18 Apr 1998 08:20:27 -0700 (PDT)
Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id IAA02962
	for <info-performer@sgi.com>; Sat, 18 Apr 1998 08:20:22 -0700 (PDT)
	mail_from (rltyme@banet.net)
Received: from banet.net (slip-32-100-117-233.va.us.ibm.net [32.100.117.233]) by out2.ibm.net (8.8.5/8.6.9) with ESMTP id PAA62648 for <info-performer@sgi.com>; Sat, 18 Apr 1998 15:20:13 GMT
Message-ID: <3538C542.24FB1436@banet.net>
Date: Sat, 18 Apr 1998 11:22:42 -0400
From: Joe Castillo <rltyme@banet.net>
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: "info-performer@sgi.com" <info-performer@sgi.com>
Subject: TopScene
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Dear performers,

I've been tasked to research "TopScene" , a real-time software.  What I
need to know is :

1. compatibility with OpenFlight format.

2. can TopScene databases be converted with little or no hierarchy
adjustment.

3. overall, I need to know what it is, who uses it, where I can find out
more about

TopScene, etc.

any help would be much appreciated.  BTW, we use "Stealth"(by MAK) to
render our

scenes.

thank you

Joe C.


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sun Apr 19 13:11:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA20733 for info-performer-dist@holodeck.engr.sgi.com; Sun, 19 Apr 1998 12:55:14 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA20706 for <info-performer@holodeck.engr.sgi.com>; Sun, 19 Apr 1998 12:55:12 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA13766815
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 19 Apr 1998 12:55:12 -0700 (PDT)
Received: from imtsg14.epfl.ch (imtsg14.epfl.ch [128.178.157.50]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA24321
	for <info-performer@sgi.com>; Sun, 19 Apr 1998 12:55:10 -0700 (PDT)
	mail_from (ogeorg@imtsg14.epfl.ch)
Received: from imtsg12.epfl.ch (imtsg12.epfl.ch [128.178.157.40]) by imtsg14.epfl.ch (950413.SGI.8.6.12/8.6.12) with ESMTP id VAA05572 for <info-performer@sgi.com>; Sun, 19 Apr 1998 21:54:44 +0200
Received: (ogeorg@localhost) by imtsg12.epfl.ch (950413.SGI.8.6.12/8.6.11) id VAA27104 for info-performer@sgi.com; Sun, 19 Apr 1998 21:54:36 +0200
From: "Olivier Georg" <ogeorg@imtsg14.epfl.ch>
Message-Id: <9804192154.ZM27102@imtsg12.epfl.ch>
Date: Sun, 19 Apr 1998 21:54:35 -0600
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Strange compiling problem
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi,

I have a very strange compiling problem.  In my Performer project,
libptk++ I have several classes that when compiled are put together
into a '.a' file (libptk++.a).  Then this file is linked to the binary.
I've recently added a class.  I know it _is_ present in libptk++.a
(I can see some string in it which are exclusive to this class)
But when linking this file to the binary, all other classes are
present, but not this new one ?

The command to get the binary is :

/usr/bin/CC     -DIRIX6 -I../.   -nostdinc -I/usr/include -mips2 -o32 -g
 -MDupdate Makedepend  -o application.DBG -L/usr/lib/Performer/DebugStatic
 -L/usr/lib/Performer/DebugStatic/libpfdb  -L/lib -lpf_ogl -lpfdu_ogl
-lpfutil_ogl -lpfui -lvl  -Wl,-none  -limage  -lfm  -ignore_unresolved -lGLU
-lGL -lXext -lXsgivc  -lXmu  -lX11  -lfpe  -lm  -lmalloc  -lC  -lcurses
   -L/usr/people/ogeorg/virgy/libptk++2.0/src/DBG.O32.OPENGL -lptk++
../../lib/libgizmo.a ../../lib/libmgl.a /usr/local/lib/libtcl.so
/usr/local/lib/libtk.so

One can see that libptk++ _is_ included, so how come something in libptk++
is _not_ int application.DBG ?  Has anyone already experienced this ?

Olivier

-- 
---------------------------------------------------------------------
| Olivier Georg       \__  e-mail:    olivier.georg@epfl.ch         |
| Ch. de Montelly 43c    \__  home:   http://imtsg7.epfl.ch/~ogeorg |
| 1007 Lausanne/Switzerland \__  tel: +41 21 693 58 50 (work)       |
-------------------------------\__    +41 21 626 51 79 (private)    |
|   Heb Deh Hag Heb Warhoaz       \__--------------------------------
|   Hirio Ne Dalv Ket C'Hoaz         \__       ________    __o      |
|     ( Sans hier et sans demain )      \__      _____   _`\<,_     |
|     ( Aujourd'hui ne vaut rien )         \__      ___ (_)/ (_)    |
|               "Kinnig", Per Jakez Helias    \                     |
---------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 05:23:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA22635 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 05:03:58 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA22608 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 05:03:56 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA13935696
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 05:03:56 -0700 (PDT)
Received: from cledf.edf.fr (cledf.edf.fr [192.54.193.133]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA12603
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 05:03:50 -0700 (PDT)
	mail_from (Michael.Krus@der.edfgdf.fr)
Received: from clserv02.edf.fr (clserv02.edf.fr [130.98.118.118]) by cledf.edf.fr (8.6.12/8.6.12) with ESMTP id OAA14504; Mon, 20 Apr 1998 14:10:53 +0200
Received: from cli24do.der.edf.fr (cli24do.der.edf.fr [130.98.14.31]) by clserv02.edf.fr (8.8.5/8.8.5) with SMTP id OAA08495; Mon, 20 Apr 1998 14:02:11 +0200 (MET DST)
Received: from der.edfgdf.fr by cli24do.der.edf.fr (SMI-8.6/SMI-SVR4)
	id OAA12805; Mon, 20 Apr 1998 14:05:07 +0200
Sender: krus@der.edfgdf.fr
Message-ID: <353B39F4.1C40955B@der.edfgdf.fr>
Date: Mon, 20 Apr 1998 14:05:08 +0200
From: Mike Krus <Michael.Krus@der.edfgdf.fr>
Organization: EdF/DER/IMA/TIEM/CAO -- http://www.edf.fr/DER/en/welcome.htm
X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX64 6.2 IP28)
MIME-Version: 1.0
To: optimizer-dev@palladium.corp.sgi.com, info-performer@sgi.com
Subject: Cosmo3D/Optimizer: Screen size of shape
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi,

I am currently trying the access the screen size of the bounding box of
a cosmo3D csGeometry object. The csDrawAction provides access to the 
transformation and to the camera (and thus to the camera
transformation).

Given the bounding box of a csGeometry how do I use the two
transformation
matrices to compute the size of that bb on the screen?

Thanks for your help,

Mike

-- 
   __     __                 Mike Krus            Michael.Krus @
der.edfgdf.fr
  /     //  _    __  ___     EdF/DER/IMA/TIEM/CAO       Tel: +33 1 47 65
39 10
 /-  --//- / |  /   /  /     1, av du Gle de Gaulle     Fax: +33 1 47 65
34 24
/__ /_//  /  / /-  /--       F-92141 CLAMART Cedex
         /__/ /__ / /        WWW: http://www.limsi.fr/Individu/krus/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 05:44:49 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA22686 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 05:28:43 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA22659 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 05:28:41 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA12872123
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 05:28:41 -0700 (PDT)
Received: from relay2.mail.uk.psi.net (relay2.mail.uk.psi.net [154.32.107.6]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id FAA17632
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 05:28:36 -0700 (PDT)
	mail_from (sys2.london2.uk.psi.net!hegel!tswl.co.uk!rmorris)
Received: from sys2.london2.uk.psi.net [154.32.110.6] 
	by relay2.mail.uk.psi.net with esmtp (Exim 1.82 #2)
	id 0yRFgG-0001Cw-00; Mon, 20 Apr 1998 13:28:16 +0100
Received: from hegel.UUCP by sys2.london2.uk.psi.net (8.8.4/SMI-5.5-UKPSINet)
	id NAA05285; Mon, 20 Apr 1998 13:28:37 +0100 (BST)
Received: from tswl (cookstown) by tswl.co.uk (4.1/SMI-4.1)
  	  id AA16955; Mon, 20 Apr 98 09:48:21 BST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; boundary="BeyondBoundary_1_Mon_Apr_20_09:51:47_1998__29"
To: "info-performer@sgi.com" <info-performer@sgi.com>,
        Joe Castillo
	<rltyme@banet.net>
From: Roger Morris <rmorris@tswl.co.uk>
Subject: re: TopScene
Date: Mon, 20 Apr 1998 09:51:46 -0700
X-Beyondmail-Priority: 1
Message-Id: <BMSMTP8930909250rmorris@hegel>
Conversation-Id: <3538C542.24FB1436@banet.net>
In-Reply-To: <3538C542.24FB1436@banet.net>
Reply-To: Roger Morris <rmorris@tswl.co.uk>
Status: O


--BeyondBoundary_1_Mon_Apr_20_09:51:47_1998__29
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7Bit
X-Mailer: BeyondMail for Windows/SMTP 2.2

Dear Joe,

>From http://www.tec.army.mil/TD/survey_17.html

"Loral Vought Systems' (LV) Tactical Operation Preview Scene (TOPSCENE) system
is included in
this survey despite its being a turn-key system, not a COTS or GOTS
software-only product.
TOPSCENE is a deployable training system, designed to permit aircrews to plan
and rehearse
missions over contingency areas. TOPSCENE includes a two-processor Silicon
Graphics' (SGI)
Onyx VTX computer, supplemented with six proprietary LV accelerator boards."

"As of 29 June 1995, eleven deployable systems are currently operational,
and over thirty are under contract. Users include the U.S. Army, Navy, Air
Force and Marines.
 

System requirements: TOPSCENE consists of a Silicon Graphics Onyx VTX
supplemented with
six proprietary Loral Vought accelerator boards. 

Price: $522,000. 

Hope this helps.

Roger

>  From: Joe Castillo <rltyme@banet.net>, on 18/04/98 11:22:
>  Dear performers,
>  
>  I've been tasked to research "TopScene" , a real-time software.  What I
>  need to know is :
>  
>  1. compatibility with OpenFlight format.
>  
>  2. can TopScene databases be converted with little or no hierarchy
>  adjustment.
>  
>  3. overall, I need to know what it is, who uses it, where I can find out
>  more about
>  
>  TopScene, etc.
>  
>  any help would be much appreciated.  BTW, we use "Stealth"(by MAK) to
>  render our
>  
>  scenes.
>  
>  thank you
>  
>  Joe C.
>  
>  
>  =======================================================================
>  List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>              Submissions:  info-performer@sgi.com
>          Admin. requests:  info-performer-request@sgi.com
>  
>  

    >		Roger Morris
  >   >		Applications Engineer
>   >   >	TEL: 01844 261456
  >   >		FAX: 01844 260056
    >

Transformation Software Ltd
Thame Park Road
Thame
Oxfordshire
OX9 3UQ
http://www.transform.co.uk

Part of the Raab Karcher Electronics Group

--BeyondBoundary_1_Mon_Apr_20_09:51:47_1998__29
Content-Type: application/octet-stream; name="ATTRIBS.BND"
Content-Transfer-Encoding: X-UUENCODE
Content-Disposition: attachment; filename="ATTRIBS.BND"

begin 666 ATTRIBS.BND
M0F5Y;VYD(%!A8VME9"!!='1R:6)U=&5S #P> !8 *       <F4Z(%1O<%-C
M96YE                                                        
M                                                            
M ')M;W)R:7,                                                 
M                                   \0DU33510.#DS,#DP.3(U,')M
M;W)R:7, 0F5Y;VYD(%!R;W!R:65T87)Y($1A=&$:      0         #P >
M                            0V]N=F5R<V%T:6]N($ED'3PS-3,X0S4T
M,BXR-$9",30S-D!B86YE="YN970^!          0  D                 
M          !-97-S86=E($5N8V]D:6YG"$E33RTX.#4Y 0         5  , 
M                          !5<V4@4')O<&]R=&EO;F%L($9O;G0!  $)
M          T (                            %!R979I;W5S($9R;VT?
M2F]E($-A<W1I;&QO(#QR;'1Y;65 8F%N970N;F5T/@T         "P!#    
M                        4')E=FEO=7,@5&]! #8! 0 ) /__,@    (R
M #$B:6YF;RUP97)F;W)M97) <V=I+F-O;2(@/&EN9F\M<&5R9F]R;65R0'-G
M:2YC;VT^#0         + $,                           !/<FEG:6YA
M;"!T;T$ -@$!  D __\R     C( ,2)I;F9O+7!E<F9O<FUE<D!S9VDN8V]M
M(B \:6YF;RUP97)F;W)M97) <V=I+F-O;3X1          T !@          
M                 $]R:6=I;F%L('1E>'0        1          0 )PH 
M                         %1E>'2D!T1E87(@2F]E+ H*1G)O;2!H='1P
M.B\O=W=W+G1E8RYA<FUY+FUI;"]41"]S=7)V97E?,3<N:'1M; H*(DQO<F%L
M(%9O=6=H="!3>7-T96US)R H3%8I(%1A8W1I8V%L($]P97)A=&EO;B!0<F5V
M:65W(%-C96YE("A43U!30T5.12D@<WES=&5M(&ES(&EN8VQU9&5D(&EN"G1H
M:7,@<W5R=F5Y(&1E<W!I=&4@:71S(&)E:6YG(&$@='5R;BUK97D@<WES=&5M
M+"!N;W0@82!#3U13(&]R($=/5%,@<V]F='=A<F4M;VYL>2!P<F]D=6-T+@I4
M3U!30T5.12!I<R!A(&1E<&QO>6%B;&4@=')A:6YI;F<@<WES=&5M+"!D97-I
M9VYE9"!T;R!P97)M:70@86ER8W)E=W,@=&\@<&QA;B!A;F0@<F5H96%R<V4*
M;6ES<VEO;G,@;W9E<B!C;VYT:6YG96YC>2!A<F5A<RX@5$]04T-%3D4@:6YC
M;'5D97,@82!T=V\M<')O8V5S<V]R(%-I;&EC;VX@1W)A<&AI8W,G("A31TDI
M"D]N>7@@5E18(&-O;7!U=&5R+"!S=7!P;&5M96YT960@=VET:"!S:7@@<')O
M<')I971A<GD@3%8@86-C96QE<F%T;W(@8F]A<F1S+B(*"B)!<R!O9B R.2!*
M=6YE(#$Y.34L(&5L979E;B!D97!L;WEA8FQE('-Y<W1E;7,@87)E(&-U<G)E
M;G1L>2!O<&5R871I;VYA;"P*86YD(&]V97(@=&AI<G1Y(&%R92!U;F1E<B!C
M;VYT<F%C="X@57-E<G,@:6YC;'5D92!T:&4@52Y3+B!!<FUY+"!.879Y+"!!
M:7(@1F]R8V4@86YD($UA<FEN97,N"B *"E-Y<W1E;2!R97%U:7)E;65N=',Z
M(%1/4%-#14Y%(&-O;G-I<W1S(&]F(&$@4VEL:6-O;B!'<F%P:&EC<R!/;GEX
M(%946"!S=7!P;&5M96YT960@=VET: IS:7@@<')O<')I971A<GD@3&]R86P@
M5F]U9VAT(&%C8V5L97)A=&]R(&)O87)D<RX@"@I0<FEC93H@)#4R,BPP,# N
M( H*2&]P92!T:&ES(&AE;'!S+@H*4F]G97(*"CX@($9R;VTZ($IO92!#87-T
M:6QL;R \<FQT>6UE0&)A;F5T+FYE=#XL(&]N(#$X+S T+SDX(#$Q.C(R.@H^
M("!$96%R('!E<F9O<FUE<G,L"CX@( H^("!))W9E(&)E96X@=&%S:V5D('1O
M(')E<V5A<F-H(")4;W!38V5N92(@+"!A(')E86PM=&EM92!S;V9T=V%R92X@
M(%=H870@20H^("!N965D('1O(&MN;W<@:7,@.@H^(" */B @,2X@8V]M<&%T
M:6)I;&ET>2!W:71H($]P96Y&;&EG:'0@9F]R;6%T+@H^(" */B @,BX@8V%N
M(%1O<%-C96YE(&1A=&%B87-E<R!B92!C;VYV97)T960@=VET:"!L:71T;&4@
M;W(@;F\@:&EE<F%R8VAY"CX@(&%D:G5S=&UE;G0N"CX@( H^(" S+B!O=F5R
M86QL+"!)(&YE960@=&\@:VYO=R!W:&%T(&ET(&ES+"!W:&\@=7-E<R!I="P@
M=VAE<F4@22!C86X@9FEN9"!O=70*/B @;6]R92!A8F]U= H^(" */B @5&]P
M4V-E;F4L(&5T8RX*/B @"CX@(&%N>2!H96QP('=O=6QD(&)E(&UU8V@@87!P
M<F5C:6%T960N("!"5%<L('=E('5S92 B4W1E86QT:"(H8GD@34%+*2!T;PH^
M("!R96YD97(@;W5R"CX@( H^("!S8V5N97,N"CX@( H^("!T:&%N:R!Y;W4*
M/B @"CX@($IO92!#+@H^(" */B @"CX@(#T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]"CX@($QI<W0@07)C:&EV97,L($9!42P@1E10.B @:'1T<#HO+W=W
M=RYS9VDN8V]M+U1E8VAN;VQO9WDO4&5R9F]R;65R+PH^(" @(" @(" @(" @
M("!3=6)M:7-S:6]N<SH@(&EN9F\M<&5R9F]R;65R0'-G:2YC;VT*/B @(" @
M(" @("!!9&UI;BX@<F5Q=65S=',Z("!I;F9O+7!E<F9O<FUE<BUR97%U97-T
M0'-G:2YC;VT*/B @"CX@( H*(" @(#X)"5)O9V5R($UO<G)I<PH@(#X@(" ^
M"0E!<'!L:6-A=&EO;G,@16YG:6YE97(*/B @(#X@(" ^"51%3#H@,#$X-#0@
M,C8Q-#4V"B @/B @(#X)"49!6#H@,#$X-#0@,C8P,#4V"B @(" ^"@I4<F%N
M<V9O<FUA=&EO;B!3;V9T=V%R92!,=&0*5&AA;64@4&%R:R!2;V%D"E1H86UE
M"D]X9F]R9'-H:7)E"D]8.2 S55$*:'1T<#HO+W=W=RYT<F%N<V9O<FTN8V\N
M=6L*"E!A<G0@;V8@=&AE(%)A86(@2V%R8VAE<B!%;&5C=')O;FEC<R!'<F]U
M<'T" P"D!W8" P "    1@ !  $  0 %!@        ( !@8H          $ 
M+@9W 0       #C_        D $          $-O=7)I97(             
M                         #C_        O (  0       $-O=7)I97( 
M                                      $  0 *  $ "P +  $ #  Z
M  $ .P [  $ / "9  $ F@#T  $ ]0!/ 0$ 4 &J 0$ JP'W 0$ ^ 'X 0$ 
M^0%" @$ 0P*@ @$ H0*B @$ HP*C @$ I +[ @$ _ (M P$ +@,N P$ +P- 
M P$ 00-! P$ 0@-2 P$ 4P-3 P$ 5 -9 P$ 6@-: P$ 6P.7 P$ F .K P$ 
MK .O P$ L /Z P$ ^P,/! $ $ 03! $ % 0_! $ 0 1#! $ 1 2)! $ B@28
M! $ F02<! $ G03H! $ Z03V! $ ]P3Z! $ ^P0,!0$ #040!0$ $059!0$ 
M6@5G!0$ : 5K!0$ ; 5V!0$ =P5Z!0$ >P6'!0$ B 6+!0$ C 65!0$ E@69
M!0$ F@6=!0$ G@7H!0$ Z04N!@$ +P9B!@$ 8P:>!@$ GP:B!@$ HP:F!@$ 
MIP:G!@$ J :[!@$ O ;:!@$ VP;V!@$ ]P81!P$ $@<7!P$ & <8!P$ &0<T
M!P$ -0=$!P$ 10=*!P$ 2P=6!P$ 5P=>!P$ 7P=Y!P$ >@=Z!P$ >P>E!P  
M             &0  > ! < # : % 8 ' 6 ) 4 + 2 - 0 / > 0 < 2 : 4
M 8 6 6 8 4 :>0             0  8                           !!
5='1A8VAM96YT($-O=6YT!       
 
end

--BeyondBoundary_1_Mon_Apr_20_09:51:47_1998__29--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 09:58:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA23310 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 09:55:52 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA23283 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 09:55:42 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA14254194
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 09:55:41 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA18740
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 09:55:39 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA10959750;
	Mon, 20 Apr 1998 09:55:38 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA11371; Mon, 20 Apr 1998 09:55:37 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353B7E09.C987AF1C@sgi.com>
Date: Mon, 20 Apr 1998 09:55:37 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Mike Krus <Michael.Krus@der.edfgdf.fr>
CC: optimizer-dev@palladium.corp.sgi.com, info-performer@sgi.com
Subject: Re: Cosmo3D/Optimizer: Screen size of shape
References: <353B39F4.1C40955B@der.edfgdf.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Mike Krus wrote:
> 
> Hi,
> 
> I am currently trying the access the screen size of the bounding box of
> a cosmo3D csGeometry object. The csDrawAction provides access to the
> transformation and to the camera (and thus to the camera
> transformation).
> 
> Given the bounding box of a csGeometry how do I use the two
> transformation
> matrices to compute the size of that bb on the screen?
> 

Well if it doesn't cross the hither plane you could just transform
the corners through the modelling then projection matrix and scale
to window coordinates then use min max testing for bounds. If it does
cross then clip the edges to produce new transformable points.

Cheers,Angus.


-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 09:58:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA23247 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 09:45:00 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA23220 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 09:44:58 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA14065445
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 09:44:58 -0700 (PDT)
Received: from vinson.ait.nrl.navy.mil (vinson.ait.nrl.navy.mil [132.250.128.91]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA13670
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 09:44:57 -0700 (PDT)
	mail_from (pawlowsk@ait.nrl.navy.mil)
Received: from ait.nrl.navy.mil (localhost [127.0.0.1])
	by vinson.ait.nrl.navy.mil (8.8.5/8.8.5) with ESMTP id MAA08011;
	Mon, 20 Apr 1998 12:44:54 -0400 (EDT)
Sender: pawlowsk@nimitz.ait.nrl.navy.mil
Message-ID: <353B7B86.FDAD29BA@ait.nrl.navy.mil>
Date: Mon, 20 Apr 1998 12:44:54 -0400
From: Carol Pawlowski <pawlowsk@ait.nrl.navy.mil>
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX64 6.2 IP25)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Video and Performer
Content-Type: multipart/alternative; boundary="------------580A5907424D1043621AC289"
Status: O


--------------580A5907424D1043621AC289
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
I would like to construct a "virtual cockpit" using Performer.  I would
like to model the cockpit itself with a .flt model.  At the same time I
would like to have a video of the external world playing through the
windows. Superimposed on the video would be a "virtual 3d world" of .flt
models.   Does anyone have any idea how to do this?

--
---------------------------------------------------------------
Carol Pawlowski              pawlowsk@ait.nrl.navy.mil
Code 5585, AIT/ITD
Naval Research Laboratory    Pho: (202)767-3040
Washington, DC  20375-5337   FAX: (202)767-1122
---------------------------------------------------------------



--------------580A5907424D1043621AC289
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
Hi,
<BR>I&nbsp;would like to construct a "virtual cockpit" using Performer.&nbsp;
I&nbsp;would like to model the cockpit itself with a .flt model.&nbsp;
At the same time I would like to have a video of the external world playing
through the windows. Superimposed on the video would be a "virtual 3d world"
of .flt models.&nbsp;&nbsp; Does anyone have any idea how to do this?
<PRE>--&nbsp;
---------------------------------------------------------------
Carol Pawlowski&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pawlowsk@ait.nrl.navy.mil
Code 5585, AIT/ITD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Naval Research Laboratory&nbsp;&nbsp;&nbsp; Pho: (202)767-3040
Washington, DC&nbsp; 20375-5337&nbsp;&nbsp; FAX: (202)767-1122
---------------------------------------------------------------</PRE>
&nbsp;</HTML>

--------------580A5907424D1043621AC289--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 10:46:45 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA23620 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 10:31:48 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA23593 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 10:31:47 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA13663541
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 10:31:47 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA06877
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 10:31:45 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA14024661;
	Mon, 20 Apr 1998 10:31:44 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA11485; Mon, 20 Apr 1998 10:31:42 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353B867E.B129E667@sgi.com>
Date: Mon, 20 Apr 1998 10:31:42 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Carol Pawlowski <pawlowsk@ait.nrl.navy.mil>
CC: info-performer@sgi.com
Subject: Re: Video and Performer
References: <353B7B86.FDAD29BA@ait.nrl.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Carol Pawlowski wrote:
> 
> Hi,
> I would like to construct a "virtual cockpit" using Performer.
> I would like to model the cockpit itself with a .flt model.  At the
> same time I would like to have a video of the external world playing
> through the windows. Superimposed on the video would be a "virtual 3d
> world" of .flt models.   Does anyone have any idea how to do this?
> 

What part don't you understand how to do?

Let's assume the video part for now, everything else is fairly
straightforward.

The easiest way would be to video texture a large distant surface
with the exterior video images and simply attach this to a DCS which
tracks the position of the cockpit. Accurate geometric alignment
is a problem you'll have to contend with and may involve the
meshing of the external geometry to undo lens abberations. Then
you just need to make sure the orientation is correct w.r.t. the
cockpit.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 10:56:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA23720 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 10:42:42 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA23693 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 10:42:41 -0700
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id KAA19394; Mon, 20 Apr 1998 10:42:41 -0700 (PDT)
Date: Mon, 20 Apr 1998 10:42:41 -0700 (PDT)
Message-Id: <199804201742.KAA19394@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: Scott McMillan <mcmillan@cambridge.com>
cc: info-performer@puget.engr.sgi.com
Subject: Re: Compiling -mips3 -n32 with MIPSpro7.2
In-Reply-To: <3537C7AE.446B@cambridge.com>
References: <3534C20F.2781@cambridge.com>
	<199804151557.IAA10834@puget.engr.sgi.com>
	<9804171327.ZM11156@quid.engr.sgi.com>
	<3537C7AE.446B@cambridge.com>
Status: O


Scott McMillan writes:
 > Jay suggested I remove the -L/usr/lib32 as well as the mips3 one
 > I just added (same as you suggest) but the way
 > I had the Makefile set up, it was putting a blank -L argument so
 > the linker started complaining about not being able to find every
 > library and choosing (incorrectly) the ones in /usr/lib.  ACK!
 > 
 > So I finally realized this, removed the offending -L, and 
 > everything is hunky-dorey now.  :)
 > 
Good.  I'm glad to hear it.

 > Now I am trying to remember why I had the -L/usr/lib32
 > in there in the first place.  I am wondering if this is a
 > carry over from previous Performer makefiles.  If so, has
 > this been removed from the Performer 2.2 makefiles?  I know
 > they have been totally revamped and I have not had time to
 > play with them.
 > 

It appears that in fact the "-mips3 -L/usr/lib32" is still there in
the sample Makefiles..  I wasn't previously aware that O2 platforms
used a mips4 version of certain files by default.  So building the
examples with the defaults on an O2 is going to create problems.
Sigh.

------------------------------------------------------------------------
Jay L Gischer        +  "I see great things in baseball.  It's our game.
Advanced Graphics    +  It will repair our losses and be a blessing to
Software             +  us."
Silicon Graphics     +    -Walt Whitman
(415) 390-4277       +    
gischer@sgi.com      +  "A life has no meaning except in the impact it
                     +  has on other lives"
                     +    -Jackie Robinson

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 10:56:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA23805 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 10:53:00 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA23778 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 10:53:00 -0700
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id KAA19487; Mon, 20 Apr 1998 10:52:54 -0700 (PDT)
Date: Mon, 20 Apr 1998 10:52:54 -0700 (PDT)
Message-Id: <199804201752.KAA19487@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: "Olivier Georg" <ogeorg@imtsg14.epfl.ch>
cc: info-performer@puget.engr.sgi.com
Subject: Strange compiling problem
In-Reply-To: <9804192154.ZM27102@imtsg12.epfl.ch>
References: <9804192154.ZM27102@imtsg12.epfl.ch>
Status: O


Olivier Georg writes:
 > Hi,
 > 
 > I have a very strange compiling problem.  In my Performer project,
 > libptk++ I have several classes that when compiled are put together
 > into a '.a' file (libptk++.a).  Then this file is linked to the binary.
 > I've recently added a class.  I know it _is_ present in libptk++.a
 > (I can see some string in it which are exclusive to this class)
 > But when linking this file to the binary, all other classes are
 > present, but not this new one ?
 > 
 > The command to get the binary is :
 > 
 > /usr/bin/CC     -DIRIX6 -I../.   -nostdinc -I/usr/include -mips2 -o32 -g
 >  -MDupdate Makedepend  -o application.DBG -L/usr/lib/Performer/DebugStatic
 >  -L/usr/lib/Performer/DebugStatic/libpfdb  -L/lib -lpf_ogl -lpfdu_ogl
 > -lpfutil_ogl -lpfui -lvl  -Wl,-none  -limage  -lfm  -ignore_unresolved -lGLU
 > -lGL -lXext -lXsgivc  -lXmu  -lX11  -lfpe  -lm  -lmalloc  -lC  -lcurses
 >    -L/usr/people/ogeorg/virgy/libptk++2.0/src/DBG.O32.OPENGL -lptk++
 > ../../lib/libgizmo.a ../../lib/libmgl.a /usr/local/lib/libtcl.so
 > /usr/local/lib/libtk.so
 > 
 > One can see that libptk++ _is_ included, so how come something in libptk++
 > is _not_ int application.DBG ?  Has anyone already experienced this ?
 > 
 > Olivier

Olivier,

Linking against a .a has different semantics than linking against a
.so.  When you link against a .so, you automatically get everything
in the .so whether or not there is a current reference to it.

When you link against a .a, you only load those object files for which
there is an outstanding reference.  What this means is that one of the
objects which appears *before* lptk++ must contain a reference to your
class in order for it to be loaded.  Life can be even more complicated
if the routines for your class are defined in more than one object
file, in which case there would probably need to be a reference to the
particular method in question in one of the objects before "-lptk++"
to trigger loading of that method.

The solution is to either 
1. Turn your .a into a dso (it isn't that hard, try "man dso") or,
2. Rearrange the order of your libraries, or
3. Use the linker flags "-all" and "-none"

"-all" will force the loading of every object file from any archives
encountered after the "-all" flag.  "-none" (poorly named IMHO) turns
off "-all", returning to the normal archive semantics described above.

------------------------------------------------------------------------
Jay L Gischer        +  "I see great things in baseball.  It's our game.
Advanced Graphics    +  It will repair our losses and be a blessing to
Software             +  us."
Silicon Graphics     +    -Walt Whitman
(415) 390-4277       +    
gischer@sgi.com      +  "A life has no meaning except in the impact it
                     +  has on other lives"
                     +    -Jackie Robinson



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 11:30:10 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA24154 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 11:16:19 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA24127 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 11:16:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA14140959
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 11:16:17 -0700 (PDT)
Received: from relay3.smtp.psi.net (relay3.smtp.psi.net [38.8.210.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA29639
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 11:16:14 -0700 (PDT)
	mail_from (bills@FTIORL02.ENZIAN.COM)
Received: from [38.227.238.3] (helo=FTIORL02.ENZIAN.COM)
	by relay3.smtp.psi.net with esmtp (Exim 1.90 #1)
	for info-performer@sgi.com
	id 0yRL6x-0005WA-00; Mon, 20 Apr 1998 14:16:12 -0400
Received: from FTIORL02/SpoolDir by FTIORL02.ENZIAN.COM (Mercury 1.40);
    20 Apr 98 14:16:32 EST
Received: from SpoolDir by FTIORL02 (Mercury 1.40); 20 Apr 98 14:16:00 EST
From: "Bill Storma" <bills@FTIORL02.ENZIAN.COM>
Organization: Future Technologies, Inc.
To: info-performer@sgi.com
Date: Mon, 20 Apr 1998 14:15:57 EST
Subject: Problem finding LOD nodes with pfFindNode
Message-ID: <16B17E3533A@FTIORL02.ENZIAN.COM>
Status: O

I am having trouble getting the Performer pfFindNode () routine to 
find all occurances of LOD nodes in a model.  Specifically, I have a 
model, built with MultiGen 14.3 and loaded with the Multigen Flight 
loader under Vega, that has 5 defined LOD nodes; LOD #1 thru LOD #5.  
When I use the pfFindNode routine, it only finds LOD #1, it cannot 
find any of the other LOD nodes.  The routine does find all the named 
groups correctly, so I know the call works on some node types.

The system in question is an ONYX RE2, running IRIX 5.3, Performer 
2.02, Multigen 14.3 and Vega 2.0.2.

 My question is, is this a problem with performer or is there a 
problem with the loader ?   How do i fix this problem ?

Thanks.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Bill Storma                     Phone:  407-384-6900
Future Technologies             FAX:    407-381-1010
Orlando, Fl.  32826             e-mail: bills@fti.enzian.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 13:17:25 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA24522 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 12:58:18 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA24495 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 12:58:17 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA14250923
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 12:58:16 -0700 (PDT)
Received: from acetef.nawcad.navy.mil (acetef.nawcad.navy.mil [140.229.93.252]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA13500
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 12:58:13 -0700 (PDT)
	mail_from (sbrabson@southernmaryland.com)
Received: from acetef (acetef.nawcad.navy.mil [140.229.93.252]) by acetef.nawcad.navy.mil (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA06780 for <info-performer@sgi.com>; Mon, 20 Apr 1998 16:01:38 -0400
Sender: sbrabson@southernmaryland.com
Message-ID: <353BA9A2.41C6@southernmaryland.com>
Date: Mon, 20 Apr 1998 16:01:38 -0400
From: Scott Brabson <sbrabson@southernmaryland.com>
Organization: Web Constructors
X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Master ClipTextures
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hello All,

I am trying to manipulate two MPCliptextures. I understand that the
first MPCliptexture added to the Pipe becomes the master. Every
MPClipTexture added after the first becomes a slave. Can I change the
Slave to become the Master and vice versa?

I used pfMPClipTextureMaster() setting the slave as the master. Thinking
the API which make the old master a slave. Performer spit out a warning
"Can't use slave as a master". I also tried to remove the MPCliptextures
from the Pipe using pfRemoveMPClipTexturePipe() and then Add
MPCliptextures in the new Master-Slave order but when I try to remove
the master the app core dumps.

Has anyone dealt with this? Any help or comments would be greatly
appreciated!

Thanks,
Scott Brabson
DCS Corporation
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 18:30:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA25186 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 18:14:45 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA25159 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 18:14:44 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA14444755
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 18:14:43 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id SAA12094
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 18:14:39 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id SAA10066 for <info-performer@sgi.com>; Mon, 20 Apr 1998 18:25:30 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id BAA26653 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Tue, 21 Apr 1998 01:15:36 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA20663 for info-performer@sgi.com; Mon, 20 Apr 1998 18:15:35 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804201815.ZM20661@logan.engr.multigen.com>
Date: Mon, 20 Apr 1998 18:15:35 -0700
In-Reply-To: "Bill Storma" <bills@FTIORL02.ENZIAN.COM>
        "Problem finding LOD nodes with pfFindNode" (Apr 20,  2:15pm)
References: <16B17E3533A@FTIORL02.ENZIAN.COM>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Re: Problem finding LOD nodes with pfFindNode
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 20,  2:15pm, Bill Storma wrote:
>I am having trouble getting the Performer pfFindNode () routine to
>find all occurances of LOD nodes in a model.  Specifically, I have a
>model, built with MultiGen 14.3 and loaded with the Multigen Flight
>loader under Vega, that has 5 defined LOD nodes; LOD #1 thru LOD #5.
>When I use the pfFindNode routine, it only finds LOD #1, it cannot
>find any of the other LOD nodes.

The loader combines all sibling lod's into as few pfLOD nodes as possible,
given their attributes.

>How do i fix this problem ?

Disable the .flt loader mode PFFLT_COMBINELODS (token value is 3). Doing this
will hurt your CULL performance a bit, but the node's will be there for you to
find.

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 23:47:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA25594 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 23:33:12 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id XAA25568 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 23:33:11 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA14433623
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 23:33:10 -0700 (PDT)
Received: from syseca.syseca.fr (syseca.syseca.fr [195.101.38.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id XAA21720
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 23:33:08 -0700 (PDT)
	mail_from (gce@syseca.fr)
Received: from anna.internet.syseca (anna [142.19.2.5])
	by syseca.syseca.fr (8.8.8/8.8.8) with SMTP id IAA21497
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 08:33:07 +0200 (MET DST)
Received: by anna.internet.syseca (940816.SGI.8.6.9/930416.SGI)
	for info-performer@sgi.com id IAA07145; Tue, 21 Apr 1998 08:31:58 +0200
Date: Tue, 21 Apr 1998 08:31:58 +0200
From: gce@syseca.fr (Cedric Gautier)
Message-Id: <199804210631.IAA07145@anna.internet.syseca>
To: info-performer@sgi.com
Status: O


 Cedric Gautier - THOMSON - tel:33(0)141480352 fax:33(0)141480681
 Simulation Department - 3D Computer Graphics and Virtual Reality
 gce@syseca.fr or www.syseca.thomson-csf.com/english/cha1/SDA.HTM
 SYSECA / 66-68 avenue Pierre Brossolette 92240 MALAKOFF / FRANCE
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 20 23:47:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA25622 for info-performer-dist@holodeck.engr.sgi.com; Mon, 20 Apr 1998 23:34:14 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id XAA25596 for <info-performer@holodeck.engr.sgi.com>; Mon, 20 Apr 1998 23:34:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA14077018
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 20 Apr 1998 23:34:13 -0700 (PDT)
Received: from syseca.syseca.fr (syseca.syseca.fr [195.101.38.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id XAA21854
	for <info-performer@sgi.com>; Mon, 20 Apr 1998 23:34:10 -0700 (PDT)
	mail_from (gce@syseca.fr)
Received: from anna.internet.syseca (anna [142.19.2.5])
	by syseca.syseca.fr (8.8.8/8.8.8) with SMTP id IAA21501
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 08:33:56 +0200 (MET DST)
Received: by anna.internet.syseca (940816.SGI.8.6.9/930416.SGI)
	for info-performer@sgi.com id IAA07149; Tue, 21 Apr 1998 08:32:47 +0200
Date: Tue, 21 Apr 1998 08:32:47 +0200
From: gce@syseca.fr (Cedric Gautier)
Message-Id: <199804210632.IAA07149@anna.internet.syseca>
To: info-performer@sgi.com
Status: O


 Cedric Gautier - THOMSON - tel:33(0)141480352 fax:33(0)141480681
 Simulation Department - 3D Computer Graphics and Virtual Reality
 gce@syseca.fr or www.syseca.thomson-csf.com/english/cha1/SDA.HTM
 SYSECA / 66-68 avenue Pierre Brossolette 92240 MALAKOFF / FRANCE
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 02:40:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA26041 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 02:20:51 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id CAA26014 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 02:20:50 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA14577332
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 02:20:49 -0700 (PDT)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id CAA24851
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 02:20:29 -0700 (PDT)
	mail_from (Jerome.Grosjean@inria.fr)
Received: from mysore.inria.fr (mysore.inria.fr [128.93.24.79])
	by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id LAA26502;
	Tue, 21 Apr 1998 11:20:23 +0200 (MET DST)
Received: from mysore (localhost [127.0.0.1])
	by mysore.inria.fr (8.8.5/8.8.7) with SMTP id JAA22837;
	Tue, 21 Apr 1998 09:20:20 GMT
Sender: Jerome.Grosjean@inria.fr
Message-ID: <353C64D4.ABD@inria.fr>
Date: Tue, 21 Apr 1998 11:20:20 +0200
From: Jerome Grosjean <Jerome.Grosjean@inria.fr>
X-Mailer: Mozilla 3.01SC-SGI (X11; I; IRIX64 6.2 IP28)
MIME-Version: 1.0
To: info-performer@sgi.com
CC: Jerome.Grosjean@inria.fr
Subject: Generating textures on the fly
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

We want to use a texture calculated on the fly. 
For that we need to get one of the computed images in the texture
buffer. We looked at the perf-97-06+247 message from Amaury Aubel
that was very useful but we failed to find out:

- how to select the channel we want to send to the pbuffer or auxbuffer.
This channel needs to be different from the current view channel.

- which draw and read parameters to use with the glXMakeCurrentReadSGI
function. 
For the read parameter, we would like to know how to indicate which
pbuffer
(resp. auxbuffer) we want to read. For the draw parameter, we wood like
to know how to
indicate to put the image in the texture buffer.


 -----------------------------------------------------------------------
 Jerome Grosjean                |
 INRIA                          |    Email: Jerome.Grosjean@inria.fr
 Domaine de Voluceau            |
 B.P. 105                       |    Tel: +33 (0)1 39 63 54 23
 78153 Le Chesnay Cedex         |    Fax: +33 (0)1 39 63 59 95
 FRANCE                         |
 -----------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 04:35:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA26306 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 04:19:20 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA26279 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 04:19:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA14474394
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 04:19:13 -0700 (PDT)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA17564
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 04:19:10 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id NAA02748; Tue, 21 Apr 1998 13:28:06 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma002726; Tue, 21 Apr 98 13:27:58 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id NAA03728;
	Tue, 21 Apr 1998 13:18:31 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804211118.NAA03728@s00sn1.fel.tno.nl>
Subject: Re: Problem finding LOD nodes with pfFindNode
To: marcus@multigen.com (Marcus Barnes)
Date: Tue, 21 Apr 1998 13:18:31 +0200 (MET DST)
Cc: info-performer@sgi.com
In-Reply-To: <9804201815.ZM20661@logan.engr.multigen.com> from "Marcus Barnes" at Apr 20, 98 06:15:35 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Marcus Barnes wrote:
> 
> On Apr 20,  2:15pm, Bill Storma wrote:
> >I am having trouble getting the Performer pfFindNode () routine to
> >find all occurances of LOD nodes in a model.  Specifically, I have a
> >model, built with MultiGen 14.3 and loaded with the Multigen Flight
> >loader under Vega, that has 5 defined LOD nodes; LOD #1 thru LOD #5.
> >When I use the pfFindNode routine, it only finds LOD #1, it cannot
> >find any of the other LOD nodes.
> 
> The loader combines all sibling lod's into as few pfLOD nodes as possible,
> given their attributes.
> 
> >How do i fix this problem ?
> 
> Disable the .flt loader mode PFFLT_COMBINELODS (token value is 3). Doing this
> will hurt your CULL performance a bit, but the node's will be there for you to
> find.
> 
> Regards.
> --
> + Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +

Maybe a possible solution is naming a subnode for every LOD, not the
LOD note itself. And if it will be removed during the clean phase then
you can use the flight loader callback to disable cleaning of a
certain node.

Mario
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 07:42:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA26618 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 07:31:41 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA26591 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 07:31:39 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA14269636
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 07:31:39 -0700 (PDT)
Received: from vista.taccsf.kirtland.af.mil (vista.taccsf.kirtland.af.mil [132.62.150.76]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA04553
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 07:31:37 -0700 (PDT)
	mail_from (suzie@TACCSF.KIRTLAND.AF.MIL)
Received: by VISTA.TACCSF.KIRTLAND.AF.MIL with Internet Mail Service (5.5.1960.3)
	id <291FLYYV>; Tue, 21 Apr 1998 08:31:29 -0600
Message-ID: <214A87629D4FD111931F0060972989BA072E98@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Isect
Date: Tue, 21 Apr 1998 08:31:28 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD6D32.2C0B4BD0"
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD6D32.2C0B4BD0
Content-Type: text/plain

Hi All,

We're running a Line-of-Sight program which uses performer libraries and
isect to calculate the height of terrain given a certain lat/lon that
has been converted to x,y positions.  There are some points on the
database which are not returning valid isect hits.  I've run some tests
and have determined that there are some points within a certain polygon
which return a valid isect and within the same polygon there are other
points which don't have valid isect returns.  

I don't know what else to try to figure this one out.  I didn't write
the code.  Of course the person who did has since left.

Example of code:

float TerrainServer::elevation(int x, int y)
{
	pfCoord	view;
	pfHit	**hits[32];
	int	isect;

	//update location of intersection segment
	segset.segs[0].pos.set(x,y,2500.0f);
	view.xyz.set(x,y,2500.0f);
	view.hpr.set(0.0f, -90.0f, 0.0f);
	chan->setView(view.xyz,view.hpr);

	// do an intersection test against the scene graph
	isect = root->isect(&segset,hits);
	// if successful, set our height to that of the point of contact
	// plus a small offset
	if (isect)
	{
		pfVec3 pnt, xpnt;
		pfMatrix xmat, xmat2;
		(*hits[0])->query(PFQHIT_POINT, &pnt);

		// transform object point into scene coordinates
		(*hits[0]->query(PFQHIT_XFORM, &xmat);
		xpnt.xformPt(pnt, xmat);
		
		return (xpnt[PF_Z] - altOffset_);
	}
}

Thanks in advance for any assistance.

Suzie	

------ =_NextPart_001_01BD6D32.2C0B4BD0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>Isect</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi All,</FONT>
</P>

<P><FONT SIZE=3D2>We're running a Line-of-Sight program which uses =
performer libraries and isect to calculate the height of terrain given =
a certain lat/lon that has been converted to x,y positions.&nbsp; There =
are some points on the database which are not returning valid isect =
hits.&nbsp; I've run some tests and have determined that there are some =
points within a certain polygon which return a valid isect and within =
the same polygon there are other points which don't have valid isect =
returns.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>I don't know what else to try to figure this one =
out.&nbsp; I didn't write the code.&nbsp; Of course the person who did =
has since left.</FONT></P>

<P><FONT SIZE=3D2>Example of code:</FONT>
</P>

<P><FONT SIZE=3D2>float TerrainServer::elevation(int x, int y)</FONT>
<BR><FONT SIZE=3D2>{</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>pfCoord&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; view;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>pfHit**hits[32];</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>int&nbsp;&nbsp; isect;</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>//update =
location of intersection segment</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>segset.segs[0].pos.set(x,y,2500.0f);</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>view.xyz.set(x,y,2500.0f);</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>view.hpr.set(0.0f, -90.0f, 0.0f);</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>chan-&gt;setView(view.xyz,view.hpr);</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>// do an =
intersection test against the scene graph</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>isect =3D =
root-&gt;isect(&amp;segset,hits);</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>// if =
successful, set our height to that of the point of contact</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>// plus a =
small offset</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>if =
(isect)</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>{</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>pfVec3 pnt, xpnt;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>pfMatrix xmat, =
xmat2;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>(*hits[0])-&gt;query(PFQHIT_POINT, &amp;pnt);</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>// transform object point =
into scene coordinates</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>(*hits[0]-&gt;query(PFQHIT_XFORM, &amp;xmat);</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>xpnt.xformPt(pnt, =
xmat);</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>return (xpnt[PF_Z] - =
altOffset_);</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>}</FONT>
<BR><FONT SIZE=3D2>}</FONT>
</P>

<P><FONT SIZE=3D2>Thanks in advance for any assistance.</FONT>
</P>

<P><FONT SIZE=3D2>Suzie&nbsp;&nbsp;</FONT>=20
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD6D32.2C0B4BD0--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 08:08:23 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA26718 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 07:47:06 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA26691 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 07:47:05 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA14304238
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 07:47:05 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA09085
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 07:47:04 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA14652545;
	Tue, 21 Apr 1998 07:47:04 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA12848; Tue, 21 Apr 1998 07:47:03 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353CB167.C0D799BD@sgi.com>
Date: Tue, 21 Apr 1998 07:47:03 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
CC: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: Isect
References: <214A87629D4FD111931F0060972989BA072E98@VISTA.TACCSF.KIRTLAND.AF.MIL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

> Bemis, Suzie CEI-TACCSF wrote:
> 
> Hi All,
> 
> We're running a Line-of-Sight program which uses performer libraries
> and isect to calculate the height of terrain given a certain lat/lon
> that has been converted to x,y positions.  There are some points on
> the database which are not returning valid isect hits.  I've run some
> tests and have determined that there are some points within a certain
> polygon which return a valid isect and within the same polygon there
> are other points which don't have valid isect returns.
> 
> I don't know what else to try to figure this one out.  I didn't write
> the code.  Of course the person who did has since left.
> 

This came up recently,

Have you computed the geometry bound box correctly?

Have you changed the geometry, some data is cached by the isector
traversal so you need to avoid cacheing of this data where you are
changing the geometry.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 09:25:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA27068 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 09:06:58 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA27041 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 09:06:56 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA14600645
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 09:06:55 -0700 (PDT)
Received: from vista.taccsf.kirtland.af.mil (vista.taccsf.kirtland.af.mil [132.62.150.76]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA11249
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 09:06:53 -0700 (PDT)
	mail_from (Sorroche@TACCSF.KIRTLAND.AF.MIL)
Received: by VISTA.TACCSF.KIRTLAND.AF.MIL with Internet Mail Service (5.5.1960.3)
	id <291FLY6M>; Tue, 21 Apr 1998 10:06:52 -0600
Message-ID: <214A87629D4FD111931F0060972989BA240695@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Missile Entities
Date: Tue, 21 Apr 1998 10:06:44 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD6D3F.7F7063B0"
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD6D3F.7F7063B0
Content-Type: text/plain

Hey;

	I'm having a visual problem with missile flyouts.  Whenever I
fire a missile, it first looks like two missiles are fired when only one
is actually fired, and also the entity does not fly out smooth, but
"jumps", so the missile and missile trail look like "dots" across the
screen, rather than looking like a smooth movement as our air entities
are displayed.  Any hints on what to do or where to look?

Thanks

Joe


------ =_NextPart_001_01BD6D3F.7F7063B0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>Missile Entities</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hey;</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I'm having a visual problem with missile flyouts.&nbsp; =
Whenever I fire a missile, it first looks like two missiles are fired =
when only one is actually fired, and also the entity does not fly out =
smooth, but &quot;jumps&quot;, so the missile and missile trail look =
like &quot;dots&quot; across the screen, rather than looking like a =
smooth movement as our air entities are displayed.&nbsp; Any hints on =
what to do or where to look?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Joe</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD6D3F.7F7063B0--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 09:41:42 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA27157 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 09:32:33 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA27130 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 09:32:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA14716491
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 09:32:31 -0700 (PDT)
Received: from mule.bur.visidyne.com ([207.247.132.34]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA21188
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 09:32:29 -0700 (PDT)
	mail_from (sartor@visidyne.com)
Received: from spock.visidyne.hsv.com (spock.hsv.visidyne.com [208.208.196.10])
          by mule.bur.visidyne.com (8.8.7/8.8.4) with SMTP
	  id LAA05617 for <info-performer@sgi.com>; Tue, 21 Apr 1998 11:32:27 -0500 (EST)
Message-Id: <3.0.32.19980421113854.0069c6c8@mail.bur.visidyne.com>
X-Sender: sartor@mail.bur.visidyne.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 21 Apr 1998 11:38:55 -0500
To: info-performer@sgi.com
From: ken sartor <sartor@visidyne.com>
Subject: java 3d
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: O


Hi -

I know this is not the forum for this, but with so many graphics
gurus, i thought it might not hurt to ask: does anyone know when 
(if?) SGI expects to provide an implementation of Java 3D for IRIX?
Or where i might go to find out?

pfThanks!

ken

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 10:21:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA27359 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 10:06:46 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA27332 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 10:06:44 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA14508306
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 10:06:44 -0700 (PDT)
Received: from vista.taccsf.kirtland.af.mil (vista.taccsf.kirtland.af.mil [132.62.150.76]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA07808
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 10:06:41 -0700 (PDT)
	mail_from (suzie@TACCSF.KIRTLAND.AF.MIL)
Received: by VISTA.TACCSF.KIRTLAND.AF.MIL with Internet Mail Service (5.5.1960.3)
	id <291FLY7Q>; Tue, 21 Apr 1998 11:06:35 -0600
Message-ID: <214A87629D4FD111931F0060972989BA072E9A@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: pfdLoadFile_flt
Date: Tue, 21 Apr 1998 11:06:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD6D47.D66B07B0"
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD6D47.D66B07B0
Content-Type: text/plain

After upgrading to Performer 2.2 from 2.0, I got the following message
after attempting to run with a .flt file.

pfdLoadFile() - Unable to load file 'file.flt' because of problem
finding pfdLoadFile_flt

What changed?

Thanks,
Suzie

------ =_NextPart_001_01BD6D47.D66B07B0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.1960.3">
<TITLE>pfdLoadFile_flt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>After upgrading to Performer 2.2 from 2.0, I got the following message after attempting to run with a .flt file.</FONT>
</P>

<P><FONT SIZE=2>pfdLoadFile() - Unable to load file 'file.flt' because of problem finding pfdLoadFile_flt</FONT>
</P>

<P><FONT SIZE=2>What changed?</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Suzie</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD6D47.D66B07B0--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 12:18:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA27855 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 12:03:39 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA27828 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 12:03:38 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA14518400
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 12:03:37 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA29664
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 12:03:36 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA13150165;
	Tue, 21 Apr 1998 12:03:35 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA13443; Tue, 21 Apr 1998 12:03:34 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353CED86.1973222@sgi.com>
Date: Tue, 21 Apr 1998 12:03:34 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
CC: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: Missile Entities
References: <214A87629D4FD111931F0060972989BA240695@VISTA.TACCSF.KIRTLAND.AF.MIL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

> Sorroche, Joe CEI-TACCSF wrote:
> 
> Hey;
> 
>         I'm having a visual problem with missile flyouts.  Whenever I
> fire a missile, it first looks like two missiles are fired when only
> one is actually fired, and also the entity does not fly out smooth,
> but "jumps", so the missile and missile trail look like "dots" across
> the screen, rather than looking like a smooth movement as our air
> entities are displayed.  Any hints on what to do or where to look?
> 

There's nothing here to suggest what the problem is.

Are you using a product like Vega or did you write
your own missile code.

Could there be a problem with your texture or the texture
coordinates you apply?

Cheers,Angus.


-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 12:37:18 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA27932 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 12:20:00 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA27905 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 12:19:59 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA14727017
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 12:19:58 -0700 (PDT)
Received: from hotmail.com (f98.hotmail.com [207.82.250.217]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA05844
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 12:19:57 -0700 (PDT)
	mail_from (inge_e_henriksen@hotmail.com)
Received: (qmail 24283 invoked by uid 0); 21 Apr 1998 19:19:56 -0000
Message-ID: <19980421191956.24281.qmail@hotmail.com>
Received: from 195.1.163.172 by www.hotmail.com with HTTP;
	Tue, 21 Apr 1998 12:19:56 PDT
X-Originating-IP: [195.1.163.172]
From: "Inge Eivind Henriksen" <inge_e_henriksen@hotmail.com>
To: info-performer@sgi.com
Subject: Freelance modeler
Content-Type: text/plain
Date: Tue, 21 Apr 1998 12:19:56 PDT
Status: O

Hello Performers
----------------
I am offering my services as a freelance modeler with MultiGen(TM) on a 
global basis. Please visit my new WEB-page at 
http://home.sol.no/~arthomas/ for samples of my work plus more.

Greetings from Inge E.Henriksen

------------------------------------------------------------
Inge E.Henriksen, Database designer
Kemivn.20, 9011 Tromsoe, Norway
Tlf.+47 77 65 64 32
Mailto:inge_e_henriksen@hotmail.com
------------------------------------------------------------
*********************************************** John.3.16-21
------------------------------------------------------------
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 14:16:10 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA28361 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 14:01:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA28334 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 14:01:35 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA6844567;
	Tue, 21 Apr 1998 14:01:35 -0700 (PDT)
Received: from helios.Discreet.QC.CA (discreet.com [207.219.240.29]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id OAA19113; Tue, 21 Apr 1998 14:01:32 -0700 (PDT)
	mail_from (dery@Discreet.COM)
Received: from cuba by helios.Discreet.QC.CA
	id RAA29265; Tue, 21 Apr 1998 17:01:15 -0400
Errors-To: postmaster@Discreet.COM
Received: from atlantis (atlantis [172.16.100.56]) by cuba (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01109; Tue, 21 Apr 1998 17:01:30 -0400
Received: (from dery@localhost) by atlantis (950413.SGI.8.6.12/) id RAA09575; Tue, 21 Apr 1998 17:01:30 -0400
From: "Jean-Luc Dery" <dery@Discreet.COM>
Message-Id: <9804211701.ZM9603@atlantis>
Date: Tue, 21 Apr 1998 17:01:30 -0400
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Channel viewpoint stepping
Cc: dery@cuba.Discreet.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi people,

We are having problems with the way the channel viewpoint is being updated. Our
channel viewpoint steps every time the channel frame rate drops from 60Hz to
30Hz due to scene complexity. This happens only during the transitions. We are
quite sure that the problem comes from the way the channel viewpoint is managed
within our Performer based application since when frame rate is stable (30Hz or
60Hz), the viewpoint movements are perfectly fluid. The problem occurs only
when the frame rate changes. The value used for the viewpoint setting is
computed and updated in a parallele process which always runs at 60Hz.

Is the channel viewpoint set in the APP from pfChannel API frame conherent in
the 3 stage APP CULL DRAW pipeline? I would suspect so since the pfChannel is a
libpf object.

When the frame rate drops at frame 5 (D3) in the phase lock mode

frame    1    2    3    4    5    6    7
APP     A1 | A2 | A3 | A4 | A5 | A6 | A7
CULL       | C1 | C2 | C3 | C4 | C5 | C6
DRAW       |    | D1 | D2 | D3.|.   | D5

Is the viewpoint used to draw at frame 7 (D5) really set from A5 ?

How can we guaranty channel viewpoint fluid movement, or what could we be doing
wrong that could cause the stepping in our application. Is there a need to
interpolate viewpoint when frame rate changes.

Thanks in advance for any help,

Jean-Luc

-- 
_____________________________________________________________________________

Jean-Luc Dery                         Discreet Logic
System Engineer                       10 Duke Street
3-D Graphics Technology               Montreal (Quebec), Canada, H3C 2L7
                                      Tel: (514) 954-7239
Email: jean-lucD@discreet.com         Fax: (514) 393-0110
_____________________________________________________________________________
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 15:06:43 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA28589 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 14:53:14 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA28562 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 14:53:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA14541404
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 14:53:13 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA11954
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 14:53:12 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA14717872;
	Tue, 21 Apr 1998 14:53:10 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA01146; Tue, 21 Apr 1998 14:53:10 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353D1545.C6CBBB7C@sgi.com>
Date: Tue, 21 Apr 1998 14:53:09 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Jean-Luc Dery <dery@Discreet.COM>
CC: info-performer@sgi.com, dery@cuba.Discreet.COM
Subject: Re: Channel viewpoint stepping
References: <9804211701.ZM9603@atlantis>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Jean-Luc Dery wrote:
> 
> Hi people,
> 
> We are having problems with the way the channel viewpoint is being updated. Our
> channel viewpoint steps every time the channel frame rate drops from 60Hz to
> 30Hz due to scene complexity. This happens only during the transitions. We are
> quite sure that the problem comes from the way the channel viewpoint is managed
> within our Performer based application since when frame rate is stable (30Hz or
> 60Hz), the viewpoint movements are perfectly fluid. The problem occurs only
> when the frame rate changes. The value used for the viewpoint setting is
> computed and updated in a parallele process which always runs at 60Hz.
> 
> Is the channel viewpoint set in the APP from pfChannel API frame conherent in
> the 3 stage APP CULL DRAW pipeline? I would suspect so since the pfChannel is a
> libpf object.
> 
> When the frame rate drops at frame 5 (D3) in the phase lock mode
> 
> frame    1    2    3    4    5    6    7
> APP     A1 | A2 | A3 | A4 | A5 | A6 | A7
> CULL       | C1 | C2 | C3 | C4 | C5 | C6
> DRAW       |    | D1 | D2 | D3.|.   | D5
> 
> Is the viewpoint used to draw at frame 7 (D5) really set from A5 ?
> 
> How can we guaranty channel viewpoint fluid movement, or what could we be doing
> wrong that could cause the stepping in our application. Is there a need to
> interpolate viewpoint when frame rate changes.
> 
> Thanks in advance for any help,
> 

Unless you know you're goind to miss your frame rate it's too late to do
anything.

I mean you've started to draw if you don't make the vertical retrace
then the
old image will be preserved and the currently rendered image will arrive
late.
In the mean time the application could still be updating depending on
phase ,
and this is as it should be so eventually when you make frame rate again
your
eye point will catch up.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 15:06:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA28626 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 14:58:51 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA28599 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 14:58:50 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA13370974
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 14:58:49 -0700 (PDT)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA14257
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 14:58:47 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id QAA21342; Tue, 21 Apr 1998 16:58:41 -0500 (CDT)
Date: Tue, 21 Apr 1998 16:58:43 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
cc: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: Missile Entities
In-Reply-To: <214A87629D4FD111931F0060972989BA240695@VISTA.TACCSF.KIRTLAND.AF.MIL>
Message-ID: <Pine.SGI.3.96.980421165714.10955B-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Tue, 21 Apr 1998, Sorroche, Joe CEI-TACCSF wrote:

> 	I'm having a visual problem with missile flyouts.  Whenever I
> fire a missile, it first looks like two missiles are fired when only one
> is actually fired, and also the entity does not fly out smooth, but
> "jumps", so the missile and missile trail look like "dots" across the
> screen, rather than looking like a smooth movement as our air entities
> are displayed.  Any hints on what to do or where to look?

Are you updating at 30Hz?

If so, that is what you get. You have to make your system run at 60Hz
to make this go away.

There is a complicated explanation of why this is - let me know
if you want it - in the meantime, run at 60Hz.

Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 15:30:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA28703 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 15:14:53 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA28676 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 15:14:52 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA14745263
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 15:14:52 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA21557
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 15:14:51 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA14845229;
	Tue, 21 Apr 1998 15:14:50 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA01213; Tue, 21 Apr 1998 15:14:49 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353D1A59.47ED7839@sgi.com>
Date: Tue, 21 Apr 1998 15:14:49 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Steve Baker <sbaker@link.com>
CC: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>,
        "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: Missile Entities
References: <Pine.SGI.3.96.980421165714.10955B-100000@lechter.bgm.link.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Steve Baker wrote:
> 
> On Tue, 21 Apr 1998, Sorroche, Joe CEI-TACCSF wrote:
> 
> >       I'm having a visual problem with missile flyouts.  Whenever I
> > fire a missile, it first looks like two missiles are fired when only one
> > is actually fired, and also the entity does not fly out smooth, but
> > "jumps", so the missile and missile trail look like "dots" across the
> > screen, rather than looking like a smooth movement as our air entities
> > are displayed.  Any hints on what to do or where to look?
> 
> Are you updating at 30Hz?
> 
> If so, that is what you get. You have to make your system run at 60Hz
> to make this go away.
> 
> There is a complicated explanation of why this is - let me know
> if you want it - in the meantime, run at 60Hz.
> 

Aha! I assumed the question was about missile trails, hence the texture
nonsense but ofcourse Steve is correct.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 21 15:41:30 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA28955 for info-performer-dist@holodeck.engr.sgi.com; Tue, 21 Apr 1998 15:31:51 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA28928 for <info-performer@holodeck.engr.sgi.com>; Tue, 21 Apr 1998 15:31:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA14847467
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 21 Apr 1998 15:31:48 -0700 (PDT)
Received: from challenge (challenge.silicon.cl [200.29.42.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id PAA28894
	for <info-performer@sgi.com>; Tue, 21 Apr 1998 15:31:41 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Tue, 21 Apr 1998 19:31:08 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma006895; Tue, 21 Apr 98 19:31:02 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA19482; Tue, 21 Apr 1998 18:34:48 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA04570; Tue, 21 Apr 1998 18:45:20 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9804211845.ZM4568@krusty>
Date: Tue, 21 Apr 1998 18:45:20 -0400
In-Reply-To: "Jean-Luc Dery" <dery@discreet.com>
        "Channel viewpoint stepping" (Apr 21,  5:01pm)
References: <9804211701.ZM9603@atlantis>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Jean-Luc Dery" <dery@discreet.com>
Subject: Re: Channel viewpoint stepping
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 21,  5:01pm, Jean-Luc Dery wrote:
> Subject: Channel viewpoint stepping
> Hi people,
>
> We are having problems with the way the channel viewpoint is being updated.
Our
> channel viewpoint steps every time the channel frame rate drops from 60Hz to
> 30Hz due to scene complexity. This happens only during the transitions. We
are
> quite sure that the problem comes from the way the channel viewpoint is
managed
> within our Performer based application since when frame rate is stable (30Hz
or
> 60Hz), the viewpoint movements are perfectly fluid. The problem occurs only
> when the frame rate changes. The value used for the viewpoint setting is
> computed and updated in a parallele process which always runs at 60Hz.
>
> Is the channel viewpoint set in the APP from pfChannel API frame conherent in
> the 3 stage APP CULL DRAW pipeline? I would suspect so since the pfChannel is
a
> libpf object.
>
> When the frame rate drops at frame 5 (D3) in the phase lock mode
>
> frame    1    2    3    4    5    6    7
> APP     A1 | A2 | A3 | A4 | A5 | A6 | A7
> CULL       | C1 | C2 | C3 | C4 | C5 | C6
> DRAW       |    | D1 | D2 | D3.|.   | D5
>
> Is the viewpoint used to draw at frame 7 (D5) really set from A5 ?
>
> How can we guaranty channel viewpoint fluid movement, or what could we be
doing
> wrong that could cause the stepping in our application. Is there a need to
> interpolate viewpoint when frame rate changes.
>
> Thanks in advance for any help,
>
> Jean-Luc
>
> --
> _____________________________________________________________________________
>
> Jean-Luc Dery                         Discreet Logic
> System Engineer                       10 Duke Street
> 3-D Graphics Technology               Montreal (Quebec), Canada, H3C 2L7
>                                       Tel: (514) 954-7239
> Email: jean-lucD@discreet.com         Fax: (514) 393-0110
> _____________________________________________________________________________
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from Jean-Luc Dery


This could well be a visual effect. But just to make sure... How or who is
updating the viewpoint. Most of the time this is done by giving a trajectory
path and a velocity which combined give the speed vector. Since the velocity
must be calculated by discreet steps during every frame there is usually a
calculation of the form:

	Velocity[Km/Hr} --->Velocity[mts/sec] and then,

	Velocity[mts/sec]/Frame Rate[frames/sec]=Velocity [mts/frame]

	which would give the distance in meters (or any other unit) you must
travel during each frame to get the desired velocity in [mts/sec]. If you
assume constant frame rate then this is just a matter of multiplying current
speed by a pre-calculated constant. But if the frame rate drops down and you
are still assuming it's constant then you'll end up traveling at half the speed
since the above calculation is only done half as many times as it should during
the same period of time. If you were moving at constant 60[mts/sec] then the
above calculation will tell you that at 60Hz you should move 1 meter for each
frame, after 60 frames (1 second at 60Hz) you have move 60 times 1 meter, thus
60 meters/sec. If you suddenly drop down to 30Hz, then after 1 second (30
frames) you have only moved 30 times 1 meter --> 30 mts/sec.

-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Andres Bello 2777, Of. 602
E-mail: asaez@silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 105       Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 01:06:59 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA29898 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 00:51:46 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id AAA29871 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 00:51:45 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA14760174
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 00:51:45 -0700 (PDT)
Received: from flatland.engr.sgi.com ([198.29.106.64]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id AAA18795
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 00:51:44 -0700 (PDT)
	mail_from (insinger@flatland.engr.sgi.com)
Received: (from insinger@localhost) by flatland.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA27174 for info-performer@sgi.com; Wed, 22 Apr 1998 00:51:40 -0700
Date: Wed, 22 Apr 1998 00:51:40 -0700
From: insinger@flatland.engr.sgi.com (Chris Insinger)
Message-Id: <9804220051.ZM27172@flatland.engr.sgi.com>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Performer at ITEC
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hello Everybody,

Next week the ITEC conference will be held in Lausanne
(Switzerland) from April 28-30.

Silicon Graphics will have a stand at which all our great hardware
will be shown, along with some of the spectacular applications our
partners have developed. Of course Performer is well represented.

Please join us for a Friends of Performer meeting on Tuesday,
April 28th, from 5:30pm to 7:00pm at the Palais de Beaulieu.

We will be discussing several of the new features in Performer
2.2, including Clipmapping, ASD and Calligraphics. Other topics
will include a discussion of the Performer product roadmap and
Performer's evolution in light of Fahrenheit. There will be time
to answer any questions you may have.

To be assured of a seat, please come to the SGI stand on the show
floor to get a ticket for this meeting - hurry because it's first
come first serve!

We look forward to seeing you there!

Regards,

Chris

-- 
 ___________________________________________________________________

    Chris Insinger 
    Product Manager 3D Graphics APIs 

    Silicon Graphics, Inc.             Tel: +1 (650) 933-3734
    2011 N. Shoreline Blvd. MS 8-525   Fax: +1 (650) 964-8671
    Mountain View, CA 94043-1389       Email: insinger@engr.sgi.com

 ___________________________________________________________________

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 04:12:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA00229 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 03:46:09 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id DAA00198 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 03:46:07 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id DAA15071557
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 03:46:07 -0700 (PDT)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id DAA23101
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 03:46:02 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id MAA06582; Wed, 22 Apr 1998 12:55:06 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma006513; Wed, 22 Apr 98 12:54:45 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id MAA05803;
	Wed, 22 Apr 1998 12:45:21 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804221045.MAA05803@s00sn1.fel.tno.nl>
Subject: Re: Isect
To: suzie@TACCSF.KIRTLAND.AF.MIL (Bemis Suzie CEI-TACCSF)
Date: Wed, 22 Apr 1998 12:45:21 +0200 (MET DST)
Cc: info-performer@sgi.com (Performer)
In-Reply-To: <214A87629D4FD111931F0060972989BA072E98@VISTA.TACCSF.KIRTLAND.AF.MIL> from "Bemis, Suzie CEI-TACCSF" at Apr 21, 98 08:31:28 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> Hi All,
> 
> We're running a Line-of-Sight program which uses performer libraries and
> isect to calculate the height of terrain given a certain lat/lon that
> has been converted to x,y positions.  There are some points on the
> database which are not returning valid isect hits.  I've run some tests
> and have determined that there are some points within a certain polygon
> which return a valid isect and within the same polygon there are other
> points which don't have valid isect returns.  
> 
> I don't know what else to try to figure this one out.  I didn't write
> the code.  Of course the person who did has since left.
> 
> Example of code:
> 
> float TerrainServer::elevation(int x, int y)
> {
> 	pfCoord	view;
> 	pfHit	**hits[32];
> 	int	isect;
> 
> 	//update location of intersection segment
> 	segset.segs[0].pos.set(x,y,2500.0f);
If you read the man page of pfNode on the section of intersction you
see that it's better to fill in some more fields of the segset
structure. They don't have a default value.
You must also fill in the direction of the segment and the length of
the segment.

    segset.mode = PFTRAV_IS_PRIM | PFTRAV_IS_CULL_BACK;
    segset.isectMask = ~0;  // intersect with everything
    segset.activeMask = 0x01;  // one segment specified
    segset.segs[0].pos.set(x,y,2500.0f);
    segset.segs[0].dir.set(0,0,-1.0f);
    segset.segs[0].length = 10000.0f;

> 	view.xyz.set(x,y,2500.0f);
> 	view.hpr.set(0.0f, -90.0f, 0.0f);
> 	chan->setView(view.xyz,view.hpr);
There is no need for these three lines.

Mario
> 
> 	// do an intersection test against the scene graph
> 	isect = root->isect(&segset,hits);
> 	// if successful, set our height to that of the point of contact
> 	// plus a small offset
> 	if (isect)
> 	{
> 		pfVec3 pnt, xpnt;
> 		pfMatrix xmat, xmat2;
> 		(*hits[0])->query(PFQHIT_POINT, &pnt);
> 
> 		// transform object point into scene coordinates
> 		(*hits[0]->query(PFQHIT_XFORM, &xmat);
> 		xpnt.xformPt(pnt, xmat);
> 		
> 		return (xpnt[PF_Z] - altOffset_);
> 	}
> }
> 
> Thanks in advance for any assistance.
> 
> Suzie	
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 08:17:45 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA00760 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 08:09:24 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA00731 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 08:09:17 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA15007636
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 08:09:17 -0700 (PDT)
Received: from iris.mit.edu (IRIS.MIT.EDU [18.152.0.135]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id IAA00262
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 08:09:15 -0700 (PDT)
	mail_from (dorrie@iris.mit.edu)
Received: (from dorrie@localhost) by iris.mit.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA08501; Wed, 22 Apr 1998 11:11:34 -0400
Date: Wed, 22 Apr 1998 11:11:34 -0400
Message-Id: <199804221511.LAA08501@iris.mit.edu>
From: Dorrie Hall <dorrie@iris.mit.edu>
To: info-performer@sgi.com
Subject: OCTANE RAM
Status: O

	I apologize for this not being a Performer question
but - has anyone had any luck with high density memory in 
an OCTANE?  Are there any special patches required?
Thanks, Dorrie

-- 
Dorrie Hall email:dorrie@mit.edu voice:(617)253-7841 FAX:(617)258-9535
MIT, N42-140
77 Massachusetts Avenue
Cambridge, MA 02139-4307
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 14:17:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA01402 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 14:02:48 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA01375 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 14:02:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA15202211
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 14:02:42 -0700 (PDT)
Received: from ptah.opensesame.com (ptah.cra.com [205.181.6.81]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA00198
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 14:02:36 -0700 (PDT)
	mail_from (smulgund@cra.com)
Received: from 205.181.6.126 by ptah.opensesame.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8)
	id JDZ5LNKZ; Wed, 22 Apr 1998 17:07:00 -0400
X-Sender: smulgund@mail.cra.com
Message-Id: <v03102803b1640a61f80e@[205.181.6.126]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 22 Apr 1998 17:02:27 -0400
To: info-performer@sgi.com
From: Sandeep Mulgund <smulgund@cra.com>
Subject: Problem with creating custom icon on minimized window
Status: O

Hello Performers,

I'm trying to create a custom icon for the minimized window of a Performer
application.  Per the Indigo Magic guidlines, I'm using some X functions to
define the WM_CLASS resource, as follows:

Display *dsp;
Window win;
dsp = pfGetCurWSConnection();
win = pipeWindow -> getWSWindow();
XClassHint* xch = XAllocClassHint();
char *resname = strdup("PilotStation");
xch -> res_name = strdup(resname);
xch -> res_class = strdup("PilotStationClass");
XSetClassHint(dsp, win, xch);

If I use 'xprop' on my running application window, it shows the resources
set to the correct values.  However, when I minimize the window, it shows
the default minimized icon, rather than my custom icon (which I've placed
in the correct directory, with the name PilotStation.icon).  What am I
doing wrong?  The only way it works is if I put a file called
"default.icon" in ~/.icon/.  It seems to be ignoring my definition of the
WM_CLASS resource.

Thanks,

Sandeep


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 15:02:25 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA01581 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 14:39:30 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA01554 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 14:39:26 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA15019204
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 14:39:26 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA17385
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 14:39:25 -0700 (PDT)
	mail_from (dwilliams@sarnoff.com)
Received: from pike ([130.33.96.3]) by postoffice.sarnoff.com
          (Netscape Messaging Server 3.5)  with SMTP id AAA4D26
          for <info-performer@sgi.com>; Wed, 22 Apr 1998 17:39:23 -0400
Sender: dcw@sarnoff.com
Message-ID: <353E6385.2781@sarnoff.com>
Date: Wed, 22 Apr 1998 17:39:17 -0400
From: Daniel Williams <dwilliams@sarnoff.com>
Organization: Systems & Scientific Software
X-Mailer: Mozilla 3.04GoldC-SGI (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Octane Channel Option and Performer2.2?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Has anyone used the Octane Channel Option with Performer2.2?

Neither /usr/share/Performer/src/pguide/libpf/C++/simple.C nor
/usr/share/Performer/src/pguide/libpf/C/pvchan.c work when the system
is in 4@640x480_60 mode. I believe I have the latest patches for the
Channel Option, #2858 and #2895.

My application doesn't even manage to open a window.

I modified simple.C to use PFMP_APPCULLDRAW mode and it opens a window
but then just spins at this location:

pfPipeVideoChannel::nb_isActive(<stripped>)["pfPipeVideoChannel.C":334]
pfPipeWindow::pf_assignPVChanIds(<stripped>) ["pfPipeWindow.C":1759]
pfPipeWindow::nb_setScreen(<stripped>) ["pfPipeWindow.C":524]
pfPipeWindow::pf_openWin(<stripped>) ["pfPipeWindow.C":2455]
pfPipeWindow::nb_open(<stripped>) ["pfPipeWindow.C":639]
main(argc = 2, argv = 0x7fff2f24) ["simple.C":120]
__istart(<stripped>) ["crt1tinit.s":13]

Pvchan never opens a window, either.

This is the output from /usr/gfx/gfxinfo -v:

Graphics board 0 is "IMPACTSR" graphics.
        Managed (":0.0") 1280x1024
        Product ID 0x2, 1 GE, 1 RE, 4 TRAMs
        MGRAS revision 0, RA revision 0
        HQ rev B, GE11 rev B, RE4 rev C, PP1 rev A,
        VC3 rev A, CMAP rev E, Heart rev D
        19" monitor (id 0x1)
        OCO board present (rev 2)

        Input Sync: Voltage - Video Level; Source - Internal; Genlocked
- False
        Channel 1:
         Origin = (0,0)
         Video Output: 640 pixels, 480 lines, 60.00Hz (4@640x480_60)
         Video Format Flags:  (none)
         Sync Disabled
         Using Gamma Map 0
        Channel 2:
         Origin = (640,0)
         Video Output: 640 pixels, 480 lines, 60.00Hz (4@640x480_60)
         Video Format Flags:  (none)
         Sync Disabled
         Using Gamma Map 0
        Channel 3:
         Origin = (0,480)
         Video Output: 640 pixels, 480 lines, 60.00Hz (4@640x480_60)
         Video Format Flags:  (none)
         Sync Disabled
         Using Gamma Map 0
        Channel 4:
         Origin = (640,480)
         Video Output: 640 pixels, 480 lines, 60.00Hz (4@640x480_60)
         Video Format Flags:  (none)
         Sync Disabled
         Using Gamma Map 0

All other graphics programs and demos that I've tried work fine, but
nothing Performer-based will work.

Help. Please?

Dan
--
Daniel Williams, Systems & Scientific Software
Independent Consultant to: Sarnoff Corporation
Voice: (609) 734-2153 Email: dwilliams@sarnoff.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 15:28:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA01708 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 15:10:01 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA01681 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 15:10:00 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA15345881
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 15:10:00 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id PAA00449
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 15:09:47 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id PAA25476 for <info-performer@sgi.com>; Wed, 22 Apr 1998 15:20:39 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id WAA08390 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Wed, 22 Apr 1998 22:10:46 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA24074 for info-performer@sgi.com; Wed, 22 Apr 1998 15:10:45 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804221510.ZM24072@logan.engr.multigen.com>
Date: Wed, 22 Apr 1998 15:10:45 -0700
In-Reply-To: "Bemis, Suzie CEI-TACCSF" <suzie@TACCSF.KIRTLAND.AF.MIL>
        "pfdLoadFile_flt" (Apr 21, 11:06am)
References: <214A87629D4FD111931F0060972989BA072E9A@VISTA.TACCSF.KIRTLAND.AF.MIL>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: pfdLoadFile_flt
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 21, 11:06am, Bemis, Suzie CEI-TACCSF wrote:
>
>After upgrading to Performer 2.2 from 2.0, I got the following message
>after attempting to run with a .flt file.

You are running the same "old" application or not?

>pfdLoadFile() - Unable to load file 'file.flt' because of problem
>finding pfdLoadFile_flt
>
>What changed?

While updating your Performer software you must not have installed one or more
of the following 2.2 subsystems:

performer_eoe.compatO32.performer2_0
performer_eoe.swO32.igl_performer
performer_eoe.swO32.ogl_performer

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 16:26:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA02043 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 16:12:25 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA02016 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 16:12:24 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA15201332
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 16:12:24 -0700 (PDT)
Received: from silver.anu.edu.au (silver.anu.edu.au [150.203.162.26]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id QAA03884
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 16:12:12 -0700 (PDT)
	mail_from (bcorrie@silver.anu.edu.au)
Received: from silver (bcorrie@localhost [127.0.0.1]) by silver.anu.edu.au (8.8.2/8.8.2) with ESMTP id JAA01102; Thu, 23 Apr 1998 09:11:55 +1000 (EST)
Message-Id: <199804222311.JAA01102@silver.anu.edu.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: insinger@flatland.engr.sgi.com (Chris Insinger)
cc: info-performer@sgi.com, bcorrie@silver.anu.edu.au
Subject: Re: Performer at ITEC 
In-reply-to: Your message of "Wed, 22 Apr 1998 00:51:40 MST."
             <9804220051.ZM27172@flatland.engr.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Apr 1998 09:11:53 +1000
From: Brian Corrie <bcorrie@cs.anu.edu.au>
Status: O

Hello Chris,

> Hello Everybody,
> 
> Next week the ITEC conference will be held in Lausanne
> (Switzerland) from April 28-30.

[Stuff deleted]

> We will be discussing several of the new features in Performer
> 2.2, including Clipmapping, ASD and Calligraphics. Other topics
> will include a discussion of the Performer product roadmap and
> Performer's evolution in light of Fahrenheit. There will be time
> to answer any questions you may have.

I, and I am sure many others, would be very interested in hearing about SGI's 
roadmap for Performer, Optimizer, OpenGL, OpenGL++, etc., with respect to 
Fahrenheit. Is it possible that some details could be posted to this list 
(from you or someone else at SGI) as well. We were hoping to see an initial 
release of OpenGL++ in the next couple of months, but according to the OpenGL 
ARB meeting minutes from March 9-10

(http://www.opengl.org/ARB/Notes/Meeting1.2/meeting_note_10-03-98.html)

Kurt Akeley (at least so the minutes say, I wasn't there...) says that "SGI 
will no longer be able to push OpenGL++ (though they have no objection to 
others picking up the work). Resources are committed to work with Microsoft 
and HP on the scene graph and large model visualization APIs." Does this mean 
that we will be waiting for the Fahrenheit scene graph as opposed to OpenGL++?

> To be assured of a seat, please come to the SGI stand on the show
> floor to get a ticket for this meeting - hurry because it's first
> come first serve!

If I was there, I would be asking the above question 8-)  We have been 
developing some software under the assumption that OpenGL++ would be available 
sometime near the middle of this year. This has a fairly significant impact on 
some our plans and I have not been able to find out any information through 
our normal SGI channels.

Thanks in advance for any information you can provide.

	Brian


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 16:53:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA02176 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 16:41:58 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA02149 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 16:41:56 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA15304138
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 16:41:56 -0700 (PDT)
Received: from zippo.paradigmsim.com (zippo.paradigmsim.com [206.7.114.202]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA14685
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 16:41:54 -0700 (PDT)
	mail_from (mew@paradigmsim.com)
Received: from zippo.paradigmsim.com (localhost [127.0.0.1]) by zippo.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA22120; Wed, 22 Apr 1998 18:34:24 -0500
Sender: mew@paradigmsim.com
Message-ID: <353E7E7F.3F54@paradigmsim.com>
Date: Wed, 22 Apr 1998 18:34:23 -0500
From: Mike Weiblen <mew@paradigmsim.com>
Organization: Paradigm Simulation, Inc.
X-Mailer: Mozilla 3.0 (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: Sandeep Mulgund <smulgund@cra.com>
CC: info-performer@sgi.com
Subject: Re: Problem with creating custom icon on minimized window
References: <v03102803b1640a61f80e@[205.181.6.126]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Try "pilotStation.icon", with the first letter in lowercase.

-- mew


Sandeep Mulgund wrote:
> If I use 'xprop' on my running application window, it shows the
> resources set to the correct values.  However, when I minimize the
> window, it shows the default minimized icon, rather than my custom
> icon (which I've placed in the correct directory, with the name
> PilotStation.icon).  What am I doing wrong?  The only way it works 
> is if I put a file called "default.icon" in ~/.icon/.  It seems to
> be ignoring my definition of the WM_CLASS resource.

-- 
Mike Weiblen                  talkto:972-960-2301 x292
PARADIGM Simulation, Inc.     faxto:972-960-9049
14900 Landmark, Suite 400     mailto:mew@paradigmsim.com
Dallas TX 75240               http://www.paradigmsim.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 16:53:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA02101 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 16:35:17 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA02074 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 16:35:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA14505191
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 16:35:08 -0700 (PDT)
Received: from archimedes.vislab.navy.mil (archimedes.chinalake.navy.mil [129.131.31.8]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id QAA12431
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 16:35:07 -0700 (PDT)
	mail_from (jan@archimedes.vislab.navy.mil)
Received: (jan@localhost) by archimedes.vislab.navy.mil (8.7.5/8.x-CL-SOS5.3) id QAA05216; Wed, 22 Apr 1998 16:44:03 -0700 (PDT)
From: Jan Barglowski <jan@archimedes.vislab.navy.mil>
Posted-Date: Wed, 22 Apr 1998 16:44:03 -0700 (PDT)
Message-Id: <199804222344.QAA05216@archimedes.vislab.navy.mil>
Subject: Re: Problem with creating custom icon on minimized window
To: smulgund@cra.com (Sandeep Mulgund)
Date: Wed, 22 Apr 1998 16:44:03 -0700 (PDT)
Cc: info-performer@sgi.com
In-Reply-To: <v03102803b1640a61f80e@[205.181.6.126]> from "Sandeep Mulgund" at Apr 22, 98 05:02:27 pm
X-Mailer: ELM [version 2.4 PL24 ME8b]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

Sandeep Mulgund wrote:
> I'm trying to create a custom icon for the minimized window of a Performer
> application.  Per the Indigo Magic guidlines, I'm using some X functions to
> define the WM_CLASS resource, as follows:
[snip]
> If I use 'xprop' on my running application window, it shows the resources
> set to the correct values.  However, when I minimize the window, it shows
> the default minimized icon, rather than my custom icon (which I've placed
> in the correct directory, with the name PilotStation.icon).  What am I
> doing wrong?  The only way it works is if I put a file called
> "default.icon" in ~/.icon/.  It seems to be ignoring my definition of the
> WM_CLASS resource.

I've done this with several programs.  First, is your "correct directory"
/usr/lib/images?  Next, what is your app name?  I think it must be the
same as your icon, e.g. myApp, myApp.icon

I never did the WM_CLASS code you mentioned.  What I did was to take
the xwsh program, copy it to xwsh_myapp, create an icon 
/usr/lib/images/xwsh_myapp.icon , and then when we invoked the xwsh_myapp
(we use xwsh_myapp -e myapp to run an app in the window shell) and iconize
it, well, it just works.

jan

-- 
Jan Anthony Barglowski	              jan@chinalake.navy.mil
Real-time Computer Graphics           http://www1.ridgecrest.ca.us/~jan
Naval Air Warfare Center, China Lake  (760) 927-1057
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 17:26:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA02497 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 17:14:26 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA02470 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 17:14:25 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA15329208
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 17:14:25 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id RAA25902
	for <info-performer@sgi.com>; Wed, 22 Apr 1998 17:14:24 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA15210601;
	Wed, 22 Apr 1998 17:14:21 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA03275; Wed, 22 Apr 1998 17:14:16 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353E87D8.2A8C364F@sgi.com>
Date: Wed, 22 Apr 1998 17:14:16 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Brian Corrie <bcorrie@cs.anu.edu.au>
CC: Chris Insinger <insinger@flatland.engr.sgi.com>, info-performer@sgi.com,
        bcorrie@silver.anu.edu.au
Subject: Re: Performer at ITEC
References: <199804222311.JAA01102@silver.anu.edu.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Brian Corrie wrote:
> 
> Hello Chris,
> 
> > Hello Everybody,
> >
> > Next week the ITEC conference will be held in Lausanne
> > (Switzerland) from April 28-30.
> 
> [Stuff deleted]
> 
> > We will be discussing several of the new features in Performer
> > 2.2, including Clipmapping, ASD and Calligraphics. Other topics
> > will include a discussion of the Performer product roadmap and
> > Performer's evolution in light of Fahrenheit. There will be time
> > to answer any questions you may have.
> 
> I, and I am sure many others, would be very interested in hearing about SGI's
> roadmap for Performer, Optimizer, OpenGL, OpenGL++, etc., with respect to
> Fahrenheit. Is it possible that some details could be posted to this list
> (from you or someone else at SGI) as well. We were hoping to see an initial
> release of OpenGL++ in the next couple of months, but according to the OpenGL
> ARB meeting minutes from March 9-10
> 
> (http://www.opengl.org/ARB/Notes/Meeting1.2/meeting_note_10-03-98.html)
> 
> Kurt Akeley (at least so the minutes say, I wasn't there...) says that "SGI
> will no longer be able to push OpenGL++ (though they have no objection to
> others picking up the work). Resources are committed to work with Microsoft
> and HP on the scene graph and large model visualization APIs." Does this mean
> that we will be waiting for the Fahrenheit scene graph as opposed to OpenGL++?

Yes, but this isn't really bad news. In many respects the engineering
goals of Fahrenheit Scene Graph are compatible with what OpenGL++ would
have been.

> 
> > To be assured of a seat, please come to the SGI stand on the show
> > floor to get a ticket for this meeting - hurry because it's first
> > come first serve!
> 
> If I was there, I would be asking the above question 8-)  We have been
> developing some software under the assumption that OpenGL++ would be available
> sometime near the middle of this year. This has a fairly significant impact on
> some our plans and I have not been able to find out any information through
> our normal SGI channels.

I won't comment on the time scales but work already undertaken is being
leveraged so this is not a step backwards. Were you hoping to use a beta
test or a release version of OpenGL++ in your original plans?

> 
> Thanks in advance for any information you can provide.
> 

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 22 18:26:08 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA02769 for info-performer-dist@holodeck.engr.sgi.com; Wed, 22 Apr 1998 18:09:42 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA02742 for <info-performer@holodeck.engr.sgi.com>; Wed, 22 Apr 1998 18:09:40 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA15326540
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 22 Apr 1998 18:09:40 -0700 (PDT)
Received: from silver.anu.edu.au (silver.anu.edu.au [150.203.162.26]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id SAA13671; Wed, 22 Apr 1998 18:09:36 -0700 (PDT)
	mail_from (bcorrie@silver.anu.edu.au)
Received: from silver (bcorrie@localhost [127.0.0.1]) by silver.anu.edu.au (8.8.2/8.8.2) with ESMTP id LAA01226; Thu, 23 Apr 1998 11:09:29 +1000 (EST)
Message-Id: <199804230109.LAA01226@silver.anu.edu.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: Angus Dorbie <dorbie@sgi.com>
cc: Brian Corrie <bcorrie@cs.anu.edu.au>,
        Chris Insinger <insinger@flatland.engr.sgi.com>,
        info-performer@sgi.com
Subject: Re: Performer at ITEC 
In-reply-to: Your message of "Wed, 22 Apr 1998 17:14:16 MST."
             <353E87D8.2A8C364F@sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Apr 1998 11:09:26 +1000
From: Brian Corrie <bcorrie@cs.anu.edu.au>
Status: O


I said:
>> I, and I am sure many others,would be very interested in hearing about SGI's
>> roadmap for Performer, Optimizer, OpenGL, OpenGL++, etc., with respect to
>> Fahrenheit. Is it possible that some details could be posted to this list
>> (from you or someone else at SGI) as well. We were hoping to see an initial
>> release of OpenGL++ in the next couple of months, but according to the 
>> OpenGL ARB meeting minutes from March 9-10
>> 
>> (http://www.opengl.org/ARB/Notes/Meeting1.2/meeting_note_10-03-98.html)
>> 
>> Kurt Akeley (at least so the minutes say, I wasn't there...) says that "SGI
>> will no longer be able to push OpenGL++ (though they have no objection to
>> others picking up the work). Resources are committed to work with Microsoft
>> and HP on the scene graph and large model visualization APIs." Does this 
mean
>> that we will be waiting for the Fahrenheit scene graph as opposed to
>> OpenGL++?

Angus replies:
> Yes, but this isn't really bad news. In many respects the engineering
> goals of Fahrenheit Scene Graph are compatible with what OpenGL++ would
> have been.

I agree it isn't bad news from the point of view of having a new, unified 
scene graph API. The confusion comes from what is going to happen and when 
(see below). I haven't seen any mention other than the ARB notes given above 
that SGI was not going to release OpenGL++ as intially intended. Has an 
official statement been made?

>>  We have been
>> developing some software under the assumption that OpenGL+ would be 
available
>> sometime near the middle of this year.This has a fairly significant impact 
on
>> some our plans and I have not been able to find out any information through
>> our normal SGI channels.
> 
> I won't comment on the time scales but work already undertaken is being
> leveraged so this is not a step backwards. Were you hoping to use a beta
> test or a release version of OpenGL++ in your original plans?

The timescales involved are our main concern. We were under the impression 
that an OpenGL++ release, at least a beta version, would be out RSN, and the 
first real release would be around August or so. I realize that one can not 
rely on dates like these, but we were assuming that they would be relatively 
close and we haven't had any indication otherwise (although it is a bit hard 
to keep on top of these things from here). The Fahrenheit time frame moves 
things well into next year which does cause some problems for us. We need to 
get a slightly clearer picture of what is going on in this respect so we can 
decide in what direction to move. The only picture we have at the moment is 
wait until Fahrenheit arrives, with no clear path between now and then. What 
is Fahrenheit going to look like and how can we move towards that API given 
the technology we have now (Performer, Optimizer, Cosmo3D, OpenGL). We thought 
we had a clear picture in this respect, but...

Cheers,

	Brian




=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 04:34:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA03539 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 04:15:39 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA03512 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 04:15:38 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA15059943
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 04:15:38 -0700 (PDT)
Received: from rose.engr.sgi.com ([150.166.37.6]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id EAA19344
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 04:15:37 -0700 (PDT)
	mail_from (src@rose.engr.sgi.com)
Received: (from src@localhost) by rose.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA19472; Thu, 23 Apr 1998 04:15:32 -0700
Date: Thu, 23 Apr 1998 04:15:32 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9804230415.ZM19470@rose.engr.sgi.com>
In-Reply-To: Daniel Williams <dwilliams@sarnoff.com>
        "Octane Channel Option and Performer2.2?" (Apr 22,  5:39pm)
References: <353E6385.2781@sarnoff.com>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Daniel Williams <dwilliams@sarnoff.com>, info-performer@sgi.com
Subject: Re: Octane Channel Option and Performer2.2?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

+>---- On Apr 22,  5:39pm, Daniel Williams wrote:
> Subject: Octane Channel Option and Performer2.2?
->
->Has anyone used the Octane Channel Option with Performer2.2?

Yup - this is a bug in Performer2.2 - we don't end up not
opening a window if there is no channel 0 and OCO doesn't 
have a channel 0.

This is fixed in our first update to Performer2.2 which will be
included in the IRIX 6.5 release.  A larger Performer2.2 patch 
covering 6.2 and forwared is also in progress and planned for
later this year.

I'll get the bug lists on the web pages updated - thanx!
src.


-- 
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src@sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 06:04:29 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA03744 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 05:40:16 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA03717 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 05:40:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA14034226
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 05:40:14 -0700 (PDT)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA05458
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 05:40:12 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from sutcliffe.bgm.link.com (sutcliffe.bgm.link.com [130.210.236.18])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id HAA26906; Thu, 23 Apr 1998 07:39:22 -0500 (CDT)
Date: Thu, 23 Apr 1998 08:39:40 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Brian Corrie <bcorrie@cs.anu.edu.au>
cc: Chris Insinger <insinger@flatland.engr.sgi.com>, info-performer@sgi.com,
        bcorrie@silver.anu.edu.au
Subject: Re: Performer at ITEC 
In-Reply-To: <199804222311.JAA01102@silver.anu.edu.au>
Message-ID: <Pine.SGI.3.96.980423083345.6888B-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Thu, 23 Apr 1998, Brian Corrie wrote:

> We were hoping to see an initial 
> release of OpenGL++ in the next couple of months, but according to the OpenGL 
> ARB meeting minutes from March 9-10
> 
> (http://www.opengl.org/ARB/Notes/Meeting1.2/meeting_note_10-03-98.html)
> 
> Kurt Akeley (at least so the minutes say, I wasn't there...) says that "SGI 
> will no longer be able to push OpenGL++ (though they have no objection to 
> others picking up the work). Resources are committed to work with Microsoft 
> and HP on the scene graph and large model visualization APIs." Does this mean 
> that we will be waiting for the Fahrenheit scene graph as opposed to OpenGL++?

I wonder if anyone would be interested in a cooperative 'freeware' Mesa++ (ie
an OpenGL++ implemented on top of Mesa and provided under the same licensing
conditions)?

Kurt's statement suggests that whatever OpenGL++ materials are out there
should be freely available. Given that, I don't think it would be too
hard to write such a thing.

I have an OpenGL++ spec (probably out of date now) - but I can't do
anything with it since it was provided under NDA.

I have been using Performer (another OpenGL scene graph API) under IRIX,
it would be nice to have a suitably Open scenegraph API to replace it on
Windoze and Linux platforms.

If anyone at SGI is listening and would be prepared to release a non-NDA
OpenGL++ spec, I'm sure that would be interesting to many people on this
list.

Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 08:31:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA04196 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 08:14:44 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA04169 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 08:14:42 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA15095606
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 08:14:41 -0700 (PDT)
Received: from amber.drawcomp.com (www.openworlds.com [204.170.208.100]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id IAA24187
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 08:14:39 -0700 (PDT)
	mail_from (prakash@drawcomp.com)
Received: (from nobody@localhost)
	by amber.drawcomp.com (8.8.5/8.8.5) id LAA27855
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 11:05:18 -0400 (EDT)
X-Authentication-Warning: amber.drawcomp.com: nobody set sender to <prakash@drawcomp.com> using -f
Received: from porter(10.0.0.5) by amber.drawcomp.com via smap (V2.0)
	id xma027850; Thu, 23 Apr 98 11:04:58 -0400
Sender: gpmahesh@drawcomp.com
Message-ID: <353F589A.33DEF0AA@drawcomp.com>
Date: Thu, 23 Apr 1998 11:04:58 -0400
From: Prakash Mahesh <prakash@drawcomp.com>
Organization: DRaW Computing Assoc. Inc., http://www.openworlds.com/employees/prakash
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <199804230109.LAA01226@silver.anu.edu.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

> The timescales involved are our main concern. We were under the impression
> that an OpenGL++ release, at least a beta version, would be out RSN, and the
> first real release would be around August or so. I realize that one can not
> rely on dates like these, but we were assuming that they would be relatively
> close and we haven't had any indication otherwise (although it is a bit hard
> to keep on top of these things from here). The Fahrenheit time frame moves
> things well into next year which does cause some problems for us. We need to
> get a slightly clearer picture of what is going on in this respect so we can
> decide in what direction to move. The only picture we have at the moment is
> wait until Fahrenheit arrives, with no clear path between now and then. What
> is Fahrenheit going to look like and how can we move towards that API given
> the technology we have now (Performer, Optimizer, Cosmo3D, OpenGL). We thought
> we had a clear picture in this respect, but...


I guess this problem (not knowing what direction SGI on the whole is
taking) is widespread among the SGI developers. We use Performer,
Optimizer, plain OpenGL and many other libraries, and we have started
supporting Windows/Solaris recently, but our main focus is still SGI.
But the recent developments at SGI and more importantly the
non-availability of information to developers is making things look
unclear. Yes, I hope someone from SGI would openly make  an (even
unofficial) announcement on what their plans are.

Thanks.
-- 
  Prakash Mahesh                                     
  prakash@drawcomp.com
  	--or--
  prakash@openworlds.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 09:19:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA04388 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 09:04:03 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA04361 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 09:03:58 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA15674616
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 09:03:57 -0700 (PDT)
Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA15432
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 09:03:55 -0700 (PDT)
	mail_from (mayer@poster.cae.ca)
Received: tid LAA09879; Thu, 23 Apr 1998 11:55:08 -0400
Received: from christine.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03)
          id AA08767; Thu, 23 Apr 1998 11:51:36 -0400
Received: from christine.cae.ca by christine.cae.ca via SMTP (950413.SGI.8.6.12/930416.SGI)
	 id LAA14660; Thu, 23 Apr 1998 11:57:04 -0400
Sender: mayer@poster.cae.ca
Message-Id: <353F64CF.41C6@cae.ca>
Date: Thu, 23 Apr 1998 11:57:03 -0400
From: Sylvain Mayer <mayer@poster.cae.ca>
Organization: CAE Electronics Ltd
X-Mailer: Mozilla 3.01SC-SGI (X11; I; IRIX 6.2 IP22)
Mime-Version: 1.0
To: info-vega@paradigmsim.com
Cc: info-performer@sgi.com
Subject: Vega now available on NT
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi,

I've never used vega but will be evaluating it very soon on the PC.

I have some Performer experience and I'd like to know what have been the
implications of porting Vega to WindowsNT??

Did Paradigm managed to replace Performer by an in-house tools?  Did
Vega lost a layer of functionality?

My question is simply: "What have replaced Performer in Vega for
WindowsNT?"

thanks

-- 

Sylvain Mayer, 3D Graphics Developer
Visual Database Tools
CAE Electronics Ltd. (http://www.cae.ca)
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 10:13:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA04636 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 09:52:02 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA04609 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 09:52:01 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA15225920
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 09:52:00 -0700 (PDT)
Received: from yourwebhost.com ([207.25.124.43]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA08565
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 09:51:58 -0700 (PDT)
	mail_from (devrim@infotron-tr.com)
Received: from infotron-tr.com (a5-10-asy47.kad-ro-03.superonline.com [195.33.231.154]) by yourwebhost.com (8.8.4/8.7.1) with ESMTP id JAA02510 for <info-performer@sgi.com>; Thu, 23 Apr 1998 09:51:22 -0700
Sender: net@yourwebhost.com
Message-ID: <353FFE58.6882DB40@infotron-tr.com>
Date: Thu, 23 Apr 1998 19:52:09 -0700
From: Devrim Erdem <devrim@infotron-tr.com>
Organization: info(+)tron
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Vega now available on NT
References: <353F64CF.41C6@cae.ca>
Content-Type: multipart/alternative; boundary="------------6ED112EA5BA5C5F6A1665E94"
Status: O


--------------6ED112EA5BA5C5F6A1665E94
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sylvain Mayer wrote:

> Hi,
>
> I've never used vega but will be evaluating it very soon on the PC.
>
> I have some Performer experience and I'd like to know what have been the
> implications of porting Vega to WindowsNT??
>
> Did Paradigm managed to replace Performer by an in-house tools?  Did
> Vega lost a layer of functionality?

The Vega/include dir has pfXXX.h files. I am not sure that Vega has lost
the layer.

> My question is simply: "What have replaced Performer in Vega for
> WindowsNT?"
>

I think the vgXXX functions make OpenGl class rather than performer calls.
The API is kept the same, so that the vega code is portable.

> thanks
>
> --
>
> Sylvain Mayer, 3D Graphics Developer
> Visual Database Tools
> CAE Electronics Ltd. (http://www.cae.ca)
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com



--
=================================================
M Devrim Erdem
System Integration Engineer - Vis. Sim. Division

devrim@infotron-tr.com http://www.infotron-tr.com
=================================================



--------------6ED112EA5BA5C5F6A1665E94
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
Sylvain Mayer wrote:
<BLOCKQUOTE TYPE=CITE>Hi,

<P>I've never used vega but will be evaluating it very soon on the PC.

<P>I have some Performer experience and I'd like to know what have been
the
<BR>implications of porting Vega to WindowsNT??

<P>Did Paradigm managed to replace Performer by an in-house tools?&nbsp;
Did
<BR>Vega lost a layer of functionality?</BLOCKQUOTE>
The Vega/include dir has pfXXX.h files. I am not sure that Vega has lost
the layer.
<BLOCKQUOTE TYPE=CITE>

<P>My question is simply: "What have replaced Performer in Vega for
<BR>WindowsNT?"
<BR>&nbsp;</BLOCKQUOTE>
I think the vgXXX functions make OpenGl class rather than performer calls.
The API is kept the same, so that the vega code is portable.
<BLOCKQUOTE TYPE=CITE>thanks

<P>--

<P>Sylvain Mayer, 3D Graphics Developer
<BR>Visual Database Tools
<BR>CAE Electronics Ltd. (<A HREF="http://www.cae.ca">http://www.cae.ca</A>)
<BR>=======================================================================
<BR>List Archives, FAQ, FTP:&nbsp; <A HREF="http://www.sgi.com/Technology/Performer/">http://www.sgi.com/Technology/Performer/</A>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Submissions:&nbsp; info-performer@sgi.com
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Admin. requests:&nbsp; info-performer-request@sgi.com</BLOCKQUOTE>
&nbsp;
<PRE>--&nbsp;
=================================================
M Devrim Erdem
System Integration Engineer - Vis. Sim. Division

devrim@infotron-tr.com <A HREF="http://www.infotron-tr.com">http://www.infotron-tr.com</A>
=================================================</PRE>
&nbsp;</HTML>

--------------6ED112EA5BA5C5F6A1665E94--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 10:52:09 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA04779 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 10:33:33 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA04752 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 10:33:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA15602941
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 10:33:31 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA28171
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 10:33:30 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA14962918;
	Thu, 23 Apr 1998 10:33:29 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA04012; Thu, 23 Apr 1998 10:33:29 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353F7B69.C3003D94@sgi.com>
Date: Thu, 23 Apr 1998 10:33:29 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Prakash Mahesh <prakash@DRAWCOMP.COM>
CC: info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <199804230109.LAA01226@silver.anu.edu.au> <353F589A.33DEF0AA@drawcomp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Prakash Mahesh wrote:
> 
> > The timescales involved are our main concern. We were under the impression
> > that an OpenGL++ release, at least a beta version, would be out RSN, and the
> > first real release would be around August or so. I realize that one can not
> > rely on dates like these, but we were assuming that they would be relatively
> > close and we haven't had any indication otherwise (although it is a bit hard
> > to keep on top of these things from here). The Fahrenheit time frame moves
> > things well into next year which does cause some problems for us. We need to
> > get a slightly clearer picture of what is going on in this respect so we can
> > decide in what direction to move. The only picture we have at the moment is
> > wait until Fahrenheit arrives, with no clear path between now and then. What
> > is Fahrenheit going to look like and how can we move towards that API given
> > the technology we have now (Performer, Optimizer, Cosmo3D, OpenGL). We thought
> > we had a clear picture in this respect, but...
> 
> I guess this problem (not knowing what direction SGI on the whole is
> taking) is widespread among the SGI developers. We use Performer,
> Optimizer, plain OpenGL and many other libraries, and we have started
> supporting Windows/Solaris recently, but our main focus is still SGI.
> But the recent developments at SGI and more importantly the
> non-availability of information to developers is making things look
> unclear. Yes, I hope someone from SGI would openly make  an (even
> unofficial) announcement on what their plans are.

There will be no unofficial announcements. (that's unofficial ofcourse
:-))

There is official information on dates though. I'll quote from the FAQ:

> When and how will Fahrenheit technologies be delivered? 
>                   The Fahrenheit project technologies will be delivered through the DirectX Architecture
>                   on the Windows Platform. The Fahrenheit Scene Graph and Large Model Visualization
>                   will be delivered by Silicon Graphics on IRIX. 
> 
>                   The deliverables of the technical collaboration are expected to be released individually
>                   in various intervals: 
> 
>                       New low-level API: Expected in 2000 
>                       New scene graph API: First half of 1999 
>                       Fahrenheit LMV APIs: First half of 1999 


Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 11:06:16 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA04898 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 10:46:34 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA04871 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 10:46:33 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA14686129
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 10:46:33 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA04651
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 10:46:32 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA5685783;
	Thu, 23 Apr 1998 10:46:31 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA04059; Thu, 23 Apr 1998 10:46:31 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353F7E77.8A15D532@sgi.com>
Date: Thu, 23 Apr 1998 10:46:31 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Brian Corrie <bcorrie@cs.anu.edu.au>
CC: Chris Insinger <insinger@flatland.engr.sgi.com>, info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <199804230109.LAA01226@silver.anu.edu.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Brian Corrie wrote:
> 
> I said:
> >> I, and I am sure many others,would be very interested in hearing about SGI's
> >> roadmap for Performer, Optimizer, OpenGL, OpenGL++, etc., with respect to
> >> Fahrenheit. Is it possible that some details could be posted to this list
> >> (from you or someone else at SGI) as well. We were hoping to see an initial
> >> release of OpenGL++ in the next couple of months, but according to the
> >> OpenGL ARB meeting minutes from March 9-10
> >>
> >> (http://www.opengl.org/ARB/Notes/Meeting1.2/meeting_note_10-03-98.html)
> >>
> >> Kurt Akeley (at least so the minutes say, I wasn't there...) says that "SGI
> >> will no longer be able to push OpenGL++ (though they have no objection to
> >> others picking up the work). Resources are committed to work with Microsoft
> >> and HP on the scene graph and large model visualization APIs." Does this
> mean
> >> that we will be waiting for the Fahrenheit scene graph as opposed to
> >> OpenGL++?
> 
> Angus replies:
> > Yes, but this isn't really bad news. In many respects the engineering
> > goals of Fahrenheit Scene Graph are compatible with what OpenGL++ would
> > have been.
> 
> I agree it isn't bad news from the point of view of having a new, unified
> scene graph API. The confusion comes from what is going to happen and when
> (see below). I haven't seen any mention other than the ARB notes given above
> that SGI was not going to release OpenGL++ as intially intended. Has an
> official statement been made?
> 
> >>  We have been
> >> developing some software under the assumption that OpenGL+ would be
> available
> >> sometime near the middle of this year.This has a fairly significant impact
> on
> >> some our plans and I have not been able to find out any information through
> >> our normal SGI channels.
> >
> > I won't comment on the time scales but work already undertaken is being
> > leveraged so this is not a step backwards. Were you hoping to use a beta
> > test or a release version of OpenGL++ in your original plans?
> 
> The timescales involved are our main concern. We were under the impression
> that an OpenGL++ release, at least a beta version, would be out RSN, and the
> first real release would be around August or so. I realize that one can not
> rely on dates like these, but we were assuming that they would be relatively
> close and we haven't had any indication otherwise (although it is a bit hard
> to keep on top of these things from here). The Fahrenheit time frame moves
> things well into next year which does cause some problems for us.

But even with OpenGL++ you'd have had to rely on beta software releases
until
then if they were made available to you.

> We need to
> get a slightly clearer picture of what is going on in this respect so we can
> decide in what direction to move. The only picture we have at the moment is
> wait until Fahrenheit arrives, with no clear path between now and then. What
> is Fahrenheit going to look like and how can we move towards that API given
> the technology we have now (Performer, Optimizer, Cosmo3D, OpenGL). We thought
> we had a clear picture in this respect, but...

The path is clear, only Cosmo3D  under OpenGL optimizer is available for
cross platform scene graph development between  now and then but the
whole objective is to get something in place which will have some
longevity and a lot of engineering merit. By definition the
functionality
required doesn't exist prior to the creation of the new API. Just
because
there isn't going to be something in place as soon as was desired
(by everyone concerned) doesn't mean the path forward is not clear.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 17:32:30 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA05780 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 17:17:24 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA05753 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 17:17:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA15466376
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 17:17:18 -0700 (PDT)
Received: from camus.paradigmsim.com (camus.paradigmsim.com [206.7.114.160]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id RAA21192
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 17:17:16 -0700 (PDT)
	mail_from (rweyrauch@paradigmsim.com)
Received: from paradigmsim.com (camus.paradigmsim.com [206.7.114.160]) by camus.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01781; Thu, 23 Apr 1998 19:09:27 -0500
Sender: rweyrauch@paradigmsim.com
Message-ID: <353FD836.9DE1BABF@paradigmsim.com>
Date: Thu, 23 Apr 1998 19:09:26 -0500
From: Rick Weyrauch <rweyrauch@paradigmsim.com>
Reply-To: rweyrauch@paradigmsim.com
Organization: Paradigm Simulation Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: Steve Baker <sbaker@link.com>, info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <Pine.SGI.3.96.980423083345.6888B-100000@sutcliffe.bgm.link.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

I am also interested in developing an open 'freeware' scene graph
toolkit for OpenGL.  The graphics community (both on Linux and Win32)
could use such a tool.

With the advent of Fahrenheit, it there a problem with SGI releasing the
OpenGL++ spec to the public?

Rick


Steve Baker wrote:
> 
> On Thu, 23 Apr 1998, Brian Corrie wrote:
> 
> > We were hoping to see an initial
> > release of OpenGL++ in the next couple of months, but according to the OpenGL
> > ARB meeting minutes from March 9-10
> >
> > (http://www.opengl.org/ARB/Notes/Meeting1.2/meeting_note_10-03-98.html)
> >
> > Kurt Akeley (at least so the minutes say, I wasn't there...) says that "SGI
> > will no longer be able to push OpenGL++ (though they have no objection to
> > others picking up the work). Resources are committed to work with Microsoft
> > and HP on the scene graph and large model visualization APIs." Does this mean
> > that we will be waiting for the Fahrenheit scene graph as opposed to OpenGL++?
> 
> I wonder if anyone would be interested in a cooperative 'freeware' Mesa++ (ie
> an OpenGL++ implemented on top of Mesa and provided under the same licensing
> conditions)?
> 
> Kurt's statement suggests that whatever OpenGL++ materials are out there
> should be freely available. Given that, I don't think it would be too
> hard to write such a thing.
> 
> I have an OpenGL++ spec (probably out of date now) - but I can't do
> anything with it since it was provided under NDA.
> 
> I have been using Performer (another OpenGL scene graph API) under IRIX,
> it would be nice to have a suitably Open scenegraph API to replace it on
> Windoze and Linux platforms.
> 
> If anyone at SGI is listening and would be prepared to release a non-NDA
> OpenGL++ spec, I'm sure that would be interesting to many people on this
> list.
> 
> Steve Baker                (817)619-8776 (Vox/Vox-Mail)
> Raytheon Systems Inc.      (817)619-4028 (Fax)
> Work: SBaker@link.com      http://www.hti.com
> Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
> 
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com

-- 

Rick Weyrauch				voice: (972) 960-2301
Paradigm Simulation Inc.		fax:   (972) 960-2303
14900 Landmark Blvd., Suite 400		rweyrauch@paradigmsim.com
Dallas TX 75240				www.paradigmsim.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 17:59:46 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA05859 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 17:44:05 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA05833 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 17:44:04 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA15810347
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 17:44:03 -0700 (PDT)
Received: from bnl.gov (bnl.gov [130.199.128.163]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id RAA29415
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 17:44:02 -0700 (PDT)
	mail_from (ballard@sirius.ccd.bnl.gov)
Received: from sirius.ccd.bnl.gov (sirius.ccd.bnl.gov [130.199.130.167])
	by bnl.gov (8.8.8/8.8.8) with SMTP id UAA03537
	for <@bnl.gov:info-performer@sgi.com>; Thu, 23 Apr 1998 20:44:01 -0400 (EDT)
Received: by sirius.ccd.bnl.gov (950215.SGI.8.6.10/940406.SGI.AUTO)
	for info-performer@sgi.com id UAA00808; Thu, 23 Apr 1998 20:35:54 -0400
Date: Thu, 23 Apr 1998 20:35:54 -0400
From: ballard@sirius.ccd.bnl.gov (A. Ballard Andrews)
Message-Id: <199804240035.UAA00808@sirius.ccd.bnl.gov>
Apparently-To: info-performer@sgi.com
Status: O

Hi there,

I have an app which works fine in 32 and N32 but when I 
compile it in N64 (no errors) I get a core dump:

 3124:stereo_test_3: rld: Error: elfmap: not an ELF file.
main(): data soft max: 4294967295 
main(): data hard max: 4294967295 
main(): vmem soft max: 4294967295 
main(): vmem hard max: 4294967295 
main(): maximum memory 251592703 
SharedArenaSize = 4294967295
Segmentation fault (core dumped)

Oddly enough, the application runs if I load
files in pfb format but files in e.g., .iv
format cause  core dump.

Is this weird or what?

Ballard Andrews

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 19:18:18 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA06225 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 18:59:53 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA06198 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 18:59:52 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA15710346
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 18:59:52 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id SAA21706
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 18:59:51 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA15853990;
	Thu, 23 Apr 1998 18:59:50 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA04880; Thu, 23 Apr 1998 18:59:43 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <353FF20F.8C61FE15@sgi.com>
Date: Thu, 23 Apr 1998 18:59:43 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: rweyrauch@paradigmsim.com
CC: Steve Baker <sbaker@link.com>, info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <Pine.SGI.3.96.980423083345.6888B-100000@sutcliffe.bgm.link.com> <353FD836.9DE1BABF@paradigmsim.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Rick Weyrauch wrote:
> 
> I am also interested in developing an open 'freeware' scene graph
> toolkit for OpenGL.  The graphics community (both on Linux and Win32)
> could use such a tool.
> 
> With the advent of Fahrenheit, it there a problem with SGI releasing the
> OpenGL++ spec to the public?

The point would seem to be that until the ARB does something about it,
even assuming that there is sufficient interest there (which may be
doubtful in light of the members and either their association with
PC platforms (Intergraph) or the Fahrenheit agreement (HP, SGI,
Microsoft) or their own proprietary scene graph approaches (SUN)),
then there really isn't an OpenGL++ and therefore no spec to follow.

Anyone seeking to write such an API may be wise to follow their own
direction, it may even produce something novel. The commercial
offerings currently out there seem either very poor or very
expensive.

This is just my opinion offered for the sake of friendly discourse, it
in now way represents SGI's position either official or unofficial.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 20:30:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id UAA06445 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 20:06:49 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id UAA06418 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 20:06:48 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id UAA15609987
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 20:06:47 -0700 (PDT)
Received: from silver.anu.edu.au (silver.anu.edu.au [150.203.162.26]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id UAA08214; Thu, 23 Apr 1998 20:06:40 -0700 (PDT)
	mail_from (bcorrie@silver.anu.edu.au)
Received: from silver (bcorrie@localhost [127.0.0.1]) by silver.anu.edu.au (8.8.2/8.8.2) with ESMTP id NAA02634; Fri, 24 Apr 1998 13:06:32 +1000 (EST)
Message-Id: <199804240306.NAA02634@silver.anu.edu.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: Angus Dorbie <dorbie@sgi.com>
cc: info-performer@sgi.com
Subject: Re: Performer at ITEC 
In-reply-to: Your message of "Thu, 23 Apr 1998 18:59:43 MST."
             <353FF20F.8C61FE15@sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Apr 1998 13:06:31 +1000
From: Brian Corrie <bcorrie@cs.anu.edu.au>
Status: O

> Rick Weyrauch wrote:
> > 
> > I am also interested in developing an open 'freeware' scene graph
> > toolkit for OpenGL.  The graphics community (both on Linux and Win32)
> > could use such a tool.
> > 
> > With the advent of Fahrenheit, it there a problem with SGI releasing the
> > OpenGL++ spec to the public?
> 
> The point would seem to be that until the ARB does something about it,
> even assuming that there is sufficient interest there (which may be
> doubtful in light of the members and either their association with
> PC platforms (Intergraph) or the Fahrenheit agreement (HP, SGI,
> Microsoft) or their own proprietary scene graph approaches (SUN)),
> then there really isn't an OpenGL++ and therefore no spec to follow.
>
> Anyone seeking to write such an API may be wise to follow their own
> direction, it may even produce something novel. The commercial
> offerings currently out there seem either very poor or very
> expensive.

But, as you say, most of the technology in OpenGL++ will be leveraged for 
Fahrenheit (man, every time I type that I type it wrong... couldn't they have 
picked a name that was easier to type 8-). I would assume that much of the 
OpenGL++ Scene Graph architecture will carry through to Fahrenheit. I think 
the goal of a Mesa++ should be to implement the Fahrenheit API much as Mesa 
implements the OpenGL API. Thus the OpenGL++ spec would be an excellent 
starting point for such an effort. One does already exist, up to a point, so 
it would be nice if SGI and/or the ARB could release it into the public domain.

Cheers,

	Brian


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 23 23:11:46 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id WAA06748 for info-performer-dist@holodeck.engr.sgi.com; Thu, 23 Apr 1998 22:48:00 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id WAA06721 for <info-performer@holodeck.engr.sgi.com>; Thu, 23 Apr 1998 22:48:00 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id WAA15881037
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 23 Apr 1998 22:47:59 -0700 (PDT)
Received: from rose.engr.sgi.com ([150.166.37.6]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id WAA10183
	for <info-performer@sgi.com>; Thu, 23 Apr 1998 22:47:58 -0700 (PDT)
	mail_from (src@rose.engr.sgi.com)
Received: (from src@localhost) by rose.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id WAA22392; Thu, 23 Apr 1998 22:47:58 -0700
Date: Thu, 23 Apr 1998 22:47:58 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <199804240547.WAA22392@rose.engr.sgi.com>
To: info-performer@sgi.com
Subject: OpenGL++ -> Fahrenheit (was Performer at ITEC)
Status: O


Hi all,

I'm glad this has come up and that folks are asking the
these specific questions so we get a chance to answer them in a 
targeted fashion. I'll try to address some of the questions raised
in the recent postings (some of this is just redundant and seconding
what Angus has already said). 

+>---- On Apr 23,  9:11am, Brian Corrie wrote:
> Subject: Re: Performer at ITEC
->
->
->I, and I am sure many others, would be very interested in hearing about SGI's 
->roadmap for Performer, Optimizer, OpenGL, OpenGL++, etc., with respect to 
->Fahrenheit. Is it possible that some details could be posted to this list 
->(from you or someone else at SGI) as well. We were hoping to see an initial 
->release of OpenGL++ in the next couple of months, but according to the OpenGL 

We have the high level in every presentation slide set we give.
A bit of this in our I/ITSEC 97  slides (on the web site).

http://www.sgi.com/Technology/Performer/technical.html

OpenGL is still going strong and 1.2 was just released!  In brief,
the SGI OpenGL++ effort has now transitioned into Fahrenheit Scene
Graph (FSG). FSG will run on OpenGL, D3D, and Fahrenheit Low
Level(FLL) when that exists. FSG will be cross-platform and will be
shipped with at least Windows and IRIX.

The next major version of Performer (3.0) will use Fahreneit Scene
Graph.  Since the pfSceneGraph and basic MP model will largely
transition into FSG, we have a chance to re-evaluate what
Performer3.0 should exactly be and how it can best serve our Visual
Simulation customers.  Future vertical market toolkits from SGI will
all be based on FSG so that they use the same Scene Graph and MP
model.  But, the rest of that is for Chris's talk at ITEC and we'll
put his slides on the web site after the show.

->ARB meeting minutes from March 9-10
->
->(http://www.opengl.org/ARB/Notes/Meeting1.2/meeting_note_10-03-98.html)
->
->Kurt Akeley (at least so the minutes say, I wasn't there...) says that "SGI 
->will no longer be able to push OpenGL++ (though they have no objection to 
->others picking up the work). Resources are committed to work with Microsoft 
->and HP on the scene graph and large model visualization APIs." Does this mean 
->that we will be waiting for the Fahrenheit scene graph as opposed to OpenGL++?

As Angus indicated, yes.  The SGI and Microsoft parts of the OpenGL++
effort have transitioned into FSG and FSG is derrived directly from
the spec and source code base that we had for OGL++.  Some solid
improvements have been made that will produce much better
extensibility on NT platforms but that is for another discussion.  In
general, we have made a lot of progress on the entire thing since
last Dec.

->
->If I was there, I would be asking the above question 8-)  We have been 
->developing some software under the assumption that OpenGL++ would be available 
->sometime near the middle of this year. This has a fairly significant impact on 
->some our plans and I have not been able to find out any information through 
->our normal SGI channels.

The most detailed we ever got was in summer '97 hoping for a Beta in
summer '98. As we mentioned then, that was a very tentative outlook
because we were (and are) talking about a 1.0 type of release here.
The schedule at this point probably is not all that different than it
otherwise would have been.  As announced at the Fahrenheit launch, we
are trying for a released product mid-98.  We'll do a beta before
that, and limited alpha exposure before that.  I'd say the move to
Fahrenheit made us slip a bit but not significantly and the
additional changes that have been incurred feel good.  We are able to
be a lot more directed and focused now so that might also make up for
a little of the lost time :-)

I'd be interested to hear more privately about how your plans are
affected so I can be better informed about how these changes are
impacting people.  Naively, I'd assume your plans had to allow some
flexibility around OGL++ and hopefully we haven't disrupted the
waters too much by doing this with Fahrenheit. While I can't go into
all of the details at this stage, I can definitely say that our
general direction and goals have not changed.


+>---- On Apr 23,  8:39am, Steve Baker wrote:
> Subject: Re: Performer at ITEC
->
->I wonder if anyone would be interested in a cooperative 'freeware' Mesa++ (ie

->
->I have an OpenGL++ spec (probably out of date now) - but I can't do
->anything with it since it was provided under NDA.

Yes, it was.

->I have been using Performer (another OpenGL scene graph API) under IRIX,
->it would be nice to have a suitably Open scenegraph API to replace it on
->Windoze and Linux platforms.

If the trouble is the fear that needed OS platforms aren't supported,
or that certain features aren't available in the OSs that we are 
covering then SGI and Microsoft would like to hear about that and
why they are needed.  

If what you really have is detailed questions on licensing for other 
OS platforms, then it might be better to pose those to Microsoft or at 
least a forum where they are listening.

->If anyone at SGI is listening and would be prepared to release a non-NDA
->OpenGL++ spec, I'm sure that would be interesting to many people on this
->list.

In truth, I don't think that last Dec. spec would provide much
insight for folks that have seen Performer and Inventor beyond
reassuring folks that we are still doing a Scene Graph.  Since the
goal here is a pervasive standard, I'd hope that folks would use
Fahrenheit and not try to start up a separate effort now on something
old.  SGI will only participate in one effort and honestly believe
what we have created with Fahrenheit is the right thing, both for ISV
and IHVs that want to be able to differentiate on top of and
underneath a ubiquitous API.  I don't think multiple efforts is going
to help anyone at this point.

If what you want is programming hints for future directions, then be
assured that 1) we are trying to both forumulate and limit the
complexity of the transition path from our current products and 2)
will advertise a set of hints when relevant.  It is really probably a
bit premature at this point and I don't think that superficial
"change pfLOD to xxLOD" type hints are really what you are looking for.

+>---- On Apr 23, 11:04am, Prakash Mahesh wrote: 
->> Subject: Re: Performer at ITEC
->
->I guess this problem (not knowing what direction SGI on the whole is
->taking) is widespread among the SGI developers. We use Performer,
->Optimizer, plain OpenGL and many other libraries, and we have started
->supporting Windows/Solaris recently, but our main focus is still SGI.
->But the recent developments at SGI and more importantly the
->non-availability of information to developers is making things look
->unclear. Yes, I hope someone from SGI would openly make  an (even
->unofficial) announcement on what their plans are.

I really need a more specific question here to know what you are
really asking.  Our general direction has never changed, we have just
been looking for a way to get a set of APIs to be pervasive in the
industry and have them be APIs that are carefully constructed to
allow us (and other hardware vendors) to differentiate within the
same API.  It will also help ISVs because then the burden of
customizing SW to run well on different platforms can be in large
part carried by the hardware vendors.  This is what we have done with
OpenGL at the low level and at the scene graph level (for the SGI
product line) with Performer.  This is what we (and others) will do
with Fahrenheit for a cross-plaform solution.


A couple of additional notes:

For more some current big picture or lengthy
essays, I'll point to some handy sites you might peruse:

General SGI Fahrenheit site: http://www.sgi.com/fahrenheit/

A recent good article from a talk by Kurt and Jay: 
    http://www.gamasutra.com/features/programming/19980410/fahrenheit_01.htm

I think this should address the basic questions that have come up.
We will give out more detailed technical information at a later stage
as it becomes appropriate.

I hope this helps and thanx for asking!
src & chris.


-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src@sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 24 05:42:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA07369 for info-performer-dist@holodeck.engr.sgi.com; Fri, 24 Apr 1998 05:23:38 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA07342 for <info-performer@holodeck.engr.sgi.com>; Fri, 24 Apr 1998 05:23:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA15792658
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 24 Apr 1998 05:23:31 -0700 (PDT)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA26524
	for <info-performer@sgi.com>; Fri, 24 Apr 1998 05:23:30 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id HAA15741; Fri, 24 Apr 1998 07:23:27 -0500 (CDT)
Date: Fri, 24 Apr 1998 07:23:39 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Rick Weyrauch <rweyrauch@paradigmsim.com>
cc: info-performer@sgi.com
Subject: Re: Performer at ITEC
In-Reply-To: <353FD836.9DE1BABF@paradigmsim.com>
Message-ID: <Pine.SGI.3.96.980424072047.5113D-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Thu, 23 Apr 1998, Rick Weyrauch wrote:

> I am also interested in developing an open 'freeware' scene graph
> toolkit for OpenGL.  The graphics community (both on Linux and Win32)
> could use such a tool.
> 
> With the advent of Fahrenheit, it there a problem with SGI releasing the
> OpenGL++ spec to the public?
 
Kurt Akeley said:

  "SGI will no longer be able to push OpenGL++ (though they have no objection to
  others picking up the work)."

Also, the OpenGL++ spec presumably belongs to the OpenGL ARB and not to SGI,
so I presume we'd have to talk to the ARB to get a copy of it.

I have a copy of the spec - but it's under NDA from SGI - so I can't use that
as the basis of a 'Mesa++' effort. Following Kurt's announcement, there should
be no problem getting hold of the current spec without NDA - I presume.

Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 24 10:49:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA08086 for info-performer-dist@holodeck.engr.sgi.com; Fri, 24 Apr 1998 10:32:54 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA08059 for <info-performer@holodeck.engr.sgi.com>; Fri, 24 Apr 1998 10:32:53 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA16028004
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 24 Apr 1998 10:32:53 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA28332
	for <info-performer@sgi.com>; Fri, 24 Apr 1998 10:32:52 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA16039860;
	Fri, 24 Apr 1998 10:32:51 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA05749; Fri, 24 Apr 1998 10:32:49 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3540CCC1.A791E07@sgi.com>
Date: Fri, 24 Apr 1998 10:32:49 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Steve Baker <sbaker@link.com>
CC: Rick Weyrauch <rweyrauch@paradigmsim.com>, info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <Pine.SGI.3.96.980424072047.5113D-100000@lechter.bgm.link.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Steve Baker wrote:
> 
> On Thu, 23 Apr 1998, Rick Weyrauch wrote:
> 
> > I am also interested in developing an open 'freeware' scene graph
> > toolkit for OpenGL.  The graphics community (both on Linux and Win32)
> > could use such a tool.
> >
> > With the advent of Fahrenheit, it there a problem with SGI releasing the
> > OpenGL++ spec to the public?
> 
> Kurt Akeley said:
> 
>   "SGI will no longer be able to push OpenGL++ (though they have no objection to
>   others picking up the work)."
> 
> Also, the OpenGL++ spec presumably belongs to the OpenGL ARB and not to SGI,
> so I presume we'd have to talk to the ARB to get a copy of it.

This in no way indicates SGI official policy but I don't see how you can
say
this. Just because a document is presented to a comittee for review,
doesn't
convey all the rights to it's contents, particularly the ownership of
any IP
described in it, but I'm no lawyer and don't know all that was said or
exchanged w.r.t. the spec.

> 
> I have a copy of the spec - but it's under NDA from SGI - so I can't use that
> as the basis of a 'Mesa++' effort. Following Kurt's announcement, there should
> be no problem getting hold of the current spec without NDA - I presume.

There's a big difference between running with an OpenGL scene graph idea
and
using the NDA spec lock, stock and barrel. None of this is is SGI
policy, but even
if the OpenGL++ spec were left to the ARB, it may very well be the case
that
nobody on the ARB is interested in OpenGL++ anymore. As I have already
pointed
out most ARB members now have a significant stake in Fahrenheit or their
own
Scene Graph strategies like Java 3D, and Raytheon isn't on the ARB :-(.

Why would you want or need to base Mesa++ on OpenGL++ if the rest of the
world
is using FSG and there is no _real OpenGL++.

I want to make it absolutely clear that these are just a personal
observations
of the issues raised by Steve and don't reflect SGIs views in any way.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 24 11:31:01 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA08285 for info-performer-dist@holodeck.engr.sgi.com; Fri, 24 Apr 1998 11:13:11 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA08258 for <info-performer@holodeck.engr.sgi.com>; Fri, 24 Apr 1998 11:13:09 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA16113465
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 24 Apr 1998 11:13:09 -0700 (PDT)
Received: from vino.paradigmsim.com (vino.paradigmsim.com [206.7.114.136]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA17636
	for <info-performer@sgi.com>; Fri, 24 Apr 1998 11:13:06 -0700 (PDT)
	mail_from (chris@paradigmsim.com)
Received: from bedlam (bedlam.paradigmsim.com [206.7.114.33]) by vino.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA13154; Fri, 24 Apr 1998 13:04:36 -0500
From: "Chris Mumford" <chris@paradigmsim.com>
To: <mayer@poster.cae.ca>, <info-vega@paradigmsim.com>
Cc: <info-performer@sgi.com>
Subject: RE: Vega now available on NT
Date: Fri, 24 Apr 1998 13:14:56 -0500
Message-ID: <001001bd6fac$e30a6810$217207ce@bedlam.paradigmsim.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-reply-to: <353F64CF.41C6@cae.ca>
Status: O

> Hi,
>
> I've never used vega but will be evaluating it very soon on the PC.
>
> I have some Performer experience and I'd like to know what have been the
> implications of porting Vega to WindowsNT??
>
> Did Paradigm managed to replace Performer by an in-house tools?  Did
> Vega lost a layer of functionality?
>
> My question is simply: "What have replaced Performer in Vega for
> WindowsNT?"
>
> thanks
>

Due to the absence of a robust Performer-like API for Windows NT, Paradigm
has written its own scene graph called the Vega Scene Graph. We have
implemented a subset of the Performer(tm) API as wrapper functions around
the Vega Scene Graph. This was done to ease the burden of porting existing
Vega applications from the IRIX platform to Windows NT. This API is not for
porting existing Performer applications to Windows NT. There are many
Performer  wrappers  that we have not implemented, and do not intend to
implement.

If you are looking for cross-platform compatibility for your existing
Performer application, Paradigm is prepared to assist you with a port to
Vega. Once the application is Vega-based, compatibility will exist between
IRIX and NT platforms, with minimal code changes. If you are interested in
this approach, please contact your local Paradigm salesperson, or send us an
email at marketing@paradigmsim.com.

Thank you,

Chris Mumford
VegaNT Product Manager

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 24 13:11:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA08981 for info-performer-dist@holodeck.engr.sgi.com; Fri, 24 Apr 1998 13:00:41 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA08954 for <info-performer@holodeck.engr.sgi.com>; Fri, 24 Apr 1998 13:00:39 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA16104535
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 24 Apr 1998 13:00:38 -0700 (PDT)
Received: from mclean2-mail.usae.bah.com (mclean2-mail.usae.bah.com [156.80.5.110]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id NAA01196
	for <info-performer@sgi.com>; Fri, 24 Apr 1998 13:00:37 -0700 (PDT)
	mail_from (castillo_joe@bah.com)
Received: from bah.com ([156.80.123.172]) by mclean2-mail.usae.bah.com
          (Netscape Messaging Server 3.01)  with ESMTP id AAA27777
          for <info-performer@sgi.com>; Fri, 24 Apr 1998 15:59:09 -0400
Message-ID: <3540EF81.8E9CC6B8@bah.com>
Date: Fri, 24 Apr 1998 16:01:05 -0400
From: "Castillo Joe" <castillo_joe@bah.com>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: "info-performer@sgi.com" <info-performer@sgi.com>
Subject: mktiles
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Dear commrades,

Does anyone have the utility "mktiles" for making cliptextures?? I
aquired it through

an FAQ a while ago and I've misplaced the executable.  If available
please repost.

thank you.

Joe



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 24 14:35:20 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA09461 for info-performer-dist@holodeck.engr.sgi.com; Fri, 24 Apr 1998 14:19:15 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA09434 for <info-performer@holodeck.engr.sgi.com>; Fri, 24 Apr 1998 14:19:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA13956019
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 24 Apr 1998 14:19:14 -0700 (PDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA08744
	for <info-performer@sgi.com>; Fri, 24 Apr 1998 14:19:13 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from multipass.engr.sgi.com (multipass.engr.sgi.com [198.29.106.105])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA15978305;
	Fri, 24 Apr 1998 14:19:12 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA06007; Fri, 24 Apr 1998 14:19:11 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <354101CF.C498734D@sgi.com>
Date: Fri, 24 Apr 1998 14:19:11 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5-BETA-1274425944 IP22)
MIME-Version: 1.0
To: Chris Mumford <chris@paradigmsim.com>
CC: mayer@poster.cae.ca, info-vega@paradigmsim.com, info-performer@sgi.com
Subject: Re: Vega now available on NT
References: <001001bd6fac$e30a6810$217207ce@bedlam.paradigmsim.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Chris Mumford wrote:
> 
> > Hi,
> >
> > I've never used vega but will be evaluating it very soon on the PC.
> >
> > I have some Performer experience and I'd like to know what have been the
> > implications of porting Vega to WindowsNT??
> >
> > Did Paradigm managed to replace Performer by an in-house tools?  Did
> > Vega lost a layer of functionality?
> >
> > My question is simply: "What have replaced Performer in Vega for
> > WindowsNT?"
> >
> > thanks
> >
> 
> Due to the absence of a robust Performer-like API for Windows NT, Paradigm
> has written its own scene graph called the Vega Scene Graph. We have
> implemented a subset of the Performer(tm) API as wrapper functions around
> the Vega Scene Graph. This was done to ease the burden of porting existing
> Vega applications from the IRIX platform to Windows NT. This API is not for
> porting existing Performer applications to Windows NT. There are many
> Performer  wrappers  that we have not implemented, and do not intend to
> implement.
> 
> If you are looking for cross-platform compatibility for your existing
> Performer application, Paradigm is prepared to assist you with a port to
> Vega. Once the application is Vega-based, compatibility will exist between
> IRIX and NT platforms, with minimal code changes. If you are interested in
> this approach, please contact your local Paradigm salesperson, or send us an
> email at marketing@paradigmsim.com.
> 
> Thank you,

The important thing interested parties on the info-performer
list need to know now is the per seat cost of Vega runtime and
development licenses, with and without various plugins?

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 24 16:16:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA09835 for info-performer-dist@holodeck.engr.sgi.com; Fri, 24 Apr 1998 15:59:57 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA09808 for <info-performer@holodeck.engr.sgi.com>; Fri, 24 Apr 1998 15:59:57 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA16286017
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 24 Apr 1998 15:59:56 -0700 (PDT)
Received: from portalcp.chevron.com (portalcp.chevron.com [207.24.17.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA14925
	for <info-performer@sgi.com>; Fri, 24 Apr 1998 15:59:55 -0700 (PDT)
	mail_from (WRVO@chevron.com)
Received: (from uucp@localhost)
	by portalcp.chevron.com (8.8.8/8.8.8) id PAA10219
	for <info-performer@sgi.com>; Fri, 24 Apr 1998 15:59:55 -0700 (PDT)
Received: from unknown(146.27.64.35) by portalcp.chevron.com via smap (4.0a)
	id xma010054; Fri, 24 Apr 98 15:59:32 -0700
Message-Id: <199804242259.PAA07934@cybil.sr.chevron.com>
Received: by chvpk-msx04-b.sr.chevron.com with Internet Mail Service (5.0.1460.8)
	id <JSRRM5XX>; Fri, 24 Apr 1998 15:59:29 -0700
From: "Volz, Bill (wrvo)" <WRVO@chevron.com>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Books on Performer
Date: Fri, 24 Apr 1998 15:59:23 -0700
X-Mailer: Internet Mail Service (5.0.1460.8)
Status: O

The Performer Programmer's guide that SGI provides with the course is pretty
weak on content on actual programming details. Is there a book written by
someone in the know that someone would like to recommend? Like the little
red book for OpenGL.

Thanks,

Bill Volz

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Fri Apr 24 16:16:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA09806 for info-performer-dist@holodeck.engr.sgi.com; Fri, 24 Apr 1998 15:57:54 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA09779 for <info-performer@holodeck.engr.sgi.com>; Fri, 24 Apr 1998 15:57:53 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA16210949
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 24 Apr 1998 15:57:52 -0700 (PDT)
Received: from portalcp.chevron.com (portalcp.chevron.com [207.24.17.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA14373
	for <info-performer@sgi.com>; Fri, 24 Apr 1998 15:57:51 -0700 (PDT)
	mail_from (WRVO@chevron.com)
Received: (from uucp@localhost)
	by portalcp.chevron.com (8.8.8/8.8.8) id PAA09484
	for <info-performer@sgi.com>; Fri, 24 Apr 1998 15:57:50 -0700 (PDT)
Received: from unknown(146.27.64.35) by portalcp.chevron.com via smap (4.0a)
	id xma009392; Fri, 24 Apr 98 15:57:40 -0700
Message-Id: <199804242257.PAA07841@cybil.sr.chevron.com>
Received: by chvpk-msx04-b.sr.chevron.com with Internet Mail Service (5.0.1460.8)
	id <JSRRM5VV>; Fri, 24 Apr 1998 15:57:40 -0700
From: "Volz, Bill (wrvo)" <WRVO@chevron.com>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Colortables and gsets
Date: Fri, 24 Apr 1998 15:57:35 -0700
X-Mailer: Internet Mail Service (5.0.1460.8)
Status: O

I would like to use a colortable when drawing some triangles. I want smooth
shading across all triangles.
I'm having trouble figuring out how the colortable is connected to be
vertex. Does the per vertex value in the attribute array now become a color
index? I've implemented it this way but it doesn't seem to be working. Any
suggestion on why it's not would be helpful?

I have pseudo code as follows on how I think it should work:

float *verts = (float*) pfMalloc(sizeof(float)*ntriangle*9,arena);
pfVec4 *colors = (pfVec4*) pfMalloc(sizeof(pfVec4)*ntriangle*3,arena);
... fill in verts
...set colors to appropriate index. in my case the z value of the triangle
scaled to be between 0 and 255.
gset->setAttr(PFGS_COORD3,PFGS_PER_VERTEX,verts,0);
gset->setAttr(PFGS_COLOR4,PFGS_PER_VERTEX,colors,0);
...
gstate = new(arena) pfGeoState();
pfColortable *ctab = new(arena) pfColortable(256);
...set color values
gstate->setMode(PFSTATE_ENCOLORTABLE,PF_ON);
gstate->setAttr(PFSTATE_COLORTABLE,ctab);
gset->setGState(gstate);
geode->addGSet(gset);
...->addChild(geode);

Am I missing any overrides, of other settings somewhere else? Anyone see
anything else wrong with
the above? Does this need to be applied or something?

Thanks, 
Bill Volz

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sat Apr 25 12:59:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA14738 for info-performer-dist@holodeck.engr.sgi.com; Sat, 25 Apr 1998 12:36:10 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA14711 for <info-performer@holodeck.engr.sgi.com>; Sat, 25 Apr 1998 12:36:07 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA16031452
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 25 Apr 1998 12:36:06 -0700 (PDT)
Received: from relay.eunet.no (relay.eunet.no [193.71.1.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA02504
	for <info-performer@sgi.com>; Sat, 25 Apr 1998 12:36:00 -0700 (PDT)
	mail_from (crccobr@nocrc.abb.no)
Received: from nocrc.abb.no ([193.71.72.10] (may be forged))
	by relay.eunet.no (8.8.6/8.8.5) with SMTP id VAA09149;
	Sat, 25 Apr 1998 21:35:51 +0200 (MDT)
Received: from pc-crccobr ([193.71.72.141]) by nocrc.abb.no (4.1/SMI-4.1)
	id AA07949; Sat, 25 Apr 98 21:32:48 +0100
Message-Id: <35423AD7.F4D@nocrc.abb.no>
Date: Sat, 25 Apr 1998 21:34:47 +0200
From: Dr Colin Bridgewater <crccobr@nocrc.abb.no>
Reply-To: crccobr@nocrc.abb.no
Organization: ABB Teknologi AS, Marine Oil and Gas Group
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: Castillo Joe <castillo_joe@bah.com>
Cc: SGI-PF Discussion Group <info-performer@sgi.com>
Subject: Re: mktiles
References: <3540EF81.8E9CC6B8@bah.com>
Content-Type: multipart/mixed; boundary="------------64521B341C7"
Status: O

This is a multi-part message in MIME format.

--------------64521B341C7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Joe

Castillo Joe wrote:
> Does anyone have the utility "mktiles" for making cliptextures??

Herewith a copy. It makes RGB sub-tiles from a larger image. These
sub-tiles are scaled so that they are friendly to texture memory. For
example, using the defaults, an image at 1280x1024 would be broken up
into numbered 80 (!) sub-images of 128x128 each.... 

Not true clip-texturing in the Performer sense, but a *very* hacky
attempt at geting my O2 to look as though it was doing it.... I used a
DBASE process to figure out which of the sub-tiles might become visible
and updated the scene graph accordingly. 

If you want to generate multiple resolution textures, take a look at the
fitimg utility for scaling complete images from, for example 1280x1024
to 320x256 pixels. Hope you find the script useful anyway.

Best wishes

Colin

PS there is a version of mktiles around which had some useful features
added, but I can't find where I saved it.... Groan.
_______________________________________________________________________
Dr Colin Bridgewater    crccobr@nocrc.abb.no    Marine Oil and Gas Dept
ABB Teknologi AS, Bergerveien 12, PO Box 91, N-1361 BILLINGSTAD, Norway
work tel: +47 66 84 35 36, fax: +47 66 84 43 90,  home: +44 1189 671713

--------------64521B341C7
Content-Type: text/plain; charset=us-ascii; name="mktiles"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="mktiles"

#!/bin/csh -f
#
# mktiles                                    Colin B 05.11.97
#
# usage:  mktiles <input file> [x tile size [y tile size]]
#
# Description
#     Script to take a large image and generate lots of sub-tiles at
#     texture-memory-friendly sizes. 
#
#     Because the sub-tiles have sides which are some power of 2 in 
#     length (eg 128x128 or 64x256), the tiles may not make up the 
#     image size exactly. In this case, the script warps the input 
#     image to ensure that the side lengths will fit the tiles. The 
#     warped image is named accordingly.
#
#     Assumes a default tile size of 128 x 128 unless told otherwise.
#     Checks that subimg, izoom and imginfo are installed.
# 
# Problems (challenges?)
#     1.  Does not check that the tile sizes are numbers....
#     2.  Only outputs SGI RGB format image files.
#
# Enhancements
#     1.  Use getopts to extract the arguments.
#     2.  User-definable output file name.
#     3.  User-definable output file type.
#
# ---------------------------------------------------------------------
#
# if no file specified, quit with rude error message

if ("$1" == "" | "$1" == "-h") then 
	if ("$1" == "") then 
		echo "Error:     no argument(s) supplied, aborting"
		echo ""
	endif
	echo   "Usage is:  mktiles <input file> [xtilesize [ytilesize]]"
	echo   "           mktiles -h"
	exit 0
endif


# if imginfo or izoom don't exist, then there are problems

if (-s /usr/sbin/subimg & -s /usr/sbin/imginfo & -s /usr/sbin/izoom)  then
	;
else
	echo "Error:     subimg, imginfo or izoom not available, aborting."
	echo "           Check permissions of /usr/sbin and re-install"
	echo "           software product subsytem: imgtools.sw.tools"
	exit 0
endif


# set the default tile size to 128 x 128

@ defsize = 128


# set the file name from which sub-images are to be taken
# necessary for when the warped image is to be used

set infile = $1


# if no tile sizes specified, assume defaults
# else if x tile size is specified, set y tile size to match
# else both sizes are specified on the command line

if ("$2" == "") then
	echo "No tile sizes specified, using $defsize x $defsize"
	@ xtsize = $defsize
	@ ytsize = $defsize
else
	@ xtsize = $2
	if ("$3" == "")  then
		@ ytsize = $xtsize
		echo "No y tile size specified, using $xtsize"
	else
		@ ytsize = $3
	endif
endif


# Get the image size from the image file

@ xsize = `imginfo $infile | grep Dimensions | cut -f2 -d : | cut -f1 -d ,`
@ ysize = `imginfo $infile | grep Dimensions | cut -f2 -d : | cut -f2 -d ,`

echo ""
echo "Size of image in $infile is $xsize by $ysize pixels"


# calculate the number of tiles to be made
# round the results (up or down) to the nearest tile size

@ xn = ( 2 * $xsize + $xtsize ) / ( 2 * $xtsize )
@ yn = ( 2 * $ysize + $ytsize ) / ( 2 * $ytsize )

@ xs = $xn * $xtsize 
@ ys = $yn * $ytsize 

echo "  - will make $xn columns by $yn rows of tiles"
echo "  - final image size will be $xs by $ys pixels"


# check that the tiles give exact coverage of the input image
# if they do not, warp the input image accordingly before
# extracting the sub-images
# nawk command string courtesy of Greg Edwards, SGI UK

if ($xs != $xsize | $ys != $ysize)  then

	# print a warning
	echo ""
	echo "Final tiled image is of different size to input image"
	echo "  - warping input image to suit tile sizes"

	# warp the image using izoom and nawk
	set warpfile = "bigtile.rgb"
	set nawkcom =  `nawk 'BEGIN { xzoom = '$xs' / '$xsize' ; yzoom = '$ys' / '$ysize' ; print "izoom", "'$infile'", "'$warpfile'", xzoom, yzoom } { }' /dev/null `  
	echo -n "    "
	echo $nawkcom

	$nawkcom
	echo "  - done"
	set infile = "$warpfile"

	# print some file information
	echo ""
	echo "File Information"
	echo "  - warped image name is $infile"
else
	echo ""
	echo "File Information"
endif


# tell the user what the file name means

@ xn -= 1
@ yn -= 1

echo "  - file names will be tile.[x:0..$xn].[y:0..$yn].rgb"


# set up the mask variables for taking the sub-images

@ x0 = 0
@ x1 = $xtsize - 1
@ y0 = 0 
@ y1 = $ytsize - 1


# set the output file name to tile.a.b.rgb

@ a = 0
@ b = 0


# use two nested while loops to chop up the image into lots of smaller 
# ones. Have to do some mucking around with the counters to make sure 
# that the tile sizes are correct....

echo
echo "Making the tiles now"
echo -n "  "

while ($x1 <= $xsize)

	while ($y1 <= $ysize)
		# make the sub-image from the input file
		subimg $infile tile.$a.$b.rgb $x0 $x1 $y0 $y1

		# increment the image sizes in the y sense
		@ y0  = $y1 + 1 
		@ y1 += $ytsize 
		@ b  += 1
		echo -n "."
	end

	# reset the image sizes in the x and y senses
	@ x0  = $x1 + 1 
	@ x1 += $xtsize
	@ y0  = 0
	@ y1  = $ytsize - 1

	# reset the counters
	@ a += 1
	@ b  = 0

	echo ""
	echo -n "  "
end


# Tell the user we have finished

echo ""
echo Done


# ---- End of File ----

--------------64521B341C7--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sat Apr 25 19:55:51 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA15329 for info-performer-dist@holodeck.engr.sgi.com; Sat, 25 Apr 1998 19:35:25 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id TAA15302 for <info-performer@holodeck.engr.sgi.com>; Sat, 25 Apr 1998 19:35:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id TAA16045081
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 25 Apr 1998 19:35:18 -0700 (PDT)
Received: from aud.ucla.edu (alberti.aud.ucla.edu [128.97.173.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id TAA03022
	for <info-performer@sgi.com>; Sat, 25 Apr 1998 19:35:16 -0700 (PDT)
	mail_from (friedman@ucla.edu)
Received: from ucla.edu by aud.ucla.edu (SMI-8.6/SMI-SVR4)
	id TAA05562; Sat, 25 Apr 1998 19:36:06 -0700
Message-ID: <35429B24.5D52D467@ucla.edu>
Date: Sat, 25 Apr 1998 19:25:40 -0700
From: "Scott A. Friedman" <friedman@ucla.edu>
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: nb_getpipe ??
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi,

I have an application that crashes on some machines in a routine called
nb_getpipe().

The suspect machines are all running performer 2.2.  One is an O2 irix
6.3 and the other is an Impact irix 6.2.  I have two other irix 6.2
machines (Impact and Onyx) that work - we cannot figure out what's
different between the two Impacts (!).  The app works on 6.4 Onyx and
Octane.

What is nb_getpipe() ??

Thanks,
Scott Friedman
UCLA



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Sun Apr 26 06:48:56 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA16055 for info-performer-dist@holodeck.engr.sgi.com; Sun, 26 Apr 1998 06:24:54 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA16028 for <info-performer@holodeck.engr.sgi.com>; Sun, 26 Apr 1998 06:24:52 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA16703835
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 26 Apr 1998 06:24:52 -0700 (PDT)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA26254
	for <info-performer@sgi.com>; Sun, 26 Apr 1998 06:24:50 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id PAA16001; Sun, 26 Apr 1998 15:34:09 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma015999; Sun, 26 Apr 98 15:33:56 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id PAA18924;
	Sun, 26 Apr 1998 15:24:13 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804261324.PAA18924@s00sn1.fel.tno.nl>
Subject: Re: Books on Performer
To: WRVO@chevron.com (Volz, Bill)
Date: Sun, 26 Apr 1998 15:24:12 +0200 (MET DST)
Cc: info-performer@sgi.com
In-Reply-To: <199804242259.PAA07934@cybil.sr.chevron.com> from "Volz, Bill" at Apr 24, 98 03:59:23 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> 
> The Performer Programmer's guide that SGI provides with the course is pretty
> weak on content on actual programming details. Is there a book written by
> someone in the know that someone would like to recommend? Like the little
> red book for OpenGL.
> 
> Thanks,
> 
> Bill Volz

Read the insight books
    IRIS Performer Getting Started Guide
    IRIS Performer Programmer's Guide

Or read them from the Web

http://techpubs.sgi.com/

search for performer in the title

Mario
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 00:50:29 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA17257 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 00:35:43 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id AAA17230 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 00:35:41 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA15104430
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 00:35:41 -0700 (PDT)
Received: from exchange.dreamteam.com ([194.90.157.242]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id AAA17648
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 00:35:39 -0700 (PDT)
	mail_from (roni@dreamteam-ltd.com)
Received: from dreamteam-ltd.com (194.90.157.221 [194.90.157.221]) by exchange.dreamteam.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id JQHPJV5C; Mon, 27 Apr 1998 10:34:28 +0200
Message-ID: <3544353C.C8923040@dreamteam-ltd.com>
Date: Mon, 27 Apr 1998 10:35:24 +0300
From: Roni Kass <roni@dreamteam-ltd.com>
Organization: DreamTeam Ltd.
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: COSMO3D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O



Is there a ListServer for Cosmo 3D ??


Roni Kass
DreamTeam Ltd.

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 04:58:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA17665 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 04:37:00 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA17638 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 04:36:59 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA16860553
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 04:36:58 -0700 (PDT)
Received: from aba.ihpc.nus.edu.sg (aba.ihpc.nus.edu.sg [137.132.15.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA12798
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 04:36:55 -0700 (PDT)
	mail_from (liuxy@nsrc.nus.edu.sg)
Received: (from smap@localhost)
          by aba.ihpc.nus.edu.sg (8.8.5/8.8.4)
	  id TAA06119 for <info-performer@sgi.com>; Mon, 27 Apr 1998 19:36:53 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma006114; Mon Apr 27 19:36:28 1998
Message-ID: <35446DF8.4494@nsrc.nus.edu.sg>
Date: Mon, 27 Apr 1998 19:37:28 +0800
From: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Organization: National Supercomputing Research Center
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: ghost polygons
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

Hi, performers,

For certain models displayed in our performer applcation, there are
some ghost polygons flashing around. While viewed in IVVIEW or
saved as .pfb files, they are gone. What's happening? The machine
used is Onyx2 with 2 IR , performer 2.1.

Thanks for reading.

Liu
***********************************************************************
Liu Xiaoyan                 Institute of High Performance Computing
Data Visualisation Group    http://www.ihpc.nus.edu.sg Tel:(65)7709267
***********************************************************************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 05:46:00 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA17872 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 05:33:50 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA17845 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 05:33:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA17047375
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 05:33:48 -0700 (PDT)
Received: from relay.eunet.no (relay.eunet.no [193.71.1.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA28968
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 05:33:07 -0700 (PDT)
	mail_from (crccobr@nocrc.abb.no)
Received: from nocrc.abb.no ([193.71.72.10] (may be forged))
	by relay.eunet.no (8.8.6/8.8.5) with SMTP id OAA29498;
	Mon, 27 Apr 1998 14:31:11 +0200 (MDT)
Received: from pc-crccobr ([193.71.72.141]) by nocrc.abb.no (4.1/SMI-4.1)
	id AA21954; Mon, 27 Apr 98 14:28:07 +0100
Message-Id: <35447A4D.6B5E@nocrc.abb.no>
Date: Mon, 27 Apr 1998 14:30:05 +0200
From: Dr Colin Bridgewater <crccobr@nocrc.abb.no>
Reply-To: crccobr@nocrc.abb.no
Organization: ABB Teknologi AS, Marine Oil and Gas Group
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Cc: Performer Discussion Group <info-performer@sgi.com>
Subject: Re: ghost polygons
References: <35446DF8.4494@nsrc.nus.edu.sg>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Greetings from Norway

Liu Xiaoyan wrote: 
> For certain models displayed in our performer applcation, there are
> some ghost polygons flashing around. While viewed in IVVIEW or
> saved as .pfb files, they are gone. What's happening? The machine
> used is Onyx2 with 2 IR , performer 2.1.

Depends on what you mean by "ghost polygons". Might be a problem with
your models where there are polygons with their back-faces enabled. Can
you be a bit more specific to help us exorcise your ghosts ? 

Best wishes

Colin
_______________________________________________________________________
Dr Colin Bridgewater    crccobr@nocrc.abb.no    Marine Oil and Gas Dept
ABB Teknologi AS, Bergerveien 12, PO Box 91, N-1361 BILLINGSTAD, Norway
work tel: +47 66 84 35 36, fax: +47 66 84 43 90,  home: +44 1189 671713
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 06:25:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA18048 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 06:13:26 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA18021 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 06:13:21 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA14444566
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 06:13:20 -0700 (PDT)
Received: from gwsmtp.thomson.fr (gwsmtp.thomson.fr [195.101.37.140]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA12506
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 06:13:13 -0700 (PDT)
	mail_from (PHILIPPE.P.P.POUTIGNAT@TTS.thomson.fr)
From: PHILIPPE.P.P.POUTIGNAT@TTS.thomson.fr
Received: by gwsmtp.thomson.fr (NPlex 2.0.098); 27 Apr 1998 15:14:15 +0100
X400-Received: by mta TFM-SMTP in /PRMD=THOMSON/ADMD=ATLAS/C=FR; relayed; 27 Apr 1998 15:14:14 +0100
To: info-performer@sgi.com
Subject: OpenGL-Optimizer
X400-MTS-Identifier: [/PRMD=THOMSON/ADMD=ATLAS/C=FR;7242571427041998/A19973/INDRE]
Message-Id: <7242571427041998/A19973/INDRE/11C4DBB92300@MHS>
Date: 27 Apr 1998 14:59:48 +0000
Importance: normal
Sensitivity: confidential
Autoforwarded: false
Status: O

Hi Performers !
Is there a mailing list for openGL Optimizer ?
If not, what is the mail of the person responsible for 
this product ?
Thanx

			Philippe Poutignat
			Thomson Traning & Simulation
			1 Rue du General de Gqulle
			ZI Les Beaux Soleils BP 226
			95523 Cergy Pontoise
			FRANCE


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 08:13:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA18295 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 07:58:43 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA18268 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 07:58:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA17162456
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 07:58:42 -0700 (PDT)
Received: from camus.paradigmsim.com (camus.paradigmsim.com [206.7.114.160]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA09377; Mon, 27 Apr 1998 07:56:57 -0700 (PDT)
	mail_from (rweyrauch@paradigmsim.com)
Received: from paradigmsim.com (camus.paradigmsim.com [206.7.114.160]) by camus.paradigmsim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09963; Mon, 27 Apr 1998 09:29:18 -0500
Sender: rweyrauch@paradigmsim.com
Message-ID: <3544963D.5A8DFC77@paradigmsim.com>
Date: Mon, 27 Apr 1998 09:29:17 -0500
From: Rick Weyrauch <rweyrauch@paradigmsim.com>
Reply-To: rweyrauch@paradigmsim.com
Organization: Paradigm Simulation Inc.
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: Angus Dorbie <dorbie@sgi.com>
CC: Steve Baker <sbaker@link.com>, info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <Pine.SGI.3.96.980424072047.5113D-100000@lechter.bgm.link.com> <3540CCC1.A791E07@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Angus Dorbie wrote:
> 
> Steve Baker wrote:
> >
> > On Thu, 23 Apr 1998, Rick Weyrauch wrote:
> >
> > > I am also interested in developing an open 'freeware' scene graph
> > > toolkit for OpenGL.  The graphics community (both on Linux and Win32)
> > > could use such a tool.
> > >
> > > With the advent of Fahrenheit, it there a problem with SGI releasing the
> > > OpenGL++ spec to the public?
> >
> > Kurt Akeley said:
> >
> >   "SGI will no longer be able to push OpenGL++ (though they have no objection to
> >   others picking up the work)."
> >
> > Also, the OpenGL++ spec presumably belongs to the OpenGL ARB and not to SGI,
> > so I presume we'd have to talk to the ARB to get a copy of it.
> 
> This in no way indicates SGI official policy but I don't see how you can
> say
> this. Just because a document is presented to a comittee for review,
> doesn't
> convey all the rights to it's contents, particularly the ownership of
> any IP
> described in it, but I'm no lawyer and don't know all that was said or
> exchanged w.r.t. the spec.
> 
> >
> > I have a copy of the spec - but it's under NDA from SGI - so I can't use that
> > as the basis of a 'Mesa++' effort. Following Kurt's announcement, there should
> > be no problem getting hold of the current spec without NDA - I presume.
> 
> There's a big difference between running with an OpenGL scene graph idea
> and
> using the NDA spec lock, stock and barrel. None of this is is SGI
> policy, but even
> if the OpenGL++ spec were left to the ARB, it may very well be the case
> that
> nobody on the ARB is interested in OpenGL++ anymore. As I have already
> pointed
> out most ARB members now have a significant stake in Fahrenheit or their
> own
> Scene Graph strategies like Java 3D, and Raytheon isn't on the ARB :-(.
> 
> Why would you want or need to base Mesa++ on OpenGL++ if the rest of the
> world
> is using FSG and there is no _real OpenGL++.

The only reason for using the OpenGL++ spec is that is (was) a spec that
a number of net-developer could write code to.  Without a solid spec,
developing a useful scene graph library would be chaotic.

If SGI does not allow us to use the OpenGL++ spec, then we'll have to
come up with our own in order to develop a 'Mesa++'.


CYA statement:
I am speaking for myself in this thread, Rick Weyrauch, late-night
graphics hacker, not Rick Weyrauch Vega engineer.


> 
> I want to make it absolutely clear that these are just a personal
> observations
> of the issues raised by Steve and don't reflect SGIs views in any way.
> 
> Cheers,Angus.
> 
> --
> "Only the mediocre are always at their best." -- Jean Giraudoux
> 
> For advanced 3D graphics Performer + OpenGL based examples and tutors:
> http://www.dorbie.com/

Rick

-- 

Rick Weyrauch				voice: (972) 960-2301
Paradigm Simulation Inc.		fax:   (972) 960-2303
14900 Landmark Blvd., Suite 400		rweyrauch@paradigmsim.com
Dallas TX 75240				www.paradigmsim.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 07:53:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA18257 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 07:45:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA18230 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 07:45:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA17007472
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 07:45:18 -0700 (PDT)
Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA01129
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 07:42:50 -0700 (PDT)
	mail_from (oesommer@immd9.informatik.uni-erlangen.de)
Received: from immd9.informatik.uni-erlangen.de (faui90.informatik.uni-erlangen.de [131.188.39.4])
	by faui45.informatik.uni-erlangen.de (8.8.8/8.1.16-FAU) with SMTP id QAA29271; Mon, 27 Apr 1998 16:31:21 +0200 (MET DST)
Received: from faui91k.informatik.uni-erlangen.de (faui91k.informatik.uni-erlangen.de [131.188.39.37]) by immd9.informatik.uni-erlangen.de with ESMTP
	id QAA03543 (950413.SGI.8.6.12/7.5b-FAU); Mon, 27 Apr 1998 16:31:19 +0200
From: "Ove Sommer" <oesommer@immd9.informatik.uni-erlangen.de>
Message-Id: <9804271631.ZM14772@immd9.informatik.uni-erlangen.de>
Date: Mon, 27 Apr 1998 16:31:18 +0000
In-Reply-To: PHILIPPE.P.P.POUTIGNAT@TTS.thomson.fr
        "OpenGL-Optimizer" (Apr 27, 14:59)
References: <7242571427041998/A19973/INDRE/11C4DBB92300@MHS>
Reply-To: Ove Sommer <oesommer@immd9.informatik.uni-erlangen.de>
X-Sign: auto
X-Attribution: Ove
X-Face: "L*&{}n3LiTt.7acf}xAEixM8"9K?GA4z\6\m*yz*^7Vo2F0+d7^B@ox$+GG_z'<5t|X<g4
 \Gtk7.4_>F.p#%wS\m>e?O#M5Q,dN1?<Jyka|dXqGv$]&CKbrPla*+~>SR-km;is7[VM+6U{'fs|m{
 -Z\O;eNTAm~&aCZ*)2,WG@P!I-~
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: PHILIPPE.P.P.POUTIGNAT@TTS.thomson.fr
Subject: Re: OpenGL-Optimizer
Cc: Performer-Mailing-List <info-performer@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

>>>>> "PP" == Philippe Poutignat <PHILIPPE.P.P.POUTIGNAT@TTS.thomson.fr> writes:
  PP> Hi Performers !
  PP> Is there a mailing list for openGL Optimizer ?
  PP> If not, what is the mail of the person responsible for this product ?

  PP> Thanx

Hi Philippe!

Yes, there is a mailing list: info-optimizer@postofc.corp.sgi.com

Hope that helps!

Ove
-- 
======================================================================
Ove Sommer                           sommer@informatik.uni-erlangen.de
Computer Graphics Group                           Tel: +49 9131 859923
University of Erlangen-Nuremberg, Germany         Fax: +49 9131 859931
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 11:45:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA18872 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 11:43:34 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA18845 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 11:43:21 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA17199519
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 11:43:20 -0700 (PDT)
Received: from firewall.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA01783
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 11:41:02 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by firewall.fel.tno.nl; id UAA08840; Mon, 27 Apr 1998 20:38:05 +0200 (MET DST)
Received: from s00sn1.fel.tno.nl(134.203.8.207) by ns.fel.tno.nl via smap (3.2)
	id xma008823; Mon, 27 Apr 98 20:37:51 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id UAA17010;
	Mon, 27 Apr 1998 20:28:03 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804271828.UAA17010@s00sn1.fel.tno.nl>
Subject: Shadow problems on RE2 with IRISGL
To: info-performer@sgi.com (Performer)
Date: Mon, 27 Apr 1998 20:28:03 +0200 (MET DST)
Cc: rioj7@s00sn1.fel.tno.nl (Mario Veraart)
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Hello pfUsers,

I try to get shadows with Iris Performer 2.0 on an Onyx Re2 with
IRISGL.

I have used shadows.c as a start but has found that there are a few
problems. I have made a terrain with a couple of cubes on it. 

You can find this text with a couple of pictures at the following URL

http://vtd.fel.tno.nl/~fveraart/shadow/problem.html

In the following pictures the small green cube is the position of the
lightsource.
On the terrrain are a few large red cubes with a small green cube next
to it. The large terrain square is 80x80 meters and I have used a shadow map
size of 512 pixels.

1)
For a setting off the light I see that the small green cubes don't
cast any shadow.

2)
Depending on the distance of the large cube to the light the geometry
that is in shadow
is further away from the object. All of the small green cubes should
be in shadow.

3)
The objects that are in shadow are not lit with the ambient lighting
term. They are drawn black.

4)
The back side of the cubes are not in shadow.

If anyone can help me solve these problems?

Mario Veraart
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 13:34:11 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA19281 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 13:23:56 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA19254 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 13:23:55 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA17186152
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 13:23:55 -0700 (PDT)
Received: from shell8.ba.best.com (shell8.ba.best.com [206.184.139.139]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id NAA06299
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 13:23:53 -0700 (PDT)
	mail_from (wbethel@shell8.ba.best.com)
Received: (from wbethel@localhost) by shell8.ba.best.com (8.8.8/8.8.BEST) id MAA27862; Mon, 27 Apr 1998 12:23:43 -0700 (PDT)
Date: Mon, 27 Apr 1998 12:23:43 -0700 (PDT)
Message-Id: <199804271923.MAA27862@shell8.ba.best.com>
From: Wes Bethel <wbethel@r3vis.com>
To: info-performer@sgi.com
Subject: OGL++
Reply-to: wbethel@r3vis.com
Status: O


>The only reason for using the OpenGL++ spec is that is (was) a spec that
>a number of net-developer could write code to.  Without a solid spec,
>developing a useful scene graph library would be chaotic.

I've been following this discussion with rapt interest. What is not clear
to me is why one of the visible contenders on "the short list" is not
making a move to fill what appears to be a bona-fide technical need.
Is it an ARB issue, a "must get the blessing of [SGI, ARB, ??]"?

To throw another chicken into the fight, so to speak, we make a 
scene graph based tool that works well with either OpenGL or Mesa, and
has been used as the modeling and rendering base in products that
are now coming to market.  It's geared towards scientific visualization,
rather than vis-sim or gaming, so may not appeal to this crowd.

Is there another forum for this besides the performer list? 

Wes






=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 13:56:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA19467 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 13:52:47 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA19428 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 13:52:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA17242124
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 13:52:43 -0700 (PDT)
Received: from otter.mbay.net (otter.mbay.net [206.40.79.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id NAA20651
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 13:52:41 -0700 (PDT)
	mail_from (kent@watsen.net)
Received: from watsen.net (smorgum.cs.nps.navy.mil [131.120.7.99])
	by otter.mbay.net (8.8.8/8.8.8) with ESMTP id NAA32322
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 13:52:39 -0700
Message-ID: <3544EF78.CB82A651@watsen.net>
Date: Mon, 27 Apr 1998 13:50:00 -0700
From: Kent Watsen <kent@watsen.net>
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <Pine.SGI.3.96.980424072047.5113D-100000@lechter.bgm.link.com> <3540CCC1.A791E07@sgi.com> <3544963D.5A8DFC77@paradigmsim.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

This isn't getting anywhere.  Its unlikely the ARB
will release the OGL++ spec and yet an open scene
graph API should be made available for alternative
OS ports.  Perhaps freeware advocates should start
thinking about what they really want and just do it.
I'd love to help develop a streaming geometry (read
progressive mesh) API toolkit.  

Are we mice or men?

--
Kent Watsen
http://watsen.net/kent
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 14:23:46 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA19607 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 14:07:38 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA19580 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 14:07:34 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA15857855
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 14:07:33 -0700 (PDT)
Received: from relay3.smtp.psi.net (relay3.smtp.psi.net [38.8.210.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA28177
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 14:07:31 -0700 (PDT)
	mail_from (bills@FTIORL02.ENZIAN.COM)
Received: from [38.227.238.3] (helo=FTIORL02.ENZIAN.COM)
	by relay3.smtp.psi.net with esmtp (Exim 1.90 #1)
	for info-performer@sgi.com
	id 0yTv7R-0002KG-00; Mon, 27 Apr 1998 17:07:21 -0400
Received: from FTIORL02/SpoolDir by FTIORL02.ENZIAN.COM (Mercury 1.40);
    27 Apr 98 17:06:30 EST
Received: from SpoolDir by FTIORL02 (Mercury 1.40); 27 Apr 98 17:06:26 EST
From: "Bill Storma" <bills@FTIORL02.ENZIAN.COM>
Organization: Future Technologies, Inc.
To: info-performer@sgi.com
Date: Mon, 27 Apr 1998 17:06:25 EST
Subject: Are you alive ???
Message-ID: <215F3F936FE@FTIORL02.ENZIAN.COM>
Status: O

I am trying to find out why I have not gotten ANY responses to my 
last two e-mails, concering questions/problems with performer.  Is 
this address still valid ?  Is there a reason why I am not getting 
any responses ?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Bill Storma                     Phone:  407-384-6900
Future Technologies             FAX:    407-381-1010
Orlando, Fl.  32826             e-mail: bills@fti.enzian.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 14:44:22 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA19767 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 14:24:41 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA19738 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 14:24:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA17134626
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 14:24:35 -0700 (PDT)
Received: from cavalier.cambridge.com (mail.cambridge.com [208.148.185.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id OAA05547
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 14:24:33 -0700 (PDT)
	mail_from (mcmillan@cambridge.com)
Received: by cavalier.cambridge.com (951211.SGI.8.6.12.PATCH1042/940406.SGI)
	 id RAA17774; Mon, 27 Apr 1998 17:23:15 -0400
Received: from ds9(192.9.200.40) by cavalier via smap (3.1)
	id xma017771; Mon, 27 Apr 98 17:23:11 -0400
Received: from ducati.cambridge.com by ds9.cambridge.com (4.1/SMI-4.1-SWS)
	id AA11400; Mon, 27 Apr 98 17:18:54 EDT
Received: from ducati by ducati.cambridge.com (940816.SGI.8.6.9/SMI-4.1-SWS)
	id RAA04032; Mon, 27 Apr 1998 17:23:08 -0400
Sender: mcmillan@cambridge.com
Message-Id: <3544F73B.41C6@cambridge.com>
Date: Mon, 27 Apr 1998 17:23:07 -0400
From: Scott McMillan <mcmillan@cambridge.com>
Organization: Cambridge Research Associates
X-Mailer: Mozilla 3.01 (X11; I; IRIX 5.3 IP20)
Mime-Version: 1.0
To: Kent Watsen <kent@watsen.net>
Cc: info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <Pine.SGI.3.96.980424072047.5113D-100000@lechter.bgm.link.com> <3540CCC1.A791E07@sgi.com> <3544963D.5A8DFC77@paradigmsim.com> <3544EF78.CB82A651@watsen.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Kent Watsen wrote:
> 
> Are we mice or men?

Squeak!?  ;-)

-- 
Scott McMillan                   mailto:mcmillan@cambridge.com
Cambridge Research Associates    Ministry of Silly Walks
1430 Spring Hill Road, Ste. 200  Voice: (703) 790-0505 x7235
McLean, VA 22102                 Fax:   (703) 790-0370
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 15:45:24 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA20109 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 15:27:06 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA20082 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 15:27:04 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA17323539
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 15:27:04 -0700 (PDT)
Received: from dfw-ix14.ix.netcom.com (dfw-ix14.ix.netcom.com [206.214.98.14]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA01634
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 15:27:02 -0700 (PDT)
	mail_from (bfolse@ix.netcom.com)
Received: (from smap@localhost)
          by dfw-ix14.ix.netcom.com (8.8.4/8.8.4)
	  id RAA14297; Mon, 27 Apr 1998 17:26:47 -0500 (CDT)
Received: from hou-tx57-06.ix.netcom.com(207.221.74.134) by dfw-ix14.ix.netcom.com via smap (V1.3)
	id rma014270; Mon Apr 27 17:26:27 1998
Received: by MIDWESTDEMO with Microsoft Mail
	id <01BD7200.EC2ADB40@MIDWESTDEMO>; Mon, 27 Apr 1998 17:21:32 -0500
Message-ID: <01BD7200.EC2ADB40@MIDWESTDEMO>
From: "Barry S. Folse" <bfolse@ix.netcom.com>
To: "'Sylvain Mayer'" <mayer@poster.cae.ca>
Cc: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: RE: rear-view mirror
Date: Mon, 27 Apr 1998 17:21:15 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Status: O

I don't think this solution is correct.  Besides facing the channel =
backwards, you also need to invert it.  Without inverting it, if you saw =
an ambulance in your "mirror", the writing on the front of it would =
still read "ecnalubma". =20

I'm not sure how that would be done, possibly by giving the view matrix =
a negative Y-scale.  Anyone?

Barry Folse

-----Original Message-----
From:	Sylvain Mayer=20
Sent:	Tuesday, April 14, 1998 1:42 PM
To:	info-performer@sgi.com
Subject:	Re: rear-view mirror

Alain Chauffaut wrote:
>=20
> Hello,
>=20
> I would like to simulate a rear-view mirror with Performer.
>=20

Hi,

all you need to do is create a new channel with different parameters
from your main channel (the rear channel can be attached to your main
channel and they will share attributes like scene and so on).  They have
to have different viewport and of course you want to have an offset to
look behind.

This should be something like your starting point:

// create both channels
chans[MAIN_CHANNEL] =3D new pfChannel(pipe);
chans[REAR_CHANNEL] =3D new pfChannel(pipe);
chans[MAIN_CHANNEL]->attach(chans[REAR_CHANNEL]);

// you don't want to share the view
uint share =3D chans[MAIN_CHANNEL]->getShare();
share &=3D ~PFCHAN_VIEW;
chans[MAIN_CHANNEL]->setShare(share);

// attach the scene only to the first channel
chans[MAIN_CHANNEL]->setScene(scene);

// rear channel will look behind and be drawn in the upper right corner
offset.xyz.set(0.0f, 0.0f, 0.0f);
offset.hpr.set(180.0f, 0.0f, 0.0f);
chans[REAR_CHANNEL]->setViewOffsets(offset.xyz, offset.hpr);
chans[REAR_CHANNEL]->setViewport(0.65f, 1.0f, 0.65f, 1.0f);

--=20

Sylvain Mayer, 3D Graphics Developer
Visual Database Tools
CAE Electronics Ltd. (http://www.cae.ca)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 19:54:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA20728 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 19:36:48 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id TAA20701 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 19:36:47 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id TAA17356482
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 19:36:46 -0700 (PDT)
Received: from uumail-relay-blr.ernet.in (uumail-relay-blr.ernet.in [202.141.1.17]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id TAA21780
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 19:36:40 -0700 (PDT)
	mail_from (ada.ernet.in!ada.ernet.in!mdrp)
Received: from ada.UUCP (uucp@localhost)
	by uumail-relay-blr.ernet.in (8.8.8/8.8.8) with UUCP id HAA26215
	for info-performer@sgi.com; Tue, 28 Apr 1998 07:10:07 +0530
Received: from ada by ernet.in (5.x/SMI-SVR4)
	id AA12569; Mon, 27 Apr 1998 17:29:39 -0500
Date: Mon, 27 Apr 1998 17:29:38 -0500 (GMT)
From: "Mr. M.D.R. Prasad - VR Group" <mdrp@ada.ernet.in>
X-Sender: mdrp@ada
To: info-performer@sgi.com
Subject: Picking in Trackball mode
Message-Id: <Pine.SOL.3.95.980427172805.12559B-100000@ada>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


Hi Performers,

    From my scene, I would like to pick each geode at a time, and
manipulate it in the trackball mode. To do this, I am picking the
component using pfiPick and doPick method. I then attach a local DCS to
this picked geode, and pass this dcs to pfiXformerAutoPosition to update
the position of the geode. 

        This works fine, when I pick and move any of the geodes for the
first time. My problem starts, when I want to pick an already moved geode.
The moment I pick an already moved geode, it jumps. This is coz its DCS
matrix, is always being set to the just previously moved geode's DCS
matrix. 
 
        I tried explicitly setting the member variable "xPosMat" of the
class pfiInputXformTrackball to the previously stored DCS mat. This doesnt
seem to work. 

Help in this regard is appreciated!  Thanx in advance. 

------------------------ 
MADHAVI D R 
Project Manager
Aeronautical Development Agency
 Bangalore
 India


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Mon Apr 27 20:46:06 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id UAA20929 for info-performer-dist@holodeck.engr.sgi.com; Mon, 27 Apr 1998 20:31:50 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id UAA20902 for <info-performer@holodeck.engr.sgi.com>; Mon, 27 Apr 1998 20:31:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id UAA17475382
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 27 Apr 1998 20:31:42 -0700 (PDT)
Received: from aba.ihpc.nus.edu.sg (aba.ihpc.nus.edu.sg [137.132.15.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id UAA03445
	for <info-performer@sgi.com>; Mon, 27 Apr 1998 20:31:27 -0700 (PDT)
	mail_from (liuxy@nsrc.nus.edu.sg)
Received: (from smap@localhost)
          by aba.ihpc.nus.edu.sg (8.8.5/8.8.4)
	  id LAA13260; Tue, 28 Apr 1998 11:30:30 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma013256; Tue Apr 28 11:30:06 1998
Message-ID: <35454D6C.7692@nsrc.nus.edu.sg>
Date: Tue, 28 Apr 1998 11:30:52 +0800
From: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Organization: National Supercomputing Research Center
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: crccobr@nocrc.abb.no
CC: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>,
        Performer Discussion Group <info-performer@sgi.com>
Subject: Re: ghost polygons
References: <35446DF8.4494@nsrc.nus.edu.sg> <35447A4D.6B5E@nocrc.abb.no>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

> > For certain models displayed in our performer applcation, there are
> > some ghost polygons flashing around. While viewed in IVVIEW or
> > saved as .pfb files, they are gone. What's happening? The machine
> > used is Onyx2 with 2 IR , performer 2.1.
> 
> Depends on what you mean by "ghost polygons". Might be a problem with
> your models where there are polygons with their back-faces enabled. >Can you be a bit more specific to help us exorcise your ghosts ?
> 

By 'ghost ploygons' I mean they don't exsit at all in our original
geometry when built in Alias and other software. After exported to .iv
and viewed in perfly, ivview , they don't come out. Only in our
CAVE performer application do they appear. 

They are mostly in the form of triangles(with two-sided lighting 
on or off), appear randomly depend on my eye position. Our application
is basically a 4 channel(2 channels share a pipe) program.

Thanks.

Liu
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 07:21:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA21698 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 07:01:04 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA21671 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 07:00:48 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA14579514
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 07:00:47 -0700 (PDT)
Received: from cavalier.cambridge.com (mail.cambridge.com [208.148.185.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA11420
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 07:00:46 -0700 (PDT)
	mail_from (mcmillan@cambridge.com)
Received: by cavalier.cambridge.com (951211.SGI.8.6.12.PATCH1042/940406.SGI)
	 id JAA21167; Tue, 28 Apr 1998 09:55:00 -0400
Received: from ds9(192.9.200.40) by cavalier via smap (3.1)
	id xma021164; Tue, 28 Apr 98 09:54:36 -0400
Received: from ducati.cambridge.com by ds9.cambridge.com (4.1/SMI-4.1-SWS)
	id AA12208; Tue, 28 Apr 98 09:50:19 EDT
Received: from ducati by ducati.cambridge.com (940816.SGI.8.6.9/SMI-4.1-SWS)
	id JAA04712; Tue, 28 Apr 1998 09:54:35 -0400
Sender: mcmillan@cambridge.com
Message-Id: <3545DF98.2781@cambridge.com>
Date: Tue, 28 Apr 1998 09:54:32 -0400
From: Scott McMillan <mcmillan@cambridge.com>
Organization: Cambridge Research Associates
X-Mailer: Mozilla 3.01 (X11; I; IRIX 5.3 IP20)
Mime-Version: 1.0
To: "Barry S. Folse" <bfolse@ix.netcom.com>
Cc: "'Sylvain Mayer'" <mayer@poster.cae.ca>,
        "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: rear-view mirror
References: <01BD7200.EC2ADB40@MIDWESTDEMO>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Barry S. Folse wrote:
> 
> I don't think this solution is correct.  Besides facing the channel
> backwards, you also need to invert it.  Without inverting it, if
> you saw an ambulance in your "mirror", the writing on the front
> of it would still read "ecnalubma".
> 
> I'm not sure how that would be done, possibly by giving the view
> matrix a negative Y-scale.  Anyone?

yep you need to reverse right and left...I used the negative
scale in OpenGL once.

-- 
Scott McMillan                   mailto:mcmillan@cambridge.com
Cambridge Research Associates    Ministry of Silly Walks
1430 Spring Hill Road, Ste. 200  Voice: (703) 790-0505 x7235
McLean, VA 22102                 Fax:   (703) 790-0370
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 07:39:59 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA21748 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 07:25:16 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA21721 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 07:25:15 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA17684491
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 07:25:14 -0700 (PDT)
Received: from zeus.lnk.com (zeus.lnk.com [198.116.32.11]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA18913
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 07:25:13 -0700 (PDT)
	mail_from (dchan@zeus.lnk.com)
Received: from localhost by zeus.lnk.com (4.1/1.35)
	id AA02600; Tue, 28 Apr 98 10:25:10 EDT
Date: Tue, 28 Apr 1998 10:25:10 -0400 (EDT)
From: David Chan <dchan@zeus.lnk.com>
To: Performer mailling list <info-performer@sgi.com>
Subject: pfMalloc & object container
Message-Id: <Pine.SUN.3.95.980428100949.2425D-100000@zeus.lnk.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

HI,
	I have a problem with pfMalloc when I am using pfMalloc to create
a shared memory. Here is my simple code:

	shared=(SharedData *)pfMalloc(sizeof(SharedData),
pfGetSharedArena());

while SharedData is a typedef structure, and inside SharedData, there is a
Class container:

	typedef structure {
		....
		Console *console[10];
		....
	} SharedData;

Where Class "Console" is an abstract class, the array is to store derived
class from "Console".
	I can create an object and assign it into the array, but after
that, when I want to access the object's public function like this: 

	shared->console[0]->

It is always segmentation falut.
I am using "CC" to compile and "cc" to link the object programs on IRIX
6.2 Indy.

Any comment are welcome.
Thanks in advance.
David Chan

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 08:05:08 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA21991 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 07:48:05 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA21964 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 07:48:03 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA17416684
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 07:48:01 -0700 (PDT)
Received: from challenge (challenge.silicon.cl [200.29.42.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA27507
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 07:47:57 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Tue, 28 Apr 1998 11:47:30 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma010872; Tue, 28 Apr 98 11:47:22 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23651; Tue, 28 Apr 1998 10:52:30 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA10915; Tue, 28 Apr 1998 11:01:38 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9804281101.ZM10913@krusty>
Date: Tue, 28 Apr 1998 11:01:38 -0400
In-Reply-To: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
        "Re: ghost polygons" (Apr 28, 11:30am)
References: <35446DF8.4494@nsrc.nus.edu.sg>  <35447A4D.6B5E@nocrc.abb.no> 
	<35454D6C.7692@nsrc.nus.edu.sg>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Subject: Re: ghost polygons
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 28, 11:30am, Liu Xiaoyan wrote:
> Subject: Re: ghost polygons
> > > For certain models displayed in our performer applcation, there are
> > > some ghost polygons flashing around. While viewed in IVVIEW or
> > > saved as .pfb files, they are gone. What's happening? The machine
> > > used is Onyx2 with 2 IR , performer 2.1.
> >
> > Depends on what you mean by "ghost polygons". Might be a problem with
> > your models where there are polygons with their back-faces enabled. >Can
you be a bit more specific to help us exorcise your ghosts ?
> >
>
> By 'ghost ploygons' I mean they don't exsit at all in our original
> geometry when built in Alias and other software. After exported to .iv
> and viewed in perfly, ivview , they don't come out. Only in our
> CAVE performer application do they appear.
>
> They are mostly in the form of triangles(with two-sided lighting
> on or off), appear randomly depend on my eye position. Our application
> is basically a 4 channel(2 channels share a pipe) program.
>
> Thanks.
>
> Liu
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from Liu Xiaoyan

Could it be a Z buffer resolution problem??? Make sure you have enough Z bits
and that the far/near plane ratio doesn't exceed around 10000. Different
programs might have different default settings, thus triggering the effect.

-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Andres Bello 2777, Of. 602
E-mail: asaez@silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 105       Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 08:33:14 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA22278 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 08:18:55 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA22251 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 08:18:55 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA17619762
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 08:18:54 -0700 (PDT)
Received: from quid.engr.sgi.com ([130.62.52.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id IAA09387
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 08:18:53 -0700 (PDT)
	mail_from (robj@quid.engr.sgi.com)
Received: (from robj@localhost) by quid.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id IAA11645; Tue, 28 Apr 1998 08:18:44 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9804280818.ZM11549@quid.engr.sgi.com>
Date: Tue, 28 Apr 1998 08:18:44 -0700
In-Reply-To: "Alejandro Saez" <cano@silicon.cl>
        "Re: ghost polygons" (Apr 28, 11:01am)
References: <35446DF8.4494@nsrc.nus.edu.sg>  <35447A4D.6B5E@nocrc.abb.no> 
	<35454D6C.7692@nsrc.nus.edu.sg>  <9804281101.ZM10913@krusty>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Alejandro Saez" <cano@silicon.cl>, Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Subject: Re: ghost polygons
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

I'm still confused about what is being described here. It sounds like you're
talking about either:

o Triangles that should be drawn, not being drawn ( leaving gaps ) OR
o Triangles that should not be drawn, being drawn ( overwriting existing
geometry ) OR
o Triangles being drawn correctly but with incorrect lighting applied to them.

I've seen the third case before where random triangles were not lit which made
it look like random black triangles were drawn, try clearing the background to
a color other than black so you can see if you have a gap or a badly lit tri.
Also draw the geometry with a wireframe outline ( as per perfly, in fact load
the scene into perfly to experiment ). When you tried with perfly before did
you draw the same number of channels as your CAVE app does ? If not then try
that and see what it's like. If perfly doesn't show the same problem with the
same data then try to narrow down the differences between your app and perfly
in terms of data loading, lighting, viewing frustrum etc

Not much specific help I'm afraid but it might help you define the problem in
more detail.

Cheers
Rob


On Apr 28, 11:01am, Alejandro Saez wrote:
> Subject: Re: ghost polygons
> On Apr 28, 11:30am, Liu Xiaoyan wrote:
> > Subject: Re: ghost polygons
> > > > For certain models displayed in our performer applcation, there are
> > > > some ghost polygons flashing around. While viewed in IVVIEW or
> > > > saved as .pfb files, they are gone. What's happening? The machine
> > > > used is Onyx2 with 2 IR , performer 2.1.
> > >
> > > Depends on what you mean by "ghost polygons". Might be a problem with
> > > your models where there are polygons with their back-faces enabled. >Can
> you be a bit more specific to help us exorcise your ghosts ?
> > >
> >
> > By 'ghost ploygons' I mean they don't exsit at all in our original
> > geometry when built in Alias and other software. After exported to .iv
> > and viewed in perfly, ivview , they don't come out. Only in our
> > CAVE performer application do they appear.
> >
> > They are mostly in the form of triangles(with two-sided lighting
> > on or off), appear randomly depend on my eye position. Our application
> > is basically a 4 channel(2 channels share a pipe) program.
> >
> > Thanks.
> >
> > Liu
> > =======================================================================
> > List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
> >             Submissions:  info-performer@sgi.com
> >         Admin. requests:  info-performer-request@sgi.com
> >-- End of excerpt from Liu Xiaoyan
>
> Could it be a Z buffer resolution problem??? Make sure you have enough Z bits
> and that the far/near plane ratio doesn't exceed around 10000. Different
> programs might have different default settings, thus triggering the effect.
>
> --
> ------------------------------------------------------------------------
> Alejandro Saez
> Software Engineer
> Silicon Chile S.A.
>                                         Avda. Andres Bello 2777, Of. 602
> E-mail: asaez@silicon.cl              	Providencia
> Phone:  +56 (2) 203 3371 Ext. 105       Santiago
> Fax:    +56 (2) 203 3370                Chile
> ------------------------------------------------------------------------
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from Alejandro Saez



-- 
________________________________________________________________
Rob Jenkins mailto:robj@sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 08:45:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA22421 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 08:37:14 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA22394 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 08:37:09 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA17581258
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 08:37:09 -0700 (PDT)
Received: from sgisgp.singapore.sgi.com ([134.14.84.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id IAA16379
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 08:37:06 -0700 (PDT)
	mail_from (tzelin@nuno.singapore.sgi.com)
Received: from nuno.singapore.sgi.com by sgisgp.singapore.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/930416.SGI)
	for <@sgisgp.singapore.sgi.com:info-performer@sgi.com> id XAA23686; Tue, 28 Apr 1998 23:36:12 +0800
Received: (from tzelin@localhost) by nuno.singapore.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA08013 for info-performer@sgi.com; Tue, 28 Apr 1998 08:34:52 -0700
From: tzelin@nuno.singapore.sgi.com (Ong Tze Lin)
Message-Id: <199804281534.IAA08013@nuno.singapore.sgi.com>
Subject: Extracting terrain data from dxf
To: info-performer@sgi.com
Date: Tue, 28 Apr 1998 08:34:51 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL24 ME5a]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

Hi all,

I'm wondering how to get Dted or other terrain info
out of a dxf file containing contour lines.

Is there any software out there that will do that?
Right now I'm faced with having to translate
the data into inventor, and sampling the points
in the data field at appropriate intervals to construct
my own ded file.

Also I'm looking into shading the contour intervals
and using the MultiGen utility image2ded to get
a terrain mesh.

But if there are any tools out there which will make
my life easier, I'll use them!

Thanks,

Cheers,
tzelin
 
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 08:33:15 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA22333 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 08:22:53 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA22306 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 08:22:52 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA17465633
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 08:22:51 -0700 (PDT)
Received: from challenge (challenge.silicon.cl [200.29.42.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id IAA10756
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 08:22:45 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Tue, 28 Apr 1998 12:22:03 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma011133; Tue, 28 Apr 98 12:18:18 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA21245; Tue, 28 Apr 1998 11:23:27 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA10955; Tue, 28 Apr 1998 11:32:38 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9804281132.ZM10953@krusty>
Date: Tue, 28 Apr 1998 11:32:38 -0400
In-Reply-To: David Chan <dchan@zeus.lnk.com>
        "pfMalloc & object container" (Apr 28, 10:25am)
References: <Pine.SUN.3.95.980428100949.2425D-100000@zeus.lnk.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: David Chan <dchan@zeus.lnk.com>
Subject: Re: pfMalloc & object container
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 28, 10:25am, David Chan wrote:
> Subject: pfMalloc & object container
> HI,
> 	I have a problem with pfMalloc when I am using pfMalloc to create
> a shared memory. Here is my simple code:
>
> 	shared=(SharedData *)pfMalloc(sizeof(SharedData),
> pfGetSharedArena());
>
> while SharedData is a typedef structure, and inside SharedData, there is a
> Class container:
>
> 	typedef structure {
> 		....
> 		Console *console[10];
> 		....
> 	} SharedData;
>
> Where Class "Console" is an abstract class, the array is to store derived
> class from "Console".
> 	I can create an object and assign it into the array, but after
> that, when I want to access the object's public function like this:
>
> 	shared->console[0]->
>
> It is always segmentation falut.
> I am using "CC" to compile and "cc" to link the object programs on IRIX
> 6.2 Indy.
>
> Any comment are welcome.
> Thanks in advance.
> David Chan
>
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from David Chan

Could you be more specific about the error you get, and the stack trace. If the
stack trace doesn't get beyond the function that executes shared->console[0]->
then it  I would presume (which I shouldn't be doing without the appropiate
info) that there isn't actually an instance of the class in the array. Did you
try printing the value of console[0], it should be a valid address.
	If it gets past that function and execution actually enters the class's
method you called, that is a different story.

-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Andres Bello 2777, Of. 602
E-mail: asaez@silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 105       Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 09:16:14 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA22780 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 09:05:57 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA22753 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 09:05:56 -0700
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id JAA12539; Tue, 28 Apr 1998 09:05:55 -0700 (PDT)
Date: Tue, 28 Apr 1998 09:05:55 -0700 (PDT)
Message-Id: <199804281605.JAA12539@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: David Chan <dchan@zeus.lnk.com>
cc: info-performer@puget.engr.sgi.com
Subject: pfMalloc & object container
In-Reply-To: <Pine.SUN.3.95.980428100949.2425D-100000@zeus.lnk.com>
References: <Pine.SUN.3.95.980428100949.2425D-100000@zeus.lnk.com>
Status: O


David Chan writes:
 > HI,
 > 	I have a problem with pfMalloc when I am using pfMalloc to create
 > a shared memory. Here is my simple code:
 > 
 > 	shared=(SharedData *)pfMalloc(sizeof(SharedData),
 > pfGetSharedArena());
 > 
 > while SharedData is a typedef structure, and inside SharedData, there is a
 > Class container:
 > 
 > 	typedef structure {
 > 		....
 > 		Console *console[10];
 > 		....
 > 	} SharedData;
 > 
 > Where Class "Console" is an abstract class, the array is to store derived
 > class from "Console".
 > 	I can create an object and assign it into the array, but after
 > that, when I want to access the object's public function like this: 
 > 
 > 	shared->console[0]->
 > 
 > It is always segmentation falut.

I don't think that pointers work too well with shared memory here.
If the Console's were allocated from shared memory, their addresses
will possibly change from process to process.  If they weren't the
memory won't even be there in a different process.

If in fact the Console structures are to be shared, it would be better
to do:

   typedef structure {
	   ...
	   Console console[10];
	   ...
   } SharedData;

   and then

   SharedData *sd = (SharedData *)pfMalloc(sizeof(SharedData),pfGetSharedArena);
   sd->console[0] = *new Console(whatever);

// This way the console data is sure to be in shared memory too.
// There are other ways to cope with this

 > I am using "CC" to compile and "cc" to link the object programs on IRIX
 > 6.2 Indy.
 > 

If it were me, I'd try to use "CC" to link as well.  I don't know if it's the
cause of any of your problems.

-j
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 09:35:19 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA22917 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 09:26:59 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA22890 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 09:26:58 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA17386390
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 09:26:58 -0700 (PDT)
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA07052
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 09:26:53 -0700 (PDT)
	mail_from (page@ex.cv.hp.com)
Received: from cvex02.cv.hp.com (cvex02.cv.hp.com [15.7.114.238])
	by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id MAA00901
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 12:26:13 -0400 (EDT)
Received: by cvex02.cv.hp.com with Internet Mail Service (5.5.1960.3)
	id <26RNHY3A>; Tue, 28 Apr 1998 09:26:50 -0700
Message-ID: <6A3EBCD1D1C7D111931C0060B068F27A14AE77@cvex01.cv.hp.com>
From: "Page, Andrew" <page@ex.cv.hp.com>
To: info-performer@sgi.com
Subject: Re: OpenGL++ -> Fahrenheit (was Performer at ITEC)
Date: Tue, 28 Apr 1998 09:26:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Status: O

Hi All,

As one of the development partners of Fahrenheit we at HP we feel that
we should chime in on these discussions. There have been many questions
flying around and Angus and Sharon have done a great job answering them.
We want to just add a few points.

Sharon writes in her very concise summary of the OGL++ questions and
comments, 

"In truth, I don't think that last Dec. spec would provide much
insight for folks that have seen Performer and Inventor beyond
reassuring folks that we are still doing a Scene Graph.  Since the
goal here is a pervasive standard, I'd hope that folks would use
Fahrenheit and not try to start up a separate effort now on something
old.  SGI will only participate in one effort and honestly believe
what we have created with Fahrenheit is the right thing, both for ISV
and IHVs that want to be able to differentiate on top of and
underneath a ubiquitous API.  I don't think multiple efforts is going
to help anyone at this point." 

We would like to reaffirm this point. Microsoft, SGI and HP are working
hard to bring all of you a ubiquitous API. Fahrenheit is a toolkit that
goes beyond the scope of any yet produced. This is a toolkit that
reaches from the low-level APIs up to Scene Graph management and
optimization. There is also ability for ISVs and IHVs to extend and
enhance the toolkit; something new that will definitely move the
industry forward. HP too will only participate in one effort and
Fahrenheit is that effort. When the higher level components of
Fahrenheit are released later this year on HP-UX, IRIX and MS Windows
platforms application developers will have a great toolkit to work with
on the worlds leading graphics platforms.. 

If you have any questions for HP in regards to Fahrenheit, please feel
free to contact me.

					-Andrew Page
					 HP Fahrenheit Engineering
					 page@cv.hp.com
					 541-715-0039
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 09:35:14 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA22999 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 09:33:54 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA22972 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 09:33:53 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA17708712
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 09:33:52 -0700 (PDT)
Received: from zeus.lnk.com (zeus.lnk.com [198.116.32.11]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA10274
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 09:33:44 -0700 (PDT)
	mail_from (dchan@zeus.lnk.com)
Received: from localhost by zeus.lnk.com (4.1/1.35)
	id AA03005; Tue, 28 Apr 98 12:33:33 EDT
Date: Tue, 28 Apr 1998 12:33:33 -0400 (EDT)
From: David Chan <dchan@zeus.lnk.com>
To: Performer mailling list <info-performer@sgi.com>
Subject: more detail about pfMalloc & object container
Message-Id: <Pine.SUN.3.95.980428122044.2739C-100000@zeus.lnk.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

HI,
	As the problem describe in my first mail, I want to add more
detail describtion:
	the abstract class "Console" is derived from "pfObject".
	Since "Console" is abstract class, so it can't be like this:
	
	typedef structure {
		...
		Console console[10];
		...
	} SharedData;
	

	And also I try to print out the address of shared->console[0], it
is 0, and it seems I can't assign the address of new object into the
array. I do it like this:

        typedef structure {
                ...
                Console *console[10];
                ...
        } SharedData;

	SharedData *shared = (SharedData *)pfMalloc(sizeof(SharedData),
pfGetSharedArena());
	shared->console[0] = new Dervid_class_from_Console(parm1,parm2);

	Then there is segnmentation fault when I try to access object
inside the array.
	And I can't use "CC" to link object program, because one of my
program is c program, the others are c++ program with C performer API.

Thanks in advance.
David Chan	

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 09:46:26 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA23094 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 09:41:02 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA23067 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 09:41:01 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) via ESMTP id JAA33619; Tue, 28 Apr 1998 09:40:58 -0700 (PDT)
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA17610938;
	Tue, 28 Apr 1998 09:40:57 -0700 (PDT)
Received: from cavalier.cambridge.com (mail.cambridge.com [208.148.185.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA13448; Tue, 28 Apr 1998 09:40:54 -0700 (PDT)
	mail_from (mcmillan@cambridge.com)
Received: by cavalier.cambridge.com (951211.SGI.8.6.12.PATCH1042/940406.SGI)
	 id MAA24054; Tue, 28 Apr 1998 12:39:42 -0400
Received: from ds9(192.9.200.40) by cavalier via smap (3.1)
	id xma024051; Tue, 28 Apr 98 12:39:14 -0400
Received: from ducati.cambridge.com by ds9.cambridge.com (4.1/SMI-4.1-SWS)
	id AA12581; Tue, 28 Apr 98 12:34:56 EDT
Received: from ducati by ducati.cambridge.com (940816.SGI.8.6.9/SMI-4.1-SWS)
	id MAA05055; Tue, 28 Apr 1998 12:39:12 -0400
Sender: mcmillan@cambridge.com
Message-Id: <3546062F.2781@cambridge.com>
Date: Tue, 28 Apr 1998 12:39:11 -0400
From: Scott McMillan <mcmillan@cambridge.com>
Organization: Cambridge Research Associates
X-Mailer: Mozilla 3.01 (X11; I; IRIX 5.3 IP20)
Mime-Version: 1.0
To: info-performer@puget.engr.sgi.com
Cc: David Chan <dchan@zeus.lnk.com>, Jay Gischer <gischer@puget.engr.sgi.com>
Subject: Re: pfMalloc & object container
References: <Pine.SUN.3.95.980428100949.2425D-100000@zeus.lnk.com> <199804281605.JAA12539@puget.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Jay Gischer wrote:
> 
> David Chan writes:
>  > HI,
>  >      I have a problem with pfMalloc when I am using pfMalloc to create
>  > a shared memory. Here is my simple code:
>  >
>  >      shared=(SharedData *)pfMalloc(sizeof(SharedData),
>  > pfGetSharedArena());
>  >
>  > while SharedData is a typedef structure, and inside SharedData, there is a
>  > Class container:
>  >
>  >      typedef structure {
>  >              ....
>  >              Console *console[10];
>  >              ....
>  >      } SharedData;
>  >
>  > Where Class "Console" is an abstract class, the array is to store derived
>  > class from "Console".
>  >      I can create an object and assign it into the array, but after
>  > that, when I want to access the object's public function like this:
>  >
>  >      shared->console[0]->
>  >
>  > It is always segmentation falut.
> 
> I don't think that pointers work too well with shared memory here.
> If the Console's were allocated from shared memory, their addresses
> will possibly change from process to process.  If they weren't the
> memory won't even be there in a different process.

I have never had a problem with abstract base class pointers in
shared memory, provided the derived class is allocated out of
the same shared arena.  I believe I had to write a new operator for
the class to accomplish this, but my memory is a bit fuzzy.

scott

P.S. I vote you use CC to link as well.  Using cc to link is
a nasty carryover from old Performer makefiles.

-- 
Scott McMillan                   mailto:mcmillan@cambridge.com
Cambridge Research Associates    Ministry of Silly Walks
1430 Spring Hill Road, Ste. 200  Voice: (703) 790-0505 x7235
McLean, VA 22102                 Fax:   (703) 790-0370
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 10:23:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA23659 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 10:14:20 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA23632 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 10:14:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA17561408
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 10:14:18 -0700 (PDT)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA28846
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 10:14:15 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from sutcliffe.bgm.link.com (sutcliffe.bgm.link.com [130.210.236.18])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id MAA24919; Tue, 28 Apr 1998 12:14:10 -0500 (CDT)
Date: Tue, 28 Apr 1998 12:12:56 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: David Chan <dchan@zeus.lnk.com>
cc: Performer mailling list <info-performer@sgi.com>
Subject: Re: pfMalloc & object container
In-Reply-To: <Pine.SUN.3.95.980428100949.2425D-100000@zeus.lnk.com>
Message-ID: <Pine.SGI.3.96.980428120106.2824B-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Tue, 28 Apr 1998, David Chan wrote:

> HI,
> 	I have a problem with pfMalloc when I am using pfMalloc to create
> a shared memory. Here is my simple code:
> 
> 	shared=(SharedData *)pfMalloc(sizeof(SharedData),
> pfGetSharedArena());
> 
> while SharedData is a typedef structure, and inside SharedData, there is a
> Class container:
> 
> 	typedef structure {
> 		....
> 		Console *console[10];
> 		....
> 	} SharedData;
 
When you are using C++, it is inadvisable to use any variety of malloc/amalloc/pfMalloc
since those functions only allocate memory - they know nothing of calling the
all-important C++ constructor functions.

One solution (the one I like best) is for structures/classes that ALWAYS need to
be in shared memory, I declare:

  class SharedMemory
  {
  public:

    void *operator new ( size_t x ) ;
    {
      return pfCalloc ( 1, x, pfGetSharedArena () ) ;
    }

    void operator delete ( void *p ) ;
    {
      if ( p != NULL )
	pfFree ( p ) ;
    }
  } ;


...then all classes that need to be in shared memory can be derived from
this base class and you can forget about pfMalloc and pfFree and just
use 'new' and 'delete' as nature intended.

  class MyClass : public SharedMemory
  {
    ...stuff...
  } ;

  MyClass *my_object = new MyClass ;  /* pfCalloc called automagically! */

There are other ways to do it - but this is my favorite.

Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 10:21:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA23603 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 10:07:22 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA23576 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 10:07:20 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA17635098
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 10:07:20 -0700 (PDT)
Received: from challenge (challenge.silicon.cl [200.29.42.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id KAA26062
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 10:07:14 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Tue, 28 Apr 1998 14:06:40 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma012128; Tue, 28 Apr 98 14:06:32 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA26090; Tue, 28 Apr 1998 13:11:41 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA11158; Tue, 28 Apr 1998 13:20:55 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9804281320.ZM11156@krusty>
Date: Tue, 28 Apr 1998 13:20:55 -0400
In-Reply-To: David Chan <dchan@zeus.lnk.com>
        "more detail about pfMalloc & object container" (Apr 28, 12:33pm)
References: <Pine.SUN.3.95.980428122044.2739C-100000@zeus.lnk.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: David Chan <dchan@zeus.lnk.com>
Subject: Re: more detail about pfMalloc & object container
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 28, 12:33pm, David Chan wrote:
> Subject: more detail about pfMalloc & object container
> HI,
> 	As the problem describe in my first mail, I want to add more
> detail describtion:
> 	the abstract class "Console" is derived from "pfObject".
> 	Since "Console" is abstract class, so it can't be like this:
>
> 	typedef structure {
> 		...
> 		Console console[10];
> 		...
> 	} SharedData;
>
>
> 	And also I try to print out the address of shared->console[0], it
> is 0, and it seems I can't assign the address of new object into the
> array. I do it like this:
>
>         typedef structure {
>                 ...
>                 Console *console[10];
>                 ...
>         } SharedData;
>
> 	SharedData *shared = (SharedData *)pfMalloc(sizeof(SharedData),
> pfGetSharedArena());
> 	shared->console[0] = new Dervid_class_from_Console(parm1,parm2);
>
> 	Then there is segnmentation fault when I try to access object
> inside the array.
> 	And I can't use "CC" to link object program, because one of my
> program is c program, the others are c++ program with C performer API.
>
> Thanks in advance.
> David Chan
>
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>
>-- End of excerpt from David Chan
mmh, strange, are you sure you are getting an instance of the class when doing
the new Dervid_class_from_Console(parm1,parm2)? Try, using an aux pointer
holding new's return value, and check is valid. This shouldn't be the problem
but just to eliminate the posibility.


-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Andres Bello 2777, Of. 602
E-mail: asaez@silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 105       Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 10:21:06 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA23527 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 10:02:08 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA23500 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 10:02:05 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA17632523
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 10:02:05 -0700 (PDT)
Received: from challenge (challenge.silicon.cl [200.29.42.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id KAA23550; Tue, 28 Apr 1998 10:01:56 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Tue, 28 Apr 1998 14:01:35 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma012092; Tue, 28 Apr 98 14:01:05 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA26070; Tue, 28 Apr 1998 13:06:13 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA11149; Tue, 28 Apr 1998 13:15:26 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9804281315.ZM11147@krusty>
Date: Tue, 28 Apr 1998 13:15:25 -0400
In-Reply-To: tzelin@nuno.singapore.sgi.com (Ong Tze Lin)
        "Extracting terrain data from dxf" (Apr 28,  8:34am)
References: <199804281534.IAA08013@nuno.singapore.sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: tzelin@nuno.singapore.sgi.com (Ong Tze Lin)
Subject: Re: Extracting terrain data from dxf
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 28,  8:34am, Ong Tze Lin wrote:
> Subject: Extracting terrain data from dxf
> Hi all,
>
> I'm wondering how to get Dted or other terrain info
> out of a dxf file containing contour lines.
>
> Is there any software out there that will do that?
> Right now I'm faced with having to translate
> the data into inventor, and sampling the points
> in the data field at appropriate intervals to construct
> my own ded file.
>
> Also I'm looking into shading the contour intervals
> and using the MultiGen utility image2ded to get
> a terrain mesh.
>
> But if there are any tools out there which will make
> my life easier, I'll use them!
>
> Thanks,
>
> Cheers,
> tzelin
>
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>
>-- End of excerpt from Ong Tze Lin

Both tasks can be done with an GIS software. Some GIS (arc-info being one of
them, I think, I'm not sure) can read dxf vector data and write DFAD culture
data. Also, most vector/raster GISs can generate an image DEM file from contour
maps (TNT mips is one of them, I've tried it). The problem is that by
generating an image file you loose geographic location information.

	Hope this helps

-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Andres Bello 2777, Of. 602
E-mail: asaez@silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 105       Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 11:00:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA24100 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 10:47:29 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA24071 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 10:47:24 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA17636896
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 10:47:23 -0700 (PDT)
Received: from ait.nrl.navy.mil (ait.nrl.navy.mil [132.250.128.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA13650
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 10:47:22 -0700 (PDT)
	mail_from (ekuo@ait.nrl.navy.mil)
Received: from fargo.ait.nrl.navy.mil (fargo [132.250.128.95])
	by ait.nrl.navy.mil (8.8.8/8.8.8) with SMTP id NAA03998
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 13:47:20 -0400 (EDT)
Date: Tue, 28 Apr 1998 13:47:20 -0400 (EDT)
From: Eddy Kuo <ekuo@ait.nrl.navy.mil>
To: info-performer@sgi.com
Subject: a geoset question
Message-ID: <Pine.SGI.3.91.980428134410.8848A-100000@fargo.ait.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello:

I am trying to create a geoset with changing geometry.
I am dealing with mostly triangle strips, and I have it working
only when number of primitives = 1, and it doesn't work when
I try to include more than one primitives in one geoset.
I used pfFlux to handle normals, coord, length, and color.

thanks in advance for any advice.

Ed.

-------------------------------------------------------------------
Eddy Kuo 		      		work phone: 202-767-6025 
Virtual Reality Lab 			home phone: 703-893-2553
Naval Research Lab		http://www.cis.ohio-state.edu/~ekuo
-------------------------------------------------------------------

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 11:18:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA24318 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 11:11:10 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA24291 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 11:11:09 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA17555658
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 11:11:09 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA24816
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 11:11:07 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id LAA28136 for <info-performer@sgi.com>; Tue, 28 Apr 1998 11:22:03 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id SAA26329 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Tue, 28 Apr 1998 18:12:10 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA04762 for info-performer@sgi.com; Tue, 28 Apr 1998 11:12:09 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804281112.ZM4760@logan.engr.multigen.com>
Date: Tue, 28 Apr 1998 11:12:09 -0700
In-Reply-To: David Chan <dchan@zeus.lnk.com>
        "more detail about pfMalloc & object container" (Apr 28, 12:33pm)
References: <Pine.SUN.3.95.980428122044.2739C-100000@zeus.lnk.com>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Performer mailling list <info-performer@sgi.com>
Subject: Re: more detail about pfMalloc & object container
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 28, 12:33pm, David Chan wrote:
>And also I try to print out the address of shared->console[0], it
>is 0 ...

You need to be a bit more precise here. You are interested in the the value of
shared->console[0] not its address. Its address can only be 0 if you failed to
allocate SharedData to begin with and it is the first data member.

shared->console[0] = new DerivedConsole;
printf( "%p", shared->console[0] ); // address of DerivedConsole object

NOTE: You cannot use iostream's unless you link with CC.

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 11:18:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA24238 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 11:04:19 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA24211 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 11:04:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA17674604
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 11:04:17 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA21271
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 11:04:16 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id LAA28091 for <info-performer@sgi.com>; Tue, 28 Apr 1998 11:15:06 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id SAA26243 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Tue, 28 Apr 1998 18:05:12 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA04745 for info-performer@sgi.com; Tue, 28 Apr 1998 11:05:12 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804281105.ZM4743@logan.engr.multigen.com>
Date: Tue, 28 Apr 1998 11:05:11 -0700
In-Reply-To: David Chan <dchan@zeus.lnk.com>
        "more detail about pfMalloc & object container" (Apr 28, 12:33pm)
References: <Pine.SUN.3.95.980428122044.2739C-100000@zeus.lnk.com>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Performer mailling list <info-performer@sgi.com>
Subject: Re: more detail about pfMalloc & object container
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 28, 12:33pm, David Chan wrote:
>Then there is segnmentation fault when I try to access object
>inside the array.

Can you access your object outside the array? It's possible you didn't
Console::Console() and/or Console::operator new() correctly.

>And I can't use "CC" to link object program, because one of my
>program is c program, the others are c++ program with C performer API.

Yes you can. Compiling and linking are separate steps.

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 11:45:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA24604 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 11:33:53 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA24577 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 11:33:45 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA17742694
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 11:33:45 -0700 (PDT)
Received: from cs.nps.navy.mil (cs.nps.navy.mil [131.120.1.13]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA04871
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 11:33:39 -0700 (PDT)
	mail_from (howard@cs.nps.navy.mil)
Received: from radical.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1)
	id AA11640; Tue, 28 Apr 98 11:29:35 PDT
Sender: howard@cs.nps.navy.mil
Message-Id: <3546200E.3D032532@cs.nps.navy.mil>
Date: Tue, 28 Apr 1998 11:29:34 -0700
From: Howard Abrams <howard@cs.nps.navy.mil>
X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX64 6.2 IP28)
Mime-Version: 1.0
To: "Page, Andrew" <page@ex.cv.hp.com>
Cc: info-performer@sgi.com
Subject: Re: OpenGL++ -> Fahrenheit (was Performer at ITEC)
References: <6A3EBCD1D1C7D111931C0060B068F27A14AE77@cvex01.cv.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Page, Andrew wrote:
> 
> [snip]
> 
> We would like to reaffirm this point. Microsoft, SGI and HP are working
> hard to bring all of you a ubiquitous API. Fahrenheit is a toolkit that
> goes beyond the scope of any yet produced. This is a toolkit that
> reaches from the low-level APIs up to Scene Graph management and
> optimization. There is also ability for ISVs and IHVs to extend and
> enhance the toolkit; something new that will definitely move the
> industry forward. HP too will only participate in one effort and
> Fahrenheit is that effort. When the higher level components of
> Fahrenheit are released later this year on HP-UX, IRIX and MS Windows
> platforms application developers will have a great toolkit to work with
> on the worlds leading graphics platforms..
> 

I am still unclear on 2 points? Will Fahrenheit be an open standard?
Will it be part of the ARB?

What about platforms such as Mac, Linux, or my platform of choice BeOS? 

Yours,

  Howard

--
Howard Abrams
howard@cs.nps.navy.mil
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 12:52:16 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA24956 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 12:49:44 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA24929 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 12:49:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA16785226
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 12:49:42 -0700 (PDT)
Received: from mail.inreach.com ([209.142.0.209]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA04827; Tue, 28 Apr 1998 12:49:40 -0700 (PDT)
	mail_from (lwillis@inreach.com)
Received: from get (209-142-17-149.oak.inreach.net [209.142.17.149]) by mail.inreach.com (8.8.8/8.8.6/(InReach)) with ESMTP id MAA11180; Tue, 28 Apr 1998 12:44:58 -0700 (PDT)
Message-Id: <199804281944.MAA11180@mail.inreach.com>
Reply-To: <lwillis@inreach.com>
From: "Lee Willis" <lwillis@inreach.com>
To: "Ong Tze Lin" <tzelin@nuno.singapore.sgi.com>
Cc: <info-performer@sgi.com>
Subject: Re: Extracting terrain data from dxf
Date: Tue, 28 Apr 1998 12:44:54 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1162
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Status: O

If you want a role-your-own solution,  *and* you have a decent TIN library:

1) Define the contours as edges in the TIN.
2) Tesselate the TIN
3) Interpolate the TIN back into a DEM.

There are a number of freely distributable TIN libraries on the net.  See

	http://www.cs.cmu.edu/~garland/multires/software.html

for some of them.  (Not everything listed there is suitable)

(Any good vector GIS should also be able to do this)

------------------------------
Lee Willis                        Virtual Landscape Dermatologist          
      
lwillis@terrex.com           TERREX

----------
> From: Ong Tze Lin <tzelin@nuno.singapore.sgi.com>
> To: info-performer@sgi.com
> Subject: Extracting terrain data from dxf
> Date: Tuesday, April 28, 1998 8:34 AM
> 
> Hi all,
> 
> I'm wondering how to get Dted or other terrain info
> out of a dxf file containing contour lines.
> 
> Is there any software out there that will do that?
> Right now I'm faced with having to translate
> the data into inventor, and sampling the points
> in the data field at appropriate intervals to construct
> my own ded file.
> 
> Also I'm looking into shading the contour intervals
> and using the MultiGen utility image2ded to get
> a terrain mesh.
> 
> But if there are any tools out there which will make
> my life easier, I'll use them!
> 
> Thanks,
> 
> Cheers,
> tzelin
>  
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 14:52:01 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA25249 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 14:36:08 -0700
Return-Path: <guest>
Received: from puget.engr.sgi.com (puget.engr.sgi.com [150.166.37.90]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA25222 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 14:36:03 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) via ESMTP id OAA34266 for <info-performer@puget.engr.sgi.com>; Tue, 28 Apr 1998 14:36:00 -0700 (PDT)
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA17783777
	for <info-performer@puget.engr.sgi.com>;
	Tue, 28 Apr 1998 14:35:58 -0700 (PDT)
Received: from mail.multigen.com (mail.multigen.com [206.184.173.230]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id OAA17960
	for <info-performer@puget.engr.sgi.com>; Tue, 28 Apr 1998 14:35:57 -0700 (PDT)
	mail_from (marcus@logan.engr.multigen.com)
Received: from plateau.engr.multigen.com (plateau.engr.multigen.com [209.24.52.10]) by mail.multigen.com (8.6.11/8.6.12) with ESMTP id OAA29622 for <info-performer@puget.engr.sgi.com>; Tue, 28 Apr 1998 14:46:52 -0700
Received: from logan.engr.multigen.com (logan.engr.multigen.com [209.24.52.77]) by plateau.engr.multigen.com (8.6.11/8.6.12) with ESMTP id VAA01382 for <@plateau.engr.multigen.com:info-performer@puget.engr.sgi.com>; Tue, 28 Apr 1998 21:36:59 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA05158 for info-performer@puget.engr.sgi.com; Tue, 28 Apr 1998 14:36:58 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9804281436.ZM5156@logan.engr.multigen.com>
Date: Tue, 28 Apr 1998 14:36:57 -0700
In-Reply-To: Jay Gischer <gischer@puget.engr.sgi.com>
        "pfMalloc & object container" (Apr 28,  9:05am)
References: <Pine.SUN.3.95.980428100949.2425D-100000@zeus.lnk.com> 
	<199804281605.JAA12539@puget.engr.sgi.com>
Organization: MultiGen Inc.
X-Phones: 1-408-556-2654
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@puget.engr.sgi.com
Subject: Re: pfMalloc & object container
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 28,  9:05am, Jay Gischer wrote:
>David Chan writes:
>
>I don't think that pointers work too well with shared memory here.

Pointers work fine ... as long as they point to other pieces of shared memory.

>If the Console's were allocated from shared memory, their addresses
>will possibly change from process to process.  If they weren't the
>memory won't even be there in a different process.

It's generally bad to map a shared memory arena to different base addresses in
cooperating processes. Make sure to create all your shared memory arenas prior
to pfConfig() or fork().

For C++, it is also bad to map a C++ DSO to different addresses because then
those object's vptrs will not be valid between processes [SIGILL typically].
This means that if you use dlopen() to dynamically load a C++ DSO, you must do
it before pfConfig() as well.

>If in fact the Console structures are to be shared, it would be better
>to do:
>
>   typedef structure {
>	   ...
>	   Console console[10];
>	   ...
>   } SharedData;
>
>   and then
>
>   SharedData *sd =
(SharedData*)pfMalloc(sizeof(SharedData),pfGetSharedArena);
>   sd->console[0] = *new Console(whatever);

This is _not_ a good way to create objects! This invokes the copy constructor
on a temporary object. The object created by the new expression is a memory
leak!

>// This way the console data is sure to be in shared memory too.

No, no, no! The temporary object is _not_ going to be in shared memory.

Regards.
--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Tue Apr 28 16:28:02 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA25607 for info-performer-dist@holodeck.engr.sgi.com; Tue, 28 Apr 1998 16:11:33 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA25580 for <info-performer@holodeck.engr.sgi.com>; Tue, 28 Apr 1998 16:11:31 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA16898282
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 28 Apr 1998 16:11:30 -0700 (PDT)
Received: from silver.anu.edu.au (silver.anu.edu.au [150.203.162.26]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id QAA27164
	for <info-performer@sgi.com>; Tue, 28 Apr 1998 16:11:27 -0700 (PDT)
	mail_from (bcorrie@silver.anu.edu.au)
Received: from silver (bcorrie@localhost [127.0.0.1]) by silver.anu.edu.au (8.8.2/8.8.2) with ESMTP id JAA05437; Wed, 29 Apr 1998 09:01:17 +1000 (EST)
Message-Id: <199804282301.JAA05437@silver.anu.edu.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: "Page, Andrew" <page@ex.cv.hp.com>
cc: info-performer@sgi.com, bcorrie@silver.anu.edu.au
Subject: Re: OpenGL++ -> Fahrenheit (was Performer at ITEC) 
In-reply-to: Your message of "Tue, 28 Apr 1998 09:26:34 MST."
             <6A3EBCD1D1C7D111931C0060B068F27A14AE77@cvex01.cv.hp.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 29 Apr 1998 09:01:16 +1000
From: Brian Corrie <bcorrie@cs.anu.edu.au>
Status: O


Before I add a few comments, I just wanted to say thanks to Sharon, Angus, and 
Andrew (and others) who have commented on what is going on with Fahrenheit 
etc. It has been extremely helpful.

Sharon says:
>The most detailed we ever got was in summer '97 hoping for a Beta in
>summer '98. As we mentioned then, that was a very tentative outlook
>because we were (and are) talking about a 1.0 type of release here.
>The schedule at this point probably is not all that different than it
>otherwise would have been.  As announced at the Fahrenheit launch, we
>are trying for a released product mid-98. ...

I assume you mean mid-99 here...

Andrew says:
>As one of the development partners of Fahrenheit we at HP we feel that
>we should chime in on these discussions. There have been many questions
>flying around and Angus and Sharon have done a great job answering them.
>We want to just add a few points.
>
>Sharon writes in her very concise summary of the OGL++ questions and
>comments, 
>
>"In truth, I don't think that last Dec. spec would provide much
>insight for folks that have seen Performer and Inventor beyond
>reassuring folks that we are still doing a Scene Graph.  Since the
>goal here is a pervasive standard, I'd hope that folks would use
>Fahrenheit and not try to start up a separate effort now on something
>old.  SGI will only participate in one effort and honestly believe
>what we have created with Fahrenheit is the right thing, both for ISV
>and IHVs that want to be able to differentiate on top of and
>underneath a ubiquitous API.  I don't think multiple efforts is going
>to help anyone at this point." 
>
>We would like to reaffirm this point. Microsoft, SGI and HP are working
>hard to bring all of you a ubiquitous API. Fahrenheit is a toolkit that
>goes beyond the scope of any yet produced. This is a toolkit that
>reaches from the low-level APIs up to Scene Graph management and
>optimization. There is also ability for ISVs and IHVs to extend and
>enhance the toolkit; something new that will definitely move the
>industry forward. HP too will only participate in one effort and
>Fahrenheit is that effort. When the higher level components of
>Fahrenheit are released later this year on HP-UX, IRIX and MS Windows
>platforms application developers will have a great toolkit to work with
>on the worlds leading graphics platforms.. 

Unless I am mistaken, I don't think that anyone is necessarily suggesting that 
an alternative scene graph API be implemented. I would assume that any Mesa 
like scene graph implementation (lets call it Celsius or Centigrade for 
obvious reasons 8-) would initially be based on an OpenGL++ spec because that 
is all we have that is "close" to what FSG might look like in the future. I 
would hope that as Celsius Scene Graph (CSG - hmmm, could cause confusion 
here... I love acronyms 8-) matures and more information about FSG becomes 
available CSG would try to approach FSG in functionality much like Mesa 
implements OpenGL's functionality. Thus we would still have the ubiquitous API 
but it would be available on a much wider range of platforms (Linux, Mac, BeOS 
etc.). An admirable goal in my mind.

Just my $0.02 worth. 

Cheers,

	Brian



=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 29 07:38:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA26597 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 07:15:49 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA26570 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 07:15:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA18036996
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 07:15:42 -0700 (PDT)
Received: from attach1.rocketmail.com (attach1.rocketmail.com [205.180.57.81]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA24243
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 07:15:40 -0700 (PDT)
	mail_from (joaquim@rocketmail.com)
Message-ID: <19980429141216.21155.rocketmail@attach1.rocketmail.com>
Received: from [194.65.233.42] by attach1; Wed, 29 Apr 1998 07:12:16 PDT
Date: Wed, 29 Apr 1998 07:12:16 -0700 (PDT)
From: Joaquim Muchaxo <joaquim@rocketmail.com>
Reply-To: joaquim@imersiva.ch
Subject: Re: Extracting terrain data from dxf
To: Ong Tze Lin <tzelin@nuno.singapore.sgi.com>
Cc: info-performer@sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi,
Imersiva has a tool to generate a "raw" matrix of altimetry
from DXF or xyz into either byte, integer or float, (Intel
or SGI formats)

ALso, we have a tool - SkeleTIN - that generates highly
optimized
TIN with LODs, gouraud, texture mapping and texture 
tiling. 

Both programs run on NT or IRIX and are still on evaluation
process.
Take a look at http://www.imersiva.ch

Regards,


===
Joaquim Muchaxo                                      
ph:+(351-1)8318237             
mobile:+(351+1)/(0)931-272387     
-------------------------------------------------------------
IMERSIVA - Multimedia, Virtual Reality & Geograph. Info.
Sys.
http://www.imersiva.ch               
mailto:info@imersiva.ch





---Ong Tze Lin <tzelin@nuno.singapore.sgi.com> wrote:
>
> Hi all,
> 
> I'm wondering how to get Dted or other terrain info
> out of a dxf file containing contour lines.
> 
> Is there any software out there that will do that?
> Right now I'm faced with having to translate
> the data into inventor, and sampling the points
> in the data field at appropriate intervals to construct
> my own ded file.
> 
> Also I'm looking into shading the contour intervals
> and using the MultiGen utility image2ded to get
> a terrain mesh.
> 
> But if there are any tools out there which will make
> my life easier, I'll use them!
> 
> Thanks,
> 
> Cheers,
> tzelin
>  
>
=======================================================================
> List Archives, FAQ, FTP: 
http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 29 09:16:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA26972 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 09:06:42 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA26945 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 09:06:41 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA17790913
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 09:06:40 -0700 (PDT)
Received: from challenge (challenge.silicon.cl [200.29.42.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA03847
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 09:06:29 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Wed, 29 Apr 1998 13:05:41 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma017907; Wed, 29 Apr 98 13:05:39 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12534; Wed, 29 Apr 1998 12:11:00 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA12044; Wed, 29 Apr 1998 12:20:01 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9804291220.ZM12038@krusty>
Date: Wed, 29 Apr 1998 12:20:00 -0400
In-Reply-To: =?iso-8859-1?Q?Jim_Tsai_=3Cjimtsai=40cradle=2Ecom=2Etw=3E
 _______=22=A6^=C2=D0_=3A_ghost_polygons=22_=28Jan_10=2C__9=3A51am=29?=
References: <01BD1DAD.536975D0@MIMIC>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Jim Tsai <jimtsai@cradle.com.tw>
Subject: =?iso-8859-1?Q?Re=3A_=A6^=C2=D0_=3A_ghost_polygons?=
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.19804291220.ZM12038.krusty"
Status: O


--PART-BOUNDARY=.19804291220.ZM12038.krusty
Content-Description: Text
Content-Type: text/plain ; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Zm-Decoding-Hint: mimencode -q -u 

On Jan 10,  9:51am, Jim Tsai wrote:
> Subject: =A6^=C2=D0 : ghost polygons
>
> Could it be a Z buffer resolution problem??? Make sure you have enough =
Z bits
> and that the far/near plane ratio doesn't exceed around 10000. Differen=
t
> programs might have different default settings, thus triggering the eff=
ect.
>
> []  Dear  Saez:
> 	Would you mind telling me why the far/near ratio cannot exceed 10000?
>
> Thanks
> Jim Tsai
>-- End of excerpt from Jim Tsai

Jim,
	Sure, no sweat. I don't know if you know how Z buffer works, so here is
a small explanation. Z buffer is used to determine which primitives oclud=
e
other primitives. For each pixel in the frame buffer, there is a correspo=
nding
"point" in the Z buffer, this point holds distance information. Each time=
 a
pixel corresponding to a primitive (i.e, triangle) is to be drawn, it is =
first
check against the Z buffer. If a pixel was te be drawn at coordinates 10,=
15 in
the frame buffer, and say this point is a 100 meters away from the observ=
er,
then the system checks what's the distance stored in the frame buffer, if=
 this
distance is less than 100, then the new pixel is not drawn, because some =
other
pixel has been drawn before which is closer to the observer than the new =
pixel,
thus ocluding it. If the distance stored in the Z buffer is greater than =
100,
then the pixel is drawn because the previously drawn pixel is further awa=
y from
the observer, at the same time, the Z buffer distance for that coordinate=
 is
updated to 100 meters. The thing goes on until the whole scene has been d=
rawn,
and occasionaly during this process another primitive will try to project=
 a
pixel in the same coordinate, an again the Z buffer is checked, and if th=
is
other pixel is closer than 100 meters, both frame and Z buffer are again
updated. During the screen refresh, the frame buffer is initialized to
background color and the Z buffer is initialized so that each point in it=
, is
holding infinite distance.

	Now, how does is this distance information stored in the Z buffer. Well
it is coded as integer numbers in a logarithmic scale. Why?? Because if i=
t
wasn't a log scale then you would have a too small range, and what's wors=
t, two
points a couple of inches apar but close to the observer would probably g=
et the
same resolution  ( say 2 bits) as two points that are 100 meters aparts b=
ut are
far from the observer. By using the log scale, you get a lot of bits to
differentiate points that are close to the observer, and get continuosly =
less
bits for points far away from him. Now since objects close to the observe=
r
should have greater detail, smaller and closer polyigons than objects in =
a low
LOD sitting far appart, this should work, shouldn't it? Well, not always.=
 This
is still a discreet scale, meaning that two objects sitting close  (by "c=
lose"
I don't necessarily mean fisically close, but ones whose distances map to=
 close
points in the log scale), but that are not in the same point could end up=
 in
the Z buffer as being in the same fisical point due to round-off and
dicretizarion errors. What's worst  during one frame one point belonging =
to a
primitive could appear to be closer than other point belonging to another=

primitive, and since this is a discretization error, during the next fram=
e,
where the observer and/or objects have move a bit, the situation reverses=
, and
then again. The effect would be pixels of both primitives fighting to get=

displayed in the screen, which resembles a bit of your description of "gh=
ost
polygons".

	How can this be solved, two ways:

	a) Get a visual (or a machine) with more Z bits, this increasing the
accuracy of the Z buffer. Since you said you were displaying in quad-buff=
 mode
or something, then probably some bits previously used as Z buffer bits, a=
re
being used in the frame buffers.
	b) The log scale is not fixed, it depends on the far/near plane. This
is obvious, when you think about it. If you are using (as an example)  24=
 bits
of Z buffer (that is 16 million diferent "distances" can be told appart) =
and
you have a near plane of 1 and a far plane of 100000000, the Z buffer has=
 to
use those 16 million combinations to represente all dsitances from 1 to
100000000. If as I said, a lot of those bits are used for near objects, t=
hen at
the end of the scale, two objects that are 200 meters appart won't be rea=
lly
appart for the Z buffer, they will map to the same discreet distance. Thi=
s is
specially true when having detailed objects for away (another reason to u=
se
LODs). So what's the solution, change one of the planes, if you are flyin=
g up
high, then it could be a good idea to increase the near plane. If on the
contrary you are in a driving simulation, then bringing the far plane dow=
n is
the way to go (of course you can do both). The question is :How much? Wel=
l the
usually given recepy is that the far/near ratio should be arround 1000, b=
ut if
think this is too strict and as I said it depends on the number of Z bits=

available, the kind of simulation (air, ground) and the complexity of the=

scene. I can usualy get away with 10000 for fairly complex ground simulat=
ions.

	Oops, this is way longer than it should've, but it's already done, so
good luck

-- =

------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Andres Bello 2777, Of. 602
E-mail: asaez@silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 105       Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------

--PART-BOUNDARY=.19804291220.ZM12038.krusty--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 29 09:16:32 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA26942 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 09:02:15 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA26915 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 09:02:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA15913107
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 09:02:13 -0700 (PDT)
Received: from zeus.lnk.com (zeus.lnk.com [198.116.32.11]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA01918
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 09:02:11 -0700 (PDT)
	mail_from (dchan@zeus.lnk.com)
Received: from localhost by zeus.lnk.com (4.1/1.35)
	id AA06433; Wed, 29 Apr 98 12:02:09 EDT
Date: Wed, 29 Apr 1998 12:02:08 -0400 (EDT)
From: David Chan <dchan@zeus.lnk.com>
To: Performer mailling list <info-performer@sgi.com>
Subject: more more details
Message-Id: <Pine.SUN.3.95.980429114346.5807C-100000@zeus.lnk.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

HI,
	I am sorry to mislead the problem about pfMalloc and object
container to assigning object to object container. Since I have try to do
like this, actually I can assign object into object container, but the
problem is I can't access the data filed of this object. Here is the whole
story:
===================================================

class Console: public pfObject {
	
protected: int dummy;
	
public:	
	int getDummy() { dummy = 2; return dummy; }
	int getOne() { return 1; }
	virtual void interaction()=0;
}

class Dervied_from_Console : public Console
{
	...
public: virtual void interaction() { ... }
	...
}

typedef structure {
	...
	Console *console[10];
	...
} SharedData;

SharedData *shared = pfMalloc(sizeof(SharedData),pfGetSharedArena());

shared->console[0] = new Dervied_from_Console();

printf("first try: %d\n",shared->console[0]->getOne()); // this statement is ok

printf("second try: %d\n",shared->console[0]->getDummy()); //Segnmentation fault

======================================================

I do the allocation of shared memory before pfConfig(), and I have try to
use malloc() to allocate memory in non-performer appilication. In that
case, both "printf" work fine. 

Any comments are welcome.
David Chan

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 29 10:08:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA27276 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 09:54:31 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA27249 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 09:54:29 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA18013027
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 09:54:28 -0700 (PDT)
Received: from post.mail.demon.net (post-10.mail.demon.net [194.217.242.39]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA23289
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 09:54:21 -0700 (PDT)
	mail_from (gordon@apollo13.demon.co.uk)
Received: from apollo13.demon.co.uk ([158.152.181.251]) by post.mail.demon.net
           id aa1028977; 29 Apr 98 16:48 GMT
From: Gordon Tomlinson <gordon@apollo13.demon.co.uk>
To: Mario Veraart <rioj7@fel.tno.nl>
Cc: Performer <info-performer@sgi.com>,
        Mario Veraart <rioj7@s00sn1.fel.tno.nl>
Subject: Re: Shadow problems on RE2 with IRISGL
Date: Wed, 29 Apr 1998 16:48:28 GMT
Reply-To: gordon@apollo13.demon.co.uk
Message-ID: <35495945.184433421@post.demon.co.uk>
References: <199804271828.UAA17010@s00sn1.fel.tno.nl>
In-Reply-To: <199804271828.UAA17010@s00sn1.fel.tno.nl>
X-Mailer: Forte Agent 1.5/32.450
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Status: O

Hi Mario


Try running your program in Single processor mode
and see if it works, is it does then it is the may be the=20
bug in performer that screws Projects lights.
( Should be fixed in PF2.2 was still broken in P2.1)


TTFN

Gordon.



On Mon, 27 Apr 1998 20:28:03 +0200 (MET DST), you wrote:

>Hello pfUsers,
>
>I try to get shadows with Iris Performer 2.0 on an Onyx Re2 with
>IRISGL.
>
>I have used shadows.c as a start but has found that there are a few
>problems. I have made a terrain with a couple of cubes on it.=20
>
>You can find this text with a couple of pictures at the following URL
>
>http://vtd.fel.tno.nl/~fveraart/shadow/problem.html
>
>In the following pictures the small green cube is the position of the
>lightsource.
>On the terrrain are a few large red cubes with a small green cube next
>to it. The large terrain square is 80x80 meters and I have used a shadow=
 map
>size of 512 pixels.
>
>1)
>For a setting off the light I see that the small green cubes don't
>cast any shadow.
>
>2)
>Depending on the distance of the large cube to the light the geometry
>that is in shadow
>is further away from the object. All of the small green cubes should
>be in shadow.
>
>3)
>The objects that are in shadow are not lit with the ambient lighting
>term. They are drawn black.
>
>4)
>The back side of the cubes are not in shadow.
>
>If anyone can help me solve these problems?
>
>Mario Veraart
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>            Submissions:  info-performer@sgi.com
>        Admin. requests:  info-performer-request@sgi.com

Gordon Tomlinson   =20
System Manager
PERA VR
Technology Centre
Nottingham Road
Melton Mowbray
Leicestershire
LE13 0PB
U.K.
***************************************************************
Tel:	01664 501 501=20
=46ax:	01664 501 553
Email: 	gordon@apollo13.demon.co.uk
Email: 	gordon_tomlinson@peragroup.com
WWW:	http://www.apollo13.demon.co.uk
***************************************************************
NOTE: ALL views, opinions, Comments etc are solely personal and
DO NOT in any way reflect the opinion or view of my employers=20
***************************************************************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 29 13:38:36 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA27821 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 13:23:03 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA27794 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 13:23:01 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA17241797
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 13:23:01 -0700 (PDT)
Received: from dewey.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA16208
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 13:22:59 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by dewey.fel.tno.nl; id WAA13533; Wed, 29 Apr 1998 22:23:23 +0200
Received: from s00sn1.fel.tno.nl(134.203.8.207) by dewey.fel.tno.nl via smap (4.1)
	id xma013514; Wed, 29 Apr 98 22:22:43 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id WAA04463;
	Wed, 29 Apr 1998 22:21:50 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804292021.WAA04463@s00sn1.fel.tno.nl>
Subject: Re: Shadow problems on RE2 with IRISGL
To: gordon@apollo13.demon.co.uk
Date: Wed, 29 Apr 1998 22:21:50 +0200 (MET DST)
Cc: info-performer@sgi.com (Performer)
In-Reply-To: <35495945.184433421@post.demon.co.uk> from "Gordon Tomlinson" at Apr 29, 98 04:48:28 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> Try running your program in Single processor mode
> and see if it works, is it does then it is the may be the 
> bug in performer that screws Projects lights.
> ( Should be fixed in PF2.2 was still broken in P2.1)

Hi Gordon,

The program is a mix from the complex.c program and the shadows.c program.
I use a pure GL window (disable the PFPW_TYPE_X).
If I try to run in APPCULLDRAW it core dumps in the call XMapWindow.
If I use a mode where DRAW is forked off from APP the program works ok.

Mario
> TTFN
> 
> Gordon.
> 
> On Mon, 27 Apr 1998 20:28:03 +0200 (MET DST), you wrote:
> 
> >Hello pfUsers,
> >
> >I try to get shadows with Iris Performer 2.0 on an Onyx Re2 with
> >IRISGL.
> >
> >I have used shadows.c as a start but has found that there are a few
> >problems. I have made a terrain with a couple of cubes on it. 
> >
> >You can find this text with a couple of pictures at the following URL
> >
> >http://vtd.fel.tno.nl/~fveraart/shadow/problem.html
> >
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 29 13:52:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA27886 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 13:40:11 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA27859 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 13:40:09 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA17178556
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 13:40:09 -0700 (PDT)
Received: from perdy.mdcorp.ksc.nasa.gov (perdy.ksc.nasa.gov [163.205.180.226]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA23437
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 13:40:06 -0700 (PDT)
	mail_from (flynnt@perdy.mdcorp.ksc.nasa.gov)
Received: (from flynnt@localhost) by perdy.mdcorp.ksc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA00039 for info-performer@sgi.com; Tue, 28 Apr 1998 17:39:37 -0400
From: "Tom Flynn" <flynnt@perdy.mdcorp.ksc.nasa.gov>
Message-Id: <9804281739.ZM37@perdy.mdcorp.ksc.nasa.gov>
Date: Tue, 28 Apr 1998 17:39:37 -0400
In-Reply-To: Steve Baker <sbaker@link.com>
        "Re: Performer at ITEC" (Apr 23,  8:39am)
References: <Pine.SGI.3.96.980423083345.6888B-100000@sutcliffe.bgm.link.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Re: Performer at ITEC
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 23,  8:39am, Steve Baker wrote:
> Subject: Re: Performer at ITEC
> On Thu, 23 Apr 1998, Brian Corrie wrote:
>
> > We were hoping to see an initial
> > release of OpenGL++ in the next couple of months, but according to the
OpenGL
> > ARB meeting minutes from March 9-10
> >
> > (http://www.opengl.org/ARB/Notes/Meeting1.2/meeting_note_10-03-98.html)
> >
> > Kurt Akeley (at least so the minutes say, I wasn't there...) says that "SGI
> > will no longer be able to push OpenGL++ (though they have no objection to
> > others picking up the work). Resources are committed to work with Microsoft
> > and HP on the scene graph and large model visualization APIs." Does this
mean
> > that we will be waiting for the Fahrenheit scene graph as opposed to
OpenGL++?
>
> I wonder if anyone would be interested in a cooperative 'freeware' Mesa++ (ie
> an OpenGL++ implemented on top of Mesa and provided under the same licensing
> conditions)?

How about an open-source (freeware if you insist on calling it that)
implementation of Performer.  This _is_ the Performer mailing list afterall :).
 An open implementation of Performer that's portable to other POSIX complient
operating systems.  That way when managers demand that their engineers port to
the PC, engineers can just re-compile rather than do the absolute complete
re-write of application code that would be necessary to port to Windows NT.
 It's also a more attractive short-term path than re-writing the graphics
portion of the code to Fahrenheit then later re-writing the rest of the
application to run under Windows NT.  Rather than re-writing twice, you just
re-compile once.  And since this would be an open-source solution, someone to
go ahead and make a port of it to Windows NT.  This could be a solution until
and perhaps even after Fahrenheit implementations are available 1-2yrs from now
or whenever it is supposed to be out.

Now a quick question about Fahrenheit:  will Fahrenheit be open,
system-independant and governed by an ARB consisting of industry leaders the
way OpenGL is?  There is a definate need for an open, system-independant,
industry-wide scene graph API that has the same goals of Performer.

Well, that's just some food for thought.  I've gotta go now.  Take note that
this email reflects my opinions and do not necessarily reflect the opinions of
The Boeing Company. (etc. etc. etc. and any other legal disclaimers you can
think of).

later,
tom


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 29 15:49:16 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA28356 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 15:34:02 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA28329 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 15:33:57 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA18227305
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 15:33:55 -0700 (PDT)
Received: from aud.ucla.edu (alberti.aud.ucla.edu [128.97.172.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id PAA13580
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 15:33:54 -0700 (PDT)
	mail_from (friedman@ucla.edu)
Received: from breuer by aud.ucla.edu (SMI-8.6/SMI-SVR4)
	id PAA05083; Wed, 29 Apr 1998 15:34:41 -0700
Sender: scott@ucla.edu
Message-ID: <3547AA8D.41C6@ucla.edu>
Date: Wed, 29 Apr 1998 15:32:45 -0700
From: "Scott A. Friedman" <friedman@ucla.edu>
Organization: UCLA Computer Science
X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX64 6.4 IP30)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Can two processes use the same pfBuffer?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi,

I have two processes that want to use the same pfBuffer.

The pfBuffer is created in the DBASE process and is used there during
pfBufferAddChild and pfBufferRemoveChild calls.  

Another process which was *not* forked from the DBASE selects the
pfBuffer through a shared variable and performs data loading.

The reason I am asking if this is okay is that when I try and delete a
piece of scene graph in the DBASE process Performer crashes.

Thanks for any insight,
Scott
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 29 18:20:47 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA28710 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 18:01:42 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA28683 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 18:01:41 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA15521447
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 18:01:40 -0700 (PDT)
Received: from aimnet.com (shell1.aimnet.com [204.247.0.210]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id SAA03284
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 18:01:39 -0700 (PDT)
	mail_from (kishore@aimnet.com)
Received: (from kishore@localhost)
	by aimnet.com (8.8.8/8.8.6) id RAA23557;
	Wed, 29 Apr 1998 17:59:52 -0700 (PDT)
Date: Wed, 29 Apr 1998 17:59:52 -0700 (PDT)
From: Anita Kishore <kishore@aimnet.com>
Message-Id: <199804300059.RAA23557@aimnet.com>
To: friedman@ucla.edu, info-performer@sgi.com
Subject: Re: Can two processes use the same pfBuffer?
Status: O

Maybe the following might help in deleting and loading another scene
in the DBASE itself:

	after pfBufferRemoveChild, call
	pfAsyncDelete() followed by pfMerge()

The above has worked so far for me in earlier versions of performer,
haven't checked this in the latest version.

-anita
kishore@triavest.com
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Wed Apr 29 22:39:23 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id WAA29112 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 22:18:15 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id WAA29085 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 22:18:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id WAA18421596
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 22:18:13 -0700 (PDT)
Received: from ceres.is.seikei.ac.jp (ceres.is.seikei.ac.jp [133.220.50.72]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id WAA02082
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 22:18:11 -0700 (PDT)
	mail_from (yukari@ceres.is.seikei.ac.jp)
Received: by ceres.is.seikei.ac.jp (1.38.193.4/2.7W)
	id AA26233; Thu, 30 Apr 1998 14:07:58 +0900
Message-Id: <9804300507.AA26233@ceres.is.seikei.ac.jp>
To: info-performer@sgi.com
Subject: discribe
Date: Thu, 30 Apr 1998 14:07:58 +0900
From: Shibuya Yukari <yukari@ceres.is.seikei.ac.jp>
Status: O

please remove me from this ML.

thank you
--
Yukari Shibuya
<yukari@ceres.is.seikei.ac.jp>
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 00:06:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA29337 for info-performer-dist@holodeck.engr.sgi.com; Wed, 29 Apr 1998 23:46:19 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id XAA29310 for <info-performer@holodeck.engr.sgi.com>; Wed, 29 Apr 1998 23:46:17 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA9750214
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 29 Apr 1998 23:46:17 -0700 (PDT)
Received: from relay.eunet.no (relay.eunet.no [193.71.1.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id XAA19787
	for <info-performer@sgi.com>; Wed, 29 Apr 1998 23:46:12 -0700 (PDT)
	mail_from (crccobr@nocrc.abb.no)
Received: from nocrc.abb.no ([193.71.72.10] (may be forged))
	by relay.eunet.no (8.8.6/8.8.5) with SMTP id IAA06740;
	Thu, 30 Apr 1998 08:46:04 +0200 (MDT)
Received: from pc-crccobr ([193.71.72.141]) by nocrc.abb.no (4.1/SMI-4.1)
	id AA15095; Thu, 30 Apr 98 08:42:59 +0100
Message-Id: <35481DE5.71CF@nocrc.abb.no>
Date: Thu, 30 Apr 1998 08:44:53 +0200
From: Dr Colin Bridgewater <crccobr@nocrc.abb.no>
Reply-To: crccobr@nocrc.abb.no
Organization: ABB Teknologi AS, Marine Oil and Gas Group
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: Tom Flynn <flynnt@perdy.mdcorp.ksc.nasa.gov>
Cc: info-performer@sgi.com
Subject: Re: Performer at ITEC
References: <Pine.SGI.3.96.980423083345.6888B-100000@sutcliffe.bgm.link.com> <9804281739.ZM37@perdy.mdcorp.ksc.nasa.gov>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi Tom

Apologies for cluttering up the ether with a lot of quotes, but your
message stands well together.

Tom Flynn wrote:
> How about an open-source (freeware if you insist on calling it that)
> implementation of Performer. 
> 
> An open implementation of Performer that's portable to other POSIX 
> compliant operating systems....

My understanding is that Performer is optimised for SGI hardware. I use
it precisely *because* I don't have to worry too much about making the
most of the underlying hardware. Folks like Sharon and Angus work very
hard to ensure that... There are tricks that have to be made to squeeze
the utmost performance, but most people get by with a single code that
scales to different visuals, multiple processors, graphics board sets
etc etc at a binary level.

> Now a quick question about Fahrenheit:  will Fahrenheit be open,
> system-independant and governed by an ARB consisting of industry 
> leaders the way OpenGL is?  There is a definite need for an open, 
> system-independant, industry-wide scene graph API that has the same 
> goals of Performer.

Well said ! Although, the vendors of World Tool Kit and OpenGVS (to name
but two) might debate with you as the to definition of "open". 

The truth is that there are already APIs which can be used on both SGI
and Wintel platforms. If you want cross-platform compatibility for your
applications, try one of those. But you won't get the same high-end
functionality or performance unless you use a toolkit (in this case,
Performer) that is tuned for use on SGI hardware.

Regards

Colin
_______________________________________________________________________
Dr Colin Bridgewater    crccobr@nocrc.abb.no    Marine Oil and Gas Dept
ABB Teknologi AS, Bergerveien 12, PO Box 91, N-1361 BILLINGSTAD, Norway
work tel: +47 66 84 35 36, fax: +47 66 84 43 90,  home: +44 1189 671713
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 02:42:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA29648 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 02:23:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id CAA29621 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 02:23:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA16474818
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 02:23:35 -0700 (PDT)
Received: from cupid.dt.nchc.gov.tw (cupid.dt.nchc.gov.tw [140.110.33.240]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id CAA20371
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 02:22:48 -0700 (PDT)
	mail_from (a00chc00@nchc.gov.tw)
Received: from nchc.gov.tw (pc225.dt.nchc.gov.tw [140.110.34.219])
	by cupid.dt.nchc.gov.tw (8.8.5/8.8.5) with ESMTP id RAA26114
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 17:18:30 +0800 (CST)
Message-ID: <35484281.945C41D1@nchc.gov.tw>
Date: Thu, 30 Apr 1998 17:21:05 +0800
From: "Charlie H. Chang" <a00chc00@nchc.gov.tw>
Organization: NCHC
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: drawing wireframe...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi there,

Can someone tell me how to draw a pfDCS in wireframe mode
like we can do on pfGeoSet?  I don't want to get the whole scene
in wireframe mode, just some pfDCS objects...
Thank you in advance!

--
Charlie H. Chang                E-mail: a00chc00@nchc.gov.tw
Voice: 886-3-5776085x209        Fax: 886-3-5773620
Media & Visualization Lab, National Center for High-performance
Computing


=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 02:42:29 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA29683 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 02:34:45 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id CAA29656 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 02:34:44 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA18251028
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 02:34:44 -0700 (PDT)
Received: from stargate.nova.es (stargate.nova.es [194.224.68.8]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id CAA22405
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 02:34:42 -0700 (PDT)
	mail_from (vissim@comarts.es)
Received: from o21 (modem203.nova.es [195.76.203.203]) by stargate.nova.es (8.6.13/8.6.12) with SMTP id LAA24025 for <info-performer@sgi.com>; Thu, 30 Apr 1998 11:35:00 +0200
Sender: vissim@stargate.nova.es
Message-ID: <35484000.41C6@comarts.es>
Date: Thu, 30 Apr 1998 11:10:24 +0200
From: Real Time Computer Graphics <vissim@comarts.es>
Organization: Computer Arts & Developments
X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: unsusbcribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

unsusbcribe
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 04:26:46 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA00060 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 04:07:16 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA00033 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 04:07:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA18446186
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 04:07:13 -0700 (PDT)
Received: from crane.cf.ac.uk (crane.cf.ac.uk [131.251.0.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA11241
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 04:07:05 -0700 (PDT)
	mail_from (Ruddle@cardiff.ac.uk)
Received: from thor.cf.ac.uk by crane.cf.ac.uk with SMTP-LOC (PP);
          Thu, 30 Apr 1998 12:02:23 +0100
Received: from localhost (saprar@localhost) by thor.cf.ac.uk (8.8.8/8.6.12) 
          with SMTP id MAA21681 for <info-performer@sgi.com>;
          Thu, 30 Apr 1998 12:06:09 +0100 (BST)
Date: Thu, 30 Apr 1998 12:06:09 +0100 (BST)
From: Roy Ruddle <Ruddle@cardiff.ac.uk>
Reply-To: Ruddle@cardiff.ac.uk
To: info-performer@sgi.com
Subject: Variable chan updates
Message-ID: <Pine.OSF.3.95q.980429182049.10977E-200000@thor>
MIME-Version: 1.0
Content-type: MULTIPART/MIXED; boundary="0-332299323-893934369=:7494"
Status: O

--0-332299323-893934369=:7494
Content-type: TEXT/PLAIN; charset="US-ASCII"

Hi there,

I'm writing an application in which the 2 channels on a single pipe
should each have a different update rate. I've tried to implement this by
toggleing the DRAW traversal mode (PF_ON/OFF) according to whether or not 
a particular channel should be drawn in a frame but I get the channels
have a black flash.

I've replicated the problem with a 1-channel test program. The channel
covers the whole of the pipe viewport (VP bounds 0 .. 1 in X and Y). The
channel is drawn (correctly) once every 10 frames but it flashes black on
the other frames. This happens whether or not the channel draw traversal
function calls clear(), and whether or not I use a channel draw traversal
function.

My guess is that the black flashing is being caused by a pipe-based
"clear" function.

Can anyone tell me how I can overcome this black flashing (what have I
done wrong?).

System:
MaximumIMPACT
pf2.2, compiled n32 (OGL)
Irix 6.2

Test program is attached.


many thanks

roy



--0-332299323-893934369=:7494
Content-ID: <Pine.OSF.3.95q.980430120609.7494E@thor>
Content-Description: 
Content-type: TEXT/PLAIN; charset="US-ASCII"; name="bug_update.c++"
Content-transfer-encoding: BASE64

I2luY2x1ZGUgPGlvc3RyZWFtLmg+DQojaW5jbHVkZSA8ZnN0cmVhbS5oPg0K
I2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0cmluZy5oPg0KI2lu
Y2x1ZGUgPG1hdGguaD4NCiNpbmNsdWRlIDxjdHlwZS5oPg0KDQojaW5jbHVk
ZSA8UGVyZm9ybWVyL3BmLmg+DQojaW5jbHVkZSA8UGVyZm9ybWVyL3BmL3Bm
Q2hhbm5lbC5oPg0KI2luY2x1ZGUgPFBlcmZvcm1lci9wZi9wZkdlb2RlLmg+
DQojaW5jbHVkZSA8UGVyZm9ybWVyL3ByL3BmR2VvU2V0Lmg+DQojaW5jbHVk
ZSA8UGVyZm9ybWVyL3BmL3BmTGlnaHRTb3VyY2UuaD4NCiNpbmNsdWRlIDxQ
ZXJmb3JtZXIvcHIvcGZMaWdodC5oPg0KI2luY2x1ZGUgPFBlcmZvcm1lci9w
ci9wZk1hdGVyaWFsLmg+DQojaW5jbHVkZSA8UGVyZm9ybWVyL3BmL3BmTm9k
ZS5oPg0KI2luY2x1ZGUgPFBlcmZvcm1lci9wZi9wZlNjZW5lLmg+DQojaW5j
bHVkZSA8UGVyZm9ybWVyL3BmL3BmRENTLmg+DQojaW5jbHVkZSA8UGVyZm9y
bWVyL3BmdXRpbC5oPg0KI2luY2x1ZGUgPFBlcmZvcm1lci9wci5oPg0KI2lu
Y2x1ZGUgPFBlcmZvcm1lci9wci9wZlRleHR1cmUuaD4NCg0Kc3RhdGljIHZv
aWQgT3BlblBpcGVXaW4ocGZQaXBlV2luZG93ICpwdyk7DQpzdGF0aWMgdm9p
ZCBEcmF3Q2hhbm5lbChwZkNoYW5uZWwgKmNoYW5uZWwsIHZvaWQgKmRhdGEp
Ow0KDQppbnQgbWFpbiggaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSApIA0Kew0K
ICBpbnQgbDEsIGwyLCBsMzsNCg0KICBwZkluaXQoKTsNCiAgcGZNdWx0aXBy
b2Nlc3MoIFBGTVBfREVGQVVMVCApOw0KICBwZkNvbmZpZygpOw0KDQogIHBm
U2NlbmUgKnNjZW5lID0gbmV3IHBmU2NlbmU7DQoNCiAgZmxvYXQgeGRpbSA9
IDEwLjBmLCB5ZGltID0gMTAuMGYsIHpkaW0gPSA5LjlmOw0KICAvLw0KICAv
LyBDcmVhdGUgcGllY2Ugb2YgZmxhdCB0ZXJyYWluDQogIC8vDQogIHBmR2Vv
U2V0ICpnc2V0ID0gbmV3IHBmR2VvU2V0KCk7DQogIGdzZXQtPnNldFByaW1U
eXBlKCBQRkdTX1RSSVNUUklQUyApOw0KICBnc2V0LT5zZXROdW1Qcmltcygg
MSApOw0KICBpbnQgKnBfbGVuZ3RocyA9IG5ldyBpbnQ7DQogICpwX2xlbmd0
aHMgPSA0Ow0KICBnc2V0LT5zZXRQcmltTGVuZ3RocyggcF9sZW5ndGhzICk7
DQogIHBmVmVjNCAqY29sb3VyID0gbmV3IHBmVmVjNCggMC4yZiwgMC43Ziwg
MC4yZiwgMS4wZiApOw0KICBnc2V0LT5zZXRBdHRyKCBQRkdTX0NPTE9SNCwg
UEZHU19PVkVSQUxMLCBjb2xvdXIsIDAgKTsNCiAgcGZWZWMzICp2ZXJ0aWNl
cyA9IG5ldyBwZlZlYzNbICpwX2xlbmd0aHMgXTsNCiAgcGZWZWMzICp2diA9
IHZlcnRpY2VzOw0KICB2di0+c2V0KCAteGRpbSwgLXlkaW0sIHpkaW0gKTsg
dnYrKzsNCiAgdnYtPnNldCggeGRpbSwgLXlkaW0sIHpkaW0gKTsgdnYrKzsN
CiAgdnYtPnNldCggLXhkaW0sIHlkaW0sIHpkaW0gKTsgdnYrKzsNCiAgdnYt
PnNldCggeGRpbSwgeWRpbSwgemRpbSApOyB2disrOw0KICBnc2V0LT5zZXRB
dHRyKCBQRkdTX0NPT1JEMywgUEZHU19QRVJfVkVSVEVYLCB2ZXJ0aWNlcywg
MCApOw0KICBwZlZlYzMgKm5vcm1hbHMgPSBuZXcgcGZWZWMzOw0KICBub3Jt
YWxzLT5zZXQoIDAuMGYsIDAuMGYsIDEuMGYgKTsNCiAgZ3NldC0+c2V0QXR0
ciggUEZHU19OT1JNQUwzLCBQRkdTX09WRVJBTEwsIG5vcm1hbHMsIDAgKTsN
CiAgZ3NldC0+c2V0QXR0ciggUEZHU19URVhDT09SRDIsIFBGR1NfT0ZGLCAw
LCAwICk7DQoNCiAgcGZHZW9TdGF0ZSAqZ3N0YXRlID0gbmV3IHBmR2VvU3Rh
dGUoKTsNCiAgZ3N0YXRlLT5zZXRNb2RlKCBQRlNUQVRFX0VOVEVYVFVSRSwg
UEZUUl9PRkYgKTsNCiAgcGZNYXRlcmlhbCAqbXRsID0gbmV3IHBmTWF0ZXJp
YWwoKTsNCiAgbXRsLT5zZXRTaWRlKCBQRk1UTF9GUk9OVCApOw0KICBtdGwt
PnNldENvbG9yKCBQRk1UTF9BTUJJRU5ULCAxLjBmLCAxLjBmLCAxLjBmICk7
DQogIG10bC0+c2V0Q29sb3IoIFBGTVRMX0RJRkZVU0UsIDEuMGYsIDEuMGYs
IDEuMGYgKTsNCiAgZ3N0YXRlLT5zZXRBdHRyKCBQRlNUQVRFX0ZST05UTVRM
LCBtdGwgKTsNCiAgZ3NldC0+c2V0R1N0YXRlKCBnc3RhdGUgKTsNCiAgcGZH
ZW9kZSAqZ2VvZGUgPSBuZXcgcGZHZW9kZSgpOw0KICBnZW9kZS0+YWRkR1Nl
dCggZ3NldCApOw0KICBzY2VuZS0+YWRkQ2hpbGQoIGdlb2RlICk7DQogIC8v
DQogIC8vIENvbmZpZ3VyZSBhbmQgb3BlbiBHTCB3aW5kb3cNCiAgLy8NCiAg
cGZQaXBlICpwaXBlID0gcGZHZXRQaXBlKDApOw0KICBwZlBpcGVXaW5kb3cg
KnB3ID0gbmV3IHBmUGlwZVdpbmRvdyhwaXBlKTsNCiAgcHctPnNldE5hbWUo
IkNhcmRpZmYgVUFWIik7DQogIGludCBkaXNwbGF5X3ggPSAxMjgwLCBkaXNw
bGF5X3kgPSAxMDI0Ow0KICBwdy0+c2V0T3JpZ2luU2l6ZSggMCwgMCwgZGlz
cGxheV94LCBkaXNwbGF5X3kgKTsNCiAgcHctPnNldE1vZGUoIFBGV0lOX05P
Qk9SREVSLCBQRklTX1RSVUUgKTsNCiAgcHctPnNldENvbmZpZ0Z1bmMoT3Bl
blBpcGVXaW4pOw0KICBwdy0+Y29uZmlnKCk7DQogIC8vDQogIC8vIENyZWF0
ZSBjaGFubmVsDQogIC8vDQogIHBmQ2hhbm5lbCAqY2hhbiA9IG5ldyBwZkNo
YW5uZWwoIHBpcGUgKTsNCiAgY2hhbi0+c2V0Vmlld3BvcnQoIDAuMGYsIDEu
MGYsIDAuMGYsIDEuMGYgKTsNCiAgY2hhbi0+c2V0Rk9WKCA0NS4wZiwgMC4w
ZiApOw0KICBjaGFuLT5zZXROZWFyRmFyKCAxLjBmLCAxMDAwLjBmICk7DQog
IGNoYW4tPnNldFNjZW5lKCBzY2VuZSApOw0KICBjaGFuLT5zZXRUcmF2RnVu
YyggUEZUUkFWX0RSQVcsIERyYXdDaGFubmVsICk7DQogIGNoYW4tPnNldFRy
YXZNb2RlKCBQRlRSQVZfRFJBVywgUEZEUkFXX09GRiApOw0KDQogIHBmVmVj
MyB4eXooIDAuMGYsIDAuMGYsIDEwMC4wZiApLCBocHI7DQogIGludCBmY250
ID0gMDsNCg0KICB3aGlsZSggcGZHZXRUaW1lKCkgPCAxMC4wICkgew0KICAg
IHBmU3luYygpOw0KICAgIGhwci5zZXQoIDAuMGYsIC05MC4wZiwgZmxvYXQo
IHBmR2V0VGltZSgpICkgKiAzMC4wZiApOw0KICAgIGNoYW4tPnNldFZpZXco
IHh5eiwgaHByICk7DQoNCiAgICBmY250Kys7DQoNCiAgICBpZiggZmNudCA9
PSA5ICkgeyAvLyBEcmF3IG9uY2UgZXZlcnkgMTAgZnJhbWVzDQogICAgICBj
aGFuLT5zZXRUcmF2TW9kZSggUEZUUkFWX0RSQVcsIFBGRFJBV19PTiApOw0K
ICAgIH0NCiAgICBlbHNlIGlmKCBmY250ID09IDEwICkgew0KICAgICAgY2hh
bi0+c2V0VHJhdk1vZGUoIFBGVFJBVl9EUkFXLCBQRkRSQVdfT0ZGICk7DQog
ICAgICBmY250ID0gMDsNCiAgICB9DQoNCiAgICBwZkZyYW1lKCk7DQoNCiAg
fQ0KICBwZkV4aXQoKTsNCiAgcmV0dXJuIDA7DQp9DQoNCnZvaWQgT3BlblBp
cGVXaW4ocGZQaXBlV2luZG93ICpwdykNCnsNCiAgaW50IGwxOw0KICBwdy0+
b3BlbigpOw0KDQogIHBmTGlnaHRNb2RlbCAqbGlnaHRfbW9kZWwgPSBuZXcg
cGZMaWdodE1vZGVsOw0KICBsaWdodF9tb2RlbC0+c2V0QW1iaWVudCggMS4w
ZiwgMS4wZiwgMS4wZiApOw0KICBsaWdodF9tb2RlbC0+YXBwbHkoKTsNCg0K
ICBwZkVuYWJsZShQRkVOX0xJR0hUSU5HKTsNCiAgcGZPdmVycmlkZShQRlNU
QVRFX0xJR0hUUywgUEZfT04pOw0KICBwZk92ZXJyaWRlKFBGU1RBVEVfTElH
SFRNT0RFTCwgUEZfT04pOw0KDQogIHBmQW50aWFsaWFzKCBQRkFBX09GRiAp
Ow0KICBwZkN1bGxGYWNlKCBQRkNGX0JBQ0sgKTsNCn0NCg0Kc3RhdGljIHZv
aWQgRHJhd0NoYW5uZWwgKHBmQ2hhbm5lbCAqY2hhbm5lbCwgdm9pZCAqZGF0
YSkNCnsNCiAgY2hhbm5lbC0+Y2xlYXIoKTsgIA0KICBwZkRyYXcoKTsNCn0N
Cg0K
--0-332299323-893934369=:7494--
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 06:41:26 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA00465 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 06:31:11 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA00438 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 06:31:09 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA14070585
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 06:31:08 -0700 (PDT)
Received: from dewey.fel.tno.nl (dewey.fel.tno.nl [192.55.105.37]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id GAA10618
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 06:31:03 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by dewey.fel.tno.nl; id PAA25823; Thu, 30 Apr 1998 15:24:42 +0200
Received: from s00sn1.fel.tno.nl(134.203.8.207) by dewey.fel.tno.nl via smap (4.1)
	id xma025819; Thu, 30 Apr 98 15:24:37 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id PAA11566;
	Thu, 30 Apr 1998 15:23:43 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199804301323.PAA11566@s00sn1.fel.tno.nl>
Subject: Re: drawing wireframe...
To: a00chc00@nchc.gov.tw (Charlie H. Chang)
Date: Thu, 30 Apr 1998 15:23:43 +0200 (MET DST)
Cc: info-performer@sgi.com (Performer)
In-Reply-To: <35484281.945C41D1@nchc.gov.tw> from "Charlie H. Chang" at Apr 30, 98 05:21:05 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> Can someone tell me how to draw a pfDCS in wireframe mode
> like we can do on pfGeoSet?  I don't want to get the whole scene
> in wireframe mode, just some pfDCS objects...
> Thank you in advance!
> 
> --
> Charlie H. Chang                E-mail: a00chc00@nchc.gov.tw

You can use the pfuTraverser to write a function that sets the
wireframe mode off all the geosets that are below a certain node.
Or you can set pre and post draw call backs to the wanted DCS's and
put in these functions call to set and override the wireframe mode.

int preDrawWireframe(pfTraverser* trav, void* data)
{
    pfEnable(PFEN_WIREFRAME);
    pfOverride(PFSTATE_ENWIREFRAME, 1);
    return PFTRAV_CONT;
}

int postDrawWireframe(pfTraverser* trav, void* data)
{
    pfOverride(PFSTATE_ENWIREFRAME, 0);
    pfDisable(PFEN_WIREFRAME);
    return PFTRAV_CONT;
}

Mario
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 07:09:02 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA00530 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 06:58:22 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA00497 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 06:58:21 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA18055803
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 06:58:20 -0700 (PDT)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA18208
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 06:58:19 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from sutcliffe.bgm.link.com (sutcliffe.bgm.link.com [130.210.236.18])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id IAA28580 for <info-performer@sgi.com>; Thu, 30 Apr 1998 08:58:18 -0500 (CDT)
Date: Thu, 30 Apr 1998 08:57:04 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Info-Performer Mailing List <info-performer@sgi.com>
Subject: Fogging problems on RE2.
Message-ID: <Pine.SGI.3.96.980430085419.7823A-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


Yes, I know this is a little off-topic, but I know
a bunch of you clue-ful SGI types are listening and
I didn't get any help from comp.graphics.api.opengl
so here goes...

  I'm writing a simple GLUT/OpenGL program which runs
quite nicely on an SGI ONYX Infinite Reality and on a
Linux machine with Mesa and a 3Dfx Voodoo card.

  So far this is great.

  Now I try to run the same thing on an SGI ONYX RE2
(IRIX 6.2) and the fog comes out WAY too dense.

  Here is the code to set up the fog:

    glEnable ( GL_FOG ) ;
    glHint ( GL_FOG_HINT, GL_NICEST ) ;

    static float fogcol [ 4 ] = { 0.3, 0.6, 1.0, 1.0 } ;
    glFogfv( GL_FOG_COLOR  , fogcol   ) ;
    glFogf ( GL_FOG_START  , 0.0      ) ;
    glFogf ( GL_FOG_END    , 50000.0 ) ;
    glFogf ( GL_FOG_DENSITY, 0.000005 ) ;
    glFogi ( GL_FOG_MODE   , GL_EXP   ) ;

  Near/far clip planes are 2.0 and 1000000.0.

  The scene is a regular grid of tristrips lying in the X/Z
plane from the eye all the way out to somewhere beyond
the far clip plane.

  Is there some lingering IrisGL-ness in the RE2's OpenGL
that might be killing me here?  Is there anything else I
can do to make the RE2 fog look the same as it does on
the other machines? Maybe there is some kind of patch I
should have installed?

  HELP!


Steve Baker                (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-4028 (Fax)
Work: SBaker@link.com      http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 07:47:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA01028 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 07:37:14 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA01001 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 07:37:08 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA18558547;
	Thu, 30 Apr 1998 07:37:07 -0700 (PDT)
Received: from helios.Discreet.QC.CA (discreet.com [207.219.240.29]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA03211; Thu, 30 Apr 1998 07:37:05 -0700 (PDT)
	mail_from (dery@discreet.com)
Received: from cuba by helios.Discreet.QC.CA
	id KAA09242; Thu, 30 Apr 1998 10:29:25 -0400
Errors-To: postmaster@discreet.com
Received: from atlantis (atlantis [172.16.100.56]) by cuba (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10727; Thu, 30 Apr 1998 10:28:25 -0400
Received: (from dery@localhost) by atlantis (950413.SGI.8.6.12/) id KAA01018; Thu, 30 Apr 1998 10:28:20 -0400
From: "Jean-Luc Dery" <dery@discreet.com>
Message-Id: <9804301028.ZM1017@atlantis>
Date: Thu, 30 Apr 1998 10:28:20 -0400
In-Reply-To: Roy Ruddle <Ruddle@cardiff.ac.uk>
        "Variable chan updates" (Apr 30, 12:06pm)
References: <Pine.OSF.3.95q.980429182049.10977E-200000@thor>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Ruddle@cardiff.ac.uk, info-performer@sgi.com
Subject: Re: Variable chan updates
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 30, 12:06pm, Roy Ruddle wrote:
> Subject: Variable chan updates
>
> Hi there,
>
> I'm writing an application in which the 2 channels on a single pipe
> should each have a different update rate. I've tried to implement this by
> toggleing the DRAW traversal mode (PF_ON/OFF) according to whether or not
> a particular channel should be drawn in a frame but I get the channels
> have a black flash.
>
> I've replicated the problem with a 1-channel test program. The channel
> covers the whole of the pipe viewport (VP bounds 0 .. 1 in X and Y). The
> channel is drawn (correctly) once every 10 frames but it flashes black on
> the other frames. This happens whether or not the channel draw traversal
> function calls clear(), and whether or not I use a channel draw traversal
> function.
>
> My guess is that the black flashing is being caused by a pipe-based
> "clear" function.
>
> Can anyone tell me how I can overcome this black flashing (what have I
> done wrong?).
>
> System:
> MaximumIMPACT
> pf2.2, compiled n32 (OGL)
> Irix 6.2
>
> Test program is attached.
>
>
> many thanks
>
> roy

Hi Roy,

This is most probably due to the fact that you drawing only one buffer in
double buffer mode but still swapping buffers. You can conrol the swap buffer
through a Performer callback.

pfPipe::setSwapFunc( pfPipe* p, pfPipeWindow* pw);
pfPipeWindow::swapBuffers();

In a two channels setup were you want to have different update rates, you have
to have one pipe window for each channel and manage the pipe window swap buffer
from the pfPipe swap callback (anybody correct me if I'm wrong??).

You can use a setUserData() (or anything you can think of to pass this
information to the swap callback) in your pfChannel draw callback to set wether
or not a swap is needed. You can then use this in the pipe swap function
callback to call the pfPipeWindow::swapBuffers().

Hope this helps,

Jean-Luc

-- 
_____________________________________________________________________________

Jean-Luc Dery                         Discreet Logic
System Engineer                       10 Duke Street
3-D Graphics Technology               Montreal (Quebec), Canada, H3C 2L7
                                      Tel: (514) 954-7239
Email: jean-lucD@discreet.com         Fax: (514) 393-0110
_____________________________________________________________________________
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 08:21:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA01150 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 08:09:17 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA01123 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 08:09:16 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA18520011
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 08:09:15 -0700 (PDT)
Received: from ait.nrl.navy.mil (ait.nrl.navy.mil [132.250.128.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id IAA16249
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 08:09:12 -0700 (PDT)
	mail_from (ekuo@ait.nrl.navy.mil)
Received: from gold-cl.cmf.nrl.navy.mil (fargo [132.250.128.95])
	by ait.nrl.navy.mil (8.8.8/8.8.8) with SMTP id LAA06371
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 11:09:07 -0400 (EDT)
Date: Thu, 30 Apr 1998 11:09:07 -0400 (EDT)
From: Eddy Kuo <ekuo@ait.nrl.navy.mil>
X-Sender: ekuo@gold-cl.cmf.nrl.navy.mil
To: info-performer@sgi.com
Subject: More GeoSet Question
Message-ID: <Pine.SGI.3.91.980430110536.15452F-100000@gold-cl.cmf.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello pfers:

I am using pfFlux for a dynamic geoset.  Whenever I display the geoset
after updating the geometry, my image flashes a lot (as if I don't
have double buffering)  During a draw callback, I did a channel clear, 
in order to erase the old geoset and redraw the new geoset, is this
the problem?

thanks the any advice


Ed.

-------------------------------------------------------------------
Eddy Kuo 		      		work phone: 202-767-6025 
Virtual Reality Lab 			home phone: 703-893-2553
Naval Research Lab		http://www.cis.ohio-state.edu/~ekuo
-------------------------------------------------------------------

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 08:35:30 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA01264 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 08:25:00 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA01237 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 08:24:59 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA18501563
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 08:24:59 -0700 (PDT)
Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id IAA22697
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 08:24:57 -0700 (PDT)
	mail_from (dpearce@dial.pipex.com)
Received: (qmail 2808 invoked from network); 30 Apr 1998 15:24:45 -0000
Received: from userl739.uk.uudial.com (HELO geordie) (193.149.76.44)
  by smtp.dial.pipex.com with SMTP; 30 Apr 1998 15:24:45 -0000
Message-ID: <000f01bd744b$a41ee7e0$2c4c95c1@geordie>
Reply-To: "David Pearce" <dpearce@dial.pipex.com>
From: "David Pearce" <dpearce@dial.pipex.com>
To: <info-performer@sgi.com>
Subject: Job Opportunity
Date: Thu, 30 Apr 1998 16:21:16 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000C_01BD7454.004A8300"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Status: O

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01BD7454.004A8300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Lockheed Martin Solartron Systems have been supplying simulation and =
training equipment to the defence industry for the last 30 years. To =
meet current demand we currently have a vacancy for a Visual Modeller to =
help us produce a new family of 3D models and terrains at our facility =
in the historic town of Hertford in Hertfordshire, England.

If you are interested, please send your CV/Resume to the address given =
below.=20

Visual Modeller

Responsibilities:

You will be part of a small team, creating virtual reality crew trainer =
simulators for the defence industry.
You will be responsible for the design of all of the interactive =
graphics. This includes acquisition and preparation of texture maps, =
design of targets models of aircraft and ground vehicles, ships, =
terrains, seascapes, and special effects.
Be able to work under pressure to meet tight deadlines. Good =
communication skills and a fun attitude are desirable.

You=92ll be using high end modelling software like MultiGen II Pro =
running on a Silicon Graphics workstation.

Skills:
Preferably: MultiGen II Pro
                    Photoshop
Other:         3Dstudio MAX

Education:
BSc degree in art, industrial design, computer design/animation, or =
engineering (or simular work experience)

Experience:
Background in working with interactive 3D computer graphics for visual =
simulation or games.
Creation of 3D models for animation or simulation.
Experience of communicating with Engineers and understanding of real =
time implication of modelling decisions is important.

If available show some examples of your previous work.

--=20
Dave Pearce
Project Manager,
Lockheed Martin Solartron Systems
Hale Road, Hertford, Hertfordshire, SG13 8DX,
England
email : dpearce@dial.pipex.com
Tel:  +44 (0)1992 534111
Fax: +44 (0)1992 534148
Mobile +44 (0)467 338645

------=_NextPart_000_000C_01BD7454.004A8300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT size=3D2>
<DIV><FONT color=3D#000000 size=3D2><STRONG></STRONG></FONT><FONT =
size=3D2>
<P>Lockheed Martin Solartron Systems have been supplying simulation and =
training=20
equipment to the defence industry for the last 30 years. To meet current =
demand=20
we currently have a vacancy for a Visual Modeller to help us produce a =
new=20
family of 3D models and terrains at our facility in the historic town of =

Hertford in Hertfordshire, England.</P>
<P>If you are interested, please send your CV/Resume to the address =
given=20
below.&nbsp;</FONT></P></DIV>
<DIV><FONT color=3D#000000 size=3D2><STRONG>Visual =
Modeller</STRONG></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Responsibilities:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>You will be part of a small team, =
creating=20
virtual reality crew trainer simulators for the defence =
industry.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>You will be responsible for the =
design of all of=20
the interactive graphics. </FONT><FONT color=3D#000000 size=3D2>This =
includes=20
acquisition and preparation of texture maps, design of targets models of =

aircraft and ground vehicles, ships, terrains, seascapes, and special=20
effects.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Be able to work under pressure to =
meet tight=20
deadlines. Good communication skills and a fun attitude are=20
desirable.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>You&rsquo;ll be using high end =
modelling=20
software like MultiGen II Pro running on a Silicon Graphics=20
workstation.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Skills:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Preferably: MultiGen II =
Pro</FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Photoshop</FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>Other:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3Dstudio =

MAX</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Education:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>BSc degree in art, industrial =
design, computer=20
design/animation, or engineering </FONT><FONT color=3D#000000 =
size=3D2>(or simular=20
work experience)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Experience:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Background in working with =
interactive 3D=20
computer graphics for visual simulation or games.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Creation of 3D models for animation =
or=20
simulation.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Experience of communicating with =
Engineers and=20
understanding of real time implication of modelling decisions is=20
important.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>If available show some examples of =
your previous=20
work.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT></FONT><FONT color=3D#000000=20
size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV><FONT color=3D#000000 size=3D2>-- <BR>Dave Pearce<BR>Project=20
Manager,<BR>Lockheed Martin Solartron Systems<BR>Hale Road, Hertford,=20
Hertfordshire, SG13 8DX,<BR>England</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>email : <A=20
href=3D"mailto:dpearce@dial.pipex.com">dpearce@dial.pipex.com</A><BR>Tel:=
&nbsp;=20
+44 (0)1992 534111<BR>Fax: +44 (0)1992 534148<BR>Mobile +44 (0)467=20
338645</FONT></DIV></BODY></HTML>

------=_NextPart_000_000C_01BD7454.004A8300--

=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 08:55:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA01430 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 08:43:42 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA01403 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 08:43:41 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA18400364
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 08:43:40 -0700 (PDT)
Received: from quid.engr.sgi.com ([130.62.52.45]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id IAA00183
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 08:43:40 -0700 (PDT)
	mail_from (robj@quid.engr.sgi.com)
Received: (from robj@localhost) by quid.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id IAA15166; Thu, 30 Apr 1998 08:43:38 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9804300843.ZM15526@quid.engr.sgi.com>
Date: Thu, 30 Apr 1998 08:43:37 -0700
In-Reply-To: Steve Baker <sbaker@link.com>
        "Fogging problems on RE2." (Apr 30,  8:57am)
References: <Pine.SGI.3.96.980430085419.7823A-100000@sutcliffe.bgm.link.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Steve Baker <sbaker@link.com>,
        Info-Performer Mailing List <info-performer@sgi.com>
Subject: Re: Fogging problems on RE2.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Steve

Patches would be the first thing I'd check. There were some regressions for EXP
and EXP2 fog on RE2 in the RE rollup patch 1702. Since then they were fixed in
patch 2038 which in turn has since been replaced by patch 2739. In short, make
sure you have the latest RE2 rollup patch installed:
Patch 2739: RealityEngine rollup #4 for IRIX 6.2

In practice I don't think 2739 has new fog fixes over 2038 so if you already
have 2038 at least then 2739 might not make any difference but you still ought
to have it for the other fixes in there.

You have a pretty big near:far clipping plane ratio, does the fog on RE2 get
better if you reduce that ? RE2 approximates the fog function in the screen
space rather than eye space so that ratio effects the fog resolutiuon spread
you get. If none of this helps then let me know, there's some other stuff we
can look into.

Cheers
Rob


On Apr 30,  8:57am, Steve Baker wrote:
> Subject: Fogging problems on RE2.
>
> Yes, I know this is a little off-topic, but I know
> a bunch of you clue-ful SGI types are listening and
> I didn't get any help from comp.graphics.api.opengl
> so here goes...
>
>   I'm writing a simple GLUT/OpenGL program which runs
> quite nicely on an SGI ONYX Infinite Reality and on a
> Linux machine with Mesa and a 3Dfx Voodoo card.
>
>   So far this is great.
>
>   Now I try to run the same thing on an SGI ONYX RE2
> (IRIX 6.2) and the fog comes out WAY too dense.
>
>   Here is the code to set up the fog:
>
>     glEnable ( GL_FOG ) ;
>     glHint ( GL_FOG_HINT, GL_NICEST ) ;
>
>     static float fogcol [ 4 ] = { 0.3, 0.6, 1.0, 1.0 } ;
>     glFogfv( GL_FOG_COLOR  , fogcol   ) ;
>     glFogf ( GL_FOG_START  , 0.0      ) ;
>     glFogf ( GL_FOG_END    , 50000.0 ) ;
>     glFogf ( GL_FOG_DENSITY, 0.000005 ) ;
>     glFogi ( GL_FOG_MODE   , GL_EXP   ) ;
>
>   Near/far clip planes are 2.0 and 1000000.0.
>
>   The scene is a regular grid of tristrips lying in the X/Z
> plane from the eye all the way out to somewhere beyond
> the far clip plane.
>
>   Is there some lingering IrisGL-ness in the RE2's OpenGL
> that might be killing me here?  Is there anything else I
> can do to make the RE2 fog look the same as it does on
> the other machines? Maybe there is some kind of patch I
> should have installed?
>
>   HELP!
>
>
> Steve Baker                (817)619-8776 (Vox/Vox-Mail)
> Raytheon Systems Inc.      (817)619-4028 (Fax)
> Work: SBaker@link.com      http://www.hti.com
> Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
>
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com
>-- End of excerpt from Steve Baker



-- 
________________________________________________________________
Rob Jenkins mailto:robj@sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 09:31:18 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA01707 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 09:17:21 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA01680 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 09:17:13 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA17991765
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 09:17:13 -0700 (PDT)
Received: from inra.inra.fr (inra.inra.fr [138.102.88.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id JAA15763
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 09:16:49 -0700 (PDT)
	mail_from (perfly@segolene.roazhon.inra.fr)
From: perfly@segolene.roazhon.inra.fr
Received: from segolene.roazhon.inra.fr (segolene.roazhon.inra.fr [194.167.74.40])
	by inra.inra.fr (8.8.8/8.8.8) with SMTP id SAA28994
	for <info-performer@sgi.com>; Thu, 30 Apr 1998 18:14:14 +0200 (MET DST)
Received: by segolene.roazhon.inra.fr (5.x/SMI-SVR4)
	id AA16567; Thu, 30 Apr 1998 18:15:41 +0200
Date: Thu, 30 Apr 1998 18:15:41 +0200
Message-Id: <9804301615.AA16567@segolene.roazhon.inra.fr>
To: info-performer@sgi.com
Subject: pfAsdConfig vs pfASDFaceBBox
X-Sun-Charset: US-ASCII
Status: O

Salut,

I want to modify the value of the vertices of my pfAsd
during the fly.
I do this and it works.
But I think that the Bboxes of my faces don't change.
I try pfAsdConfig () but the Cull process works
as I 've never changed the vertices. I think that I can't use
this function during the fly.

Do I have to change all the Bboxes by myself with pfASDFaceBBox (...)
or is there any function to do this.

Thanks

Kenavo.
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com

From guest  Thu Apr 30 17:47:56 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA02648 for info-performer-dist@holodeck.engr.sgi.com; Thu, 30 Apr 1998 17:28:58 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA02620 for <info-performer@holodeck.engr.sgi.com>; Thu, 30 Apr 1998 17:28:57 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA18880109
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 30 Apr 1998 17:28:56 -0700 (PDT)
Received: from imo20.mx.aol.com (imo20.mx.aol.com [198.81.17.42]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id RAA15893; Thu, 30 Apr 1998 17:28:42 -0700 (PDT)
	mail_from (PASociety@aol.com)
Received: from PASociety@aol.com
	by imo20.mx.aol.com (IMOv14.1) id KTGYa19024
	for <v-humans@ece.uwaterloo.ca>; Thu, 30 Apr 1998 19:59:55 -0400 (EDT)
From: PA Society <PASociety@aol.com>
Message-ID: <be94f990.3549107d@aol.com>
Date: Thu, 30 Apr 1998 19:59:55 EDT
To: v-humans@ece.uwaterloo.ca
Mime-Version: 1.0
Subject: (PAS) Facial Animation Presentation on Monday (May 4th)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Mailer: AOL 3.0 for Windows 95 sub 18
Status: O

 IMPORTANT REMINDER --- UPCOMING EVENT 

**********    FACIAL ANIMATION MONDAY  (MAY 4th) PRESENTATION   **********

THE PERFORMANCE ANIMATION SOCIETY KICKS OFF THE COMPUTER
GAME DEVELOPERS CONFERENCE MONDAY (MAY 4th) EVENING WITH
AN EXCITING PRESENTATION ON CREATING REALISTIC FACIAL ANIMATION
IN COMPUTER GAMES.

******************************************************************************
*****************

MEETING HIGHLIGHT:         "Computer Games get a Face Lift"


TIME & PLACE:   COMPUTER GAME DEVELOPERS CONFERENCE
                MONDAY, MAY 4th at 7:00PM Sharp!
                LONG BEACH CONVENTION CENTER - ROOM 103A

The "Performance Animation Society", the world's premier organization
for artists and developers working with the exciting new tools of human
digitization and simulation, will present a 1 + 1/2 hour seminar at the
Computer Games Developers Conference in Long Beach, CA. in Room 103A in
the Long Beach Convention Center on Monday, May 4th at 7:00 PM sharp.

MEETING DETAILS AND PRESENTATIONS:

TOPIC:   "COMPUTER GAMES GET A FACE LIFT"

Motion Capture and Performance Animation techniques are valuable tools
in adding realism to character animation in Computer Games. These tools
are being focused and refined even further to meet a growing need for
believable, accurate facial animation in gaming characters.

Motion Analysis Corporation, a leading solutions provider in human motion
and performance capture will present late-breaking developments and
applications of facial expression capture and image processing as they
apply to enhancing expressiveness in computer game characters.

Videos and demonstrations will also augment this exciting meeting of
artists, developers, scientists and performers. The meeting is free and
all who are interested are welcome and encouraged to attend this exciting
meeting.


FOR ADDITIONAL INFORMATION PLEASE VISIT OUR WEBSITE AT:

 WWW.PASOCIETY.ORG

THANK YOU

***********************   PLEASE CIRCULATE !!!! ***********************
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer@sgi.com
        Admin. requests:  info-performer-request@sgi.com